网站反复跳转：定位重定向循环
浏览器提示“重定向次数过多”，常见原因是两层规则互相矛盾：一层把地址改成 HTTPS，另一层又改回 HTTP；或者代理已经接收 HTTPS，应用仍误以为用户访问的是 HTTP。先记录循环在哪两个地址之间发生，再修改对应规则。
下面适用于自己管理的网站。命令在 Linux 或 macOS 终端执行，域名替换为实际值，选首页或其他明确只读的公开地址；不使用付款、退出、开通等业务动作进行测试。
把第一跳和完整跳转链分开看
先分别请求 HTTP 和 HTTPS，查看第一份响应。这里使用 GET 并丢弃正文，避免某些应用对 HEAD 的处理与正常访问不同：
curl -q -sS --max-time 15 -D - -o /dev/null 'http://www.example.com/'
curl -q -sS --max-time 15 -D - -o /dev/null 'https://www.example.com/'重点记录状态码与 Location。301、302、303、307、308 中出现 Location 时，再看下一跳指向哪个协议、域名和路径。没有 Location 却在浏览器里跳转，还要查看页面脚本或 HTML 刷新设置。
然后跟随有限次数的跳转，打印每一跳的响应头：
curl -q -sS -L --max-redirs 8 --max-time 20 \
--proto-redir '=http,https' -D - -o /dev/null \
-w '\n最终地址：%{url_effective}\n状态：%{http_code}\n跳转次数：%{num_redirects}\n' \
'https://www.example.com/'反复出现相同地址，或者两个地址交替出现，就是有用证据。超过 8 次时 curl 会报达到跳转上限；不要改成无限跟随。本例的 -q放在第一个参数位置，避免读取默认 curl 配置，也没有添加认证或 Cookie。输出里的 Set-Cookie、带令牌的 Location 等内容仍需脱敏后才能分享。
对照跳转规律找冲突层
| 重复出现的变化 | 优先核对 |
|---|---|
| HTTP和HTTPS来回切换 | 代理、Nginx、应用的站点URL和强制HTTPS规则是否一致。 |
| 带www与不带www互相跳转 | 各层是否指定了不同的主域名。 |
| 同一路径不断添加、删除末尾斜杠 | 应用路由规范与代理重写是否相反。 |
| 同一个HTTPS地址反复返回跳转 | 应用是否误判原始协议，也检查认证与会话逻辑。 |
| 登录页与业务页交替出现 | Cookie是否保存并发送、域名和路径是否正确、会话是否有效。 |
状态码或 Server 响应头不能单独证明是哪一层生成了跳转。按同一请求时间核对入口日志、源站日志和应用日志，并检查实际生效的站点配置，避免改到另一份同名文件。
前面有代理时，比较公网入口和源站
若当前 Nginx 在服务器本机提供 443，并拥有匹配域名的可信证书，可在这台服务器上这样检查源站第一跳：
curl -q --noproxy '*' -sS --max-time 15 -D - -o /dev/null \
--resolve 'www.example.com:443:127.0.0.1' \
'https://www.example.com/'--resolve改变本次连接地址，同时保留域名用于 Host 和 TLS 校验；这里用 --noproxy确保直接连接本机，不被终端代理带到其他入口。仅监听指定地址时，按真实监听调整，不据本机拒绝连接就断定公网故障。源站使用私有CA时应提供正确的可信CA文件，不能关闭验证。
公网循环、源站正常，优先检查入口的重定向及其缓存；两边都循环，继续查源站和应用。此对照只针对当前检查的节点，多源站还需确认请求实际落到哪台机器。
如果外层已经处理 HTTPS，转到源站却是 HTTP，应用可能把请求再次跳到原来的 HTTPS 地址。需要让代理链正确传递原始协议，并让应用只信任实际代理来源；也可以在支持的部署中正确启用并校验入口到源站的 HTTPS。不能把“信任所有转发头”或“关闭HTTPS”当成统一修复。
规则改完，分别验收公开页面和登录流程
修改前保存涉及的站点、代理和应用 URL 配置，每次只处理已经定位的冲突。系统 Nginx 修改后先检查再重载；由面板管理时使用对应入口：
sudo nginx -t && sudo systemctl reload nginx修复后重复前面的检查，确认 HTTP、HTTPS、主域名及备用域名最终收敛到同一正确入口，原路径和必要参数仍保留。再从浏览器检查首页、内页、登录和退出，不能只凭首页返回 200 结束验收。统一入口的配置思路可参考HTTPS 配置指南；WordPress 另需核对站点地址与HTTPS设置。
只在某个浏览器出现时，用新的隐私窗口做对照，并查看浏览器是否使用缓存的永久跳转、HSTS或特定Cookie。HSTS的HTTP升级可能发生在浏览器内部，和服务端返回一条301不同；不要为排查删除整站的安全策略。确认源头已修复后，再有针对性处理受影响的缓存或会话。
匿名 curl 跳到登录页本身可以是正常行为；登录后的循环仍需用测试账号验证。支付回调、API等入口还涉及请求方法和参数，不要用真实交易反复试跳转。