网站提示ERR_TOO_MANY_REDIRECTS怎么办？从响应头找出重定向死循环

浏览器提示 ERR_TOO_MANY_REDIRECTS 时，页面往往连错误内容都加载不出来。删除 Cookie 或清理缓存有时会让现象短暂变化，但如果服务端仍在把请求来回跳转，换浏览器后还会再次出现。

我处理这类问题时不会先改 Nginx，也不会先停用全部插件，而是先把跳转链还原出来。只有知道每一次响应把请求送到了哪里，才能判断循环发生在哪一层。

先用响应头确认循环方向

在任意能够访问目标域名的终端执行：

curl -I http://example.com
curl -I https://example.com

重点看状态码和 Location。下面是一个经过简化的示例：

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

HTTP/2 302
Location: http://example.com/

第一条把 HTTP 跳到 HTTPS，第二条又把 HTTPS 跳回 HTTP，循环已经形成。此时继续增加强制 HTTPS 规则只会叠加问题。

需要查看多次跳转时，可以限制次数并输出过程：

curl -IL --max-redirs 10 https://example.com

-L 会跟随跳转，--max-redirs 10 用来避免命令无限跟随。测试生产站时只需要请求响应头，不要用高并发工具反复压测。

用不同入口确定是哪一层返回重定向

一条网站请求可能依次经过 CDN、负载均衡、Nginx、Apache、PHP 和 WordPress。浏览器只显示循环结果，不会说明是哪一层写入了 Location。

如果服务器允许，可以在源站本机指定域名访问：

curl -I http://127.0.0.1 -H 'Host: example.com'

这条命令里的英文引号属于 Shell 语法。若源站本机没有循环，而公网域名有循环，重点检查 CDN、代理协议模式和边缘重定向规则。若本机也循环，继续检查 Web 服务器与应用配置。

这里有一个处理边界：源站按域名区分虚拟主机时必须保留正确的 Host；HTTPS 虚拟主机还涉及 SNI 与证书，不能简单把域名替换为 IP 就认为测试结果等价。必要时可以使用 curl --resolve 把域名临时指向源站 IP。

Nginx规则是否把同一个请求反复改写

Nginx 的 return 和 rewrite 都能产生跳转。配置里同时存在 HTTP 转 HTTPS、裸域转 www、路径补斜杠和面板自动规则时，很容易让两个 server 块互相打架。

先导出 Nginx 当前真正加载的配置：

sudo nginx -T

再查找可能产生外部跳转的规则：

sudo nginx -T 2>&1 | grep -nE 'return 30[1278]|rewrite'

不要只检查某一个站点配置文件。nginx -T 会展开被加载的配置，更容易发现面板生成文件、公共 include 或重复 server 块。

修改前先备份相关配置，完成后执行：

sudo nginx -t
sudo systemctl reload nginx

只有语法检查通过后才应重新加载。 直接重启 Nginx 不会修复循环，反而可能让原本还能提供静态页面的服务一起中断。

WordPress地址与代理协议不一致

WordPress 会根据站点地址以及它看到的请求协议生成跳转。反向代理在前端终止 HTTPS，再使用 HTTP 连接后端时，如果没有正确传递原始协议，WordPress 可能认为当前请求仍是 HTTP，于是再次要求跳转到 HTTPS。

先检查 WordPress 的站点地址是否一致：

wp option get home
wp option get siteurl

这两项不一定在所有架构中完全相同，但协议、域名或目录设置错误时，应先核对真实部署方式，不要盲目在数据库里批量替换。

代理层还应正确传递原始协议信息。Nginx 反向代理常见配置包含：

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;

仅添加请求头并不保证应用一定识别。应用或框架还需要信任指定的代理来源，否则攻击者可能伪造请求头。处理边界是同时配置代理发送与应用可信代理，两端缺一不可。

CDN的HTTPS模式可能与源站规则冲突

CDN 面板里的强制 HTTPS、回源协议和源站自身跳转规则如果组合不一致，也会形成循环。典型现象是公网访问循环，但绕过 CDN 访问源站正常。

检查时应记录当前设置，再一次只修改一个变量。重点核对：

• 访客到 CDN 使用的协议
• CDN 到源站使用的协议
• 边缘是否启用 HTTP 转 HTTPS
• 源站是否再次根据收到的协议执行跳转

不要同时关闭 CDN、删除 Nginx 规则并修改 WordPress 地址。这样即使网站恢复，也无法确定根因，下一次重新开启某个功能时还会复发。

如果源站已经提供有效 HTTPS，更稳妥的方向是让回源协议与外部协议保持一致，并明确只在一个位置执行规范化跳转。具体选项名称会因 CDN 服务商不同而变化，应以当前控制台说明为准。

清Cookie为什么不是主要修复方法

会话插件、登录系统或语言插件可能根据 Cookie 跳转，因此只在某个浏览器、某个账号出现循环时，清理站点 Cookie 有排查价值。

但使用 curl -I 在无登录状态下仍能复现循环，就说明服务端已经给普通请求返回了重复跳转。此时清 Cookie 只能改变客户端状态，不能修复 Nginx、WordPress 或 CDN 之间的协议判断冲突。

同样不建议一开始就停用全部插件。更好的顺序是先观察跳转路径是否与登录、语言、移动端或缓存规则有关，再对对应模块做最小范围验证。

修改后的验收不能只看首页

修复后先重新执行：

curl -IL --max-redirs 10 http://example.com
curl -IL --max-redirs 10 https://example.com

理想结果不是完全没有跳转，而是跳转路径能够在有限步骤内稳定到达最终页面。例如 HTTP 到 HTTPS 一次、裸域到规范域名一次，随后返回 200 或业务本身预期的状态码。

还要分别检查首页、后台登录页、一篇文章页和原本触发问题的具体路径。WordPress 后台、语言目录或带查询参数的页面可能使用不同规则，只验证首页容易漏掉局部循环。

最后查看 Nginx 访问日志，确认同一请求没有在两个 URL 之间持续出现 301 或 302。如果站点位于 CDN 后面，再清理相关缓存并等待配置生效，然后从公网复测。

保留一份可回滚的重定向清单

网站的重定向可能分散在 CDN、Nginx、应用和插件中。每层单独看都合理，组合在一起却可能互相覆盖。上线前最好列出每条跳转的来源、匹配条件、目标地址和预期状态码。

新增规则时先使用临时跳转状态验证，确认路径正确后再决定是否改成长期缓存的永久跳转。浏览器和 CDN 可能缓存永久跳转，错误规则一旦扩散，修复后的观察会变得更困难。

这类故障真正有效的处理方法，是用响应头找出循环的两个端点，再只修改负责错误判断的那一层。验收标准是完整跳转链有限、方向唯一、最终状态正确，并且源站与公网结果都符合预期。