所有文章
· URLsCheck

如何查找并修复 URL 重定向循环

系统排查 ERR_TOO_MANY_REDIRECTS，覆盖 HTTPS、www、尾斜杠、CDN、反向代理、Cookie、登录与语言跳转冲突。

重定向 故障排查 CDN

重定向循环是指请求最终回到已经访问过的 URL。浏览器不断跟随跳转，达到上限后显示 ERR_TOO_MANY_REDIRECTS。真正的根因经常横跨 CDN、反向代理、Web 服务器和应用框架，因此第一步不是盲目修改规则，而是先记录完整循环。

捕获最小循环

将浏览器报错的原始地址提交到URL 重定向检查器，寻找重复出现的 URL：

https://example.com/page
→ https://www.example.com/page
→ https://example.com/page

记录每一跳的状态码、协议、主机名、路径、查询参数和跳转类型。最小重复周期通常直接指向两个互相冲突的规则。

常见根因

HTTP 与 HTTPS 判断不一致

访客通过 HTTPS 连接 CDN，而 CDN 使用 HTTP 访问源站。若应用只观察到源站连接，就会反复要求升级 HTTPS。应正确配置并只信任来自可信代理的 Forwarded 或 X-Forwarded-Proto。

www 与非 www 冲突

CDN 强制 www，应用又强制非 www。选择一个规范主机，并让 DNS、CDN、服务器和应用保持一致。

尾斜杠冲突

一个框架把 /docs 改成 /docs/，另一个层又删除斜杠。规范化规则应只有一个明确责任方，站内链接也应直接使用规范形式。

受保护页面跳到登录页，但会话 Cookie 因域名、Secure、SameSite 或回调地址错误而无法建立，登录页又跳回受保护页面。无痕窗口可以帮助隔离状态，但最终仍需修复会话逻辑。

语言和地区路由

URL 前缀、Cookie、地区和 Accept-Language 互相冲突时，用户可能在 /、/en/ 与区域域名之间循环。显式 URL 和用户选择应优先于自动检测。

分层排查步骤

  1. 使用全新会话和服务端工具复现；
  2. 找到最小重复周期；
  3. 通过响应头和日志确定每一跳由哪一层生成；
  4. 在测试环境逐层隔离 CDN、服务器和应用规则；
  5. 为协议、主机名和尾斜杠指定唯一责任方；
  6. 测试 HTTP/HTTPS、www、斜杠与查询参数变体；
  7. 清理相关缓存后从公网重新验证。

永久重定向可能被浏览器和中间缓存长期保存。服务器修好后，旧浏览器仍可能继续走错误路线。请使用新会话或在线检查器区分“实时循环”和“本地缓存”。

预防清单

  • 记录规范协议、主机名与路径策略；
  • 避免多个层重复执行相反的规范化；
  • 明确信任代理范围；
  • 用接近生产的 CDN 配置做预发布测试；
  • 把关键跳转加入发布回归检查；
  • 避免会匹配自身目标的宽泛正则表达式。

它可能清除过期状态，但无法修复持续生成错误状态的规则。应把清理 Cookie 当作诊断步骤，而不是最终解决方案。

为什么只在 CDN 后出现？

CDN 可能终止 TLS、重写主机、缓存 3xx 或改变转发头。需要比较边缘与源站响应，并检查 SSL 模式和代理头配置。

所有文章
URLsCheck