重定向次数过多：怎样找出HTTP、HTTPS与域名跳转闭环
浏览器提示重定向次数过多时，清缓存未必能解决。本文教你记录每一步跳转，检查CDN、源站和应用的地址规则，找出协议、域名或登录状态引起的循环。
先记录循环经过哪些地址
网站提示重定向次数过多，说明请求反复被带到另一个地址，最终形成闭环。先打开浏览器网络面板并保留请求记录，重新访问故障页面，逐条查看3xx响应的Location，记录协议、域名、路径和状态码。不要只看最后一个报错地址。
例如A跳到B、B又跳回A，就应分别定位两条规则属于哪一层。常见链路包括CDN强制HTTPS、Nginx统一域名，以及程序自己的站点地址设置。如果只在登录后出现，也要检查登录页、首页和权限判断之间是否相互跳转。
对齐代理与源站的规则
先确定唯一正式地址，再检查CDN、源站和应用是否都认可它。特别是Cloudflare的Flexible模式会通过HTTP连接源站；如果源站持续把这次请求重定向到HTTPS，就可能形成循环。准备调整加密模式前，应先确认源站证书和HTTPS服务配置正确。
另一个常见问题是www与裸域名各有一条相反跳转，或程序把HTTPS误判为HTTP。使用代理传递的协议信息时，只信任受控代理，不能无条件相信客户端自己提交的请求头。应修正地址判断，不要通过关闭加密来掩盖问题。
用四个入口验证
分别测试HTTP、HTTPS、www及裸域名入口，确认它们能够到达同一个正式页面。修改前备份规则，每次只调整一个冲突点；登录页还应分别测试登录和未登录状态，避免只修复首页。
若规则已正确而旧浏览器仍失败，再排查缓存、Cookie或已保存的跳转。清理浏览器数据只是对照手段，不能代替服务端规则修复。最终应能说明每次跳转的目的，并确认不存在回到前一地址的路径。
参考资料
资料核对日期：2026年10月24日。本文为综合官方文档整理的原创排查指南，未声称进行本站故障实测。
本文新增价值
本文按照可观察的请求和日志组织诊断顺序，提供对照测试、分层定位与修复验收方法，帮助读者减少盲目修改配置，并明确说明不同运行环境的适用边界。
本文按照可观察的请求和日志组织诊断顺序，提供对照测试、分层定位与修复验收方法，帮助读者减少盲目修改配置，并明确说明不同运行环境的适用边界。