永久重定向, 怎样识别配置互相冲突
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fa683c204b64.html
📄
永久重定向, 怎样识别配置互相冲突
识别永久重定向配置冲突，核心是检查同一请求路径是否被多条规则同时命中，且目标地址或状态码不一致。常见误解是：只要每条规则单独测试成功，整站就不会出问题。实际上，规则按顺序执行，前一条可能改写路径，后一条再基于新路径匹配，最终结果与单测完全不同。
为什么单条规则正确，合起来却冲突
永久重定向通常写在服务器配置、CDN边缘规则或应用路由中。冲突来源有三类：顺序叠加，即多条规则依次改写同一路径；条件重叠，即两条规则都匹配同一来源但指向不同目标；协议与域名混用，例如一条把HTTP跳HTTPS，另一条又把HTTPS跳回HTTP。多人协作时，各自只验证自己那段，合并后就可能出现循环或跳错域名。
用一条命令观察完整跳转链
不要只看浏览器地址栏，它可能缓存了之前的跳转。用命令行跟踪每一跳：
curl -I -L --max-redirs 10 http://example.com/old-path
重点看每一条响应的Location和状态码。301表示永久重定向，302表示临时。如果链中出现同一URL反复出现，就是循环；如果中间夹着302再转301，说明配置层不止一处。把--max-redirs设小一些，能更快暴露循环。
逐层核对规则，找出重叠的匹配条件
按请求经过的顺序列出所有可能改写该路径的位置：服务器配置文件、CDN回源规则、应用中间件。对每一层记录三件事：匹配条件、目标地址、状态码。然后做一张对照表：
- 同一来源路径是否出现在两层的匹配条件里；
- 两层给出的目标是否一致；
- 状态码是否都是301，还是混用了302。
只要同一路径被两层同时命中且目标不同，就是配置冲突。此时不要直接删规则，先确认哪一层应该负责该跳转。通常原则是：越靠近入口的层处理协议和域名归一，应用层只处理业务路径变更。
区分“可能原因”与“已定位原因”
看到循环跳转，可能原因是规则顺序错误，也可能是缓存返回了旧响应，还可能是CDN与源站各配了一条。不要直接断言是某一条规则写错。正确做法是：先清掉测试端的缓存，再用带随机查询串的URL请求一次，例如http://example.com/old-path?test=1，避免命中缓存。如果问题消失，说明之前看到的是缓存结果；如果仍然循环，再回到规则表逐层禁用验证。
多人协作时的交付检查项
为减少返工，交付前让每条重定向规则都有唯一负责人和唯一生效层。检查项包括：来源路径是否已被其他规则覆盖、目标地址是否经过协议归一、状态码是否统一为301、是否有测试用的临时302混入生产配置。若使用站点地图提交新地址，要明白站点地图不保证收录，它只帮助发现URL，不能替代重定向本身。robots.txt限制抓取也不等于可靠的索引移除，旧地址仍可能被外部链接引用。
下一步：把当前所有重定向规则导出成一张来源、目标、状态码、生效层的清单，对同一来源出现两次以上的行做标记，再按请求顺序逐条验证。
