浏览器提示“重定向次数过多”，常见表现是页面始终打不开，清理 Cookie 后偶尔恢复，过一会儿又复发。故障通常来自几条互相矛盾的地址规则：一层要求使用 HTTPS，另一层又把请求送回 HTTP；或者 WordPress、Web 服务器和 CDN 对主域名的判断不一致。
排查需要记录实际跳转链，找出哪两个地址反复出现，再定位产生响应的层级。直接关闭 HTTPS 或反复清理全部缓存，可能让问题暂时消失，却留下登录安全和地址一致性风险。
本文面向使用 WordPress、Nginx 或 CDN 的网站管理者，命令仅用于检查示例。文中未对生产站点实施测试或修改。
记录每一跳的状态码与 Location
在浏览器开发者工具中打开 Network，启用保留日志后重现故障，观察文档请求的状态码和 Location。隐私窗口可帮助区分已有 Cookie 和缓存影响，但不能代替服务器端诊断。
也可以从终端查看不携带登录 Cookie 的公开页面请求。将域名替换为自己的站点。
curl -sS -D - -o /dev/null --max-time 20 https://example.com/
curl -sS -L -D - -o /dev/null --max-redirs 10 --max-time 30 https://example.com/
第一条只查看首次响应，第二条跟随跳转并输出各次响应头。到达跳转上限后 curl 会退出报错，这正好为记录链路设置边界。不要增加无限跳转，也不要使用 -k 绕过证书验证掩盖另一类问题。
这里使用 GET 并丢弃正文，比只用 HEAD 更接近普通页面访问；但它仍无法模拟浏览器已有 Cookie、JavaScript 跳转和完整登录流程。公开页面正常而登录后循环时，还需检查登录态、插件规则及响应中的 Cookie 行为。
重点记录反复出现的地址组合：
http与https来回切换，优先检查代理到源站的协议和应用 HTTPS 判断。- 裸域名与
www互相跳转，检查各层的规范域名规则。 - 登录地址与某个业务页面往返，检查登录 Cookie、权限插件及访问控制。
- 相同域名下斜杠或路径来回变化，检查伪静态、目录规则和应用规范化逻辑。
一次 HTTP 到 HTTPS 再到规范域名的跳转可以是正常行为。循环的特征是地址重复、请求无法稳定落到预期最终页面。
CDN 终止 HTTPS 后，源站可能只看见 HTTP
访客到 CDN 使用 HTTPS，不代表 CDN 到源站也使用 HTTPS。若代理以 HTTP 回源，而源站无条件将 HTTP 请求重定向到 HTTPS，访客再次请求后仍经同一条 HTTP 回源路径，就可能持续循环。
Cloudflare 官方文档列出了 Flexible 加源站 HTTPS 重定向等组合导致循环的情形，也说明了源站将 HTTPS 重定向到 HTTP 与端到端设置冲突的问题。[3] 其他代理产品需要对应检查回源协议、TLS 校验和转发配置，不能照搬某个厂商的模式名称。
计划使用端到端 HTTPS 时，应先确认源站证书有效、域名匹配、证书链完整，代理能够通过要求的校验，再调整回源设置。修改前保存当前模式、证书配置和重定向规则，安排可回退窗口。关闭证书校验或降级回源协议不应作为长期修复。
代理还需要准确传递访客原始协议，应用则应只信任受控代理提供的信息。X-Forwarded-Proto 是常见机制，但不能在公网直连源站的情况下，无条件相信客户端自己提交的同名头。
WordPress 的 HTTPS 判断需要与可信代理一致
WordPress 官方文档说明，在反向代理后使用 SSL 时，WordPress 可能需要借助转发协议头识别 HTTPS；如果识别失败，强制 HTTPS 的设置可能导致循环。[1]
处理前先核对网络边界。源站应通过防火墙、私网或其他控制仅接受预期代理的业务流量，代理需要覆盖或清洗外部传入的协议头。若采用多层代理，还需明确每层的传递格式与信任关系。
确认边界后，再依据 WordPress 官方文档和所用代理的说明配置协议识别。不能把一段读取请求头的 PHP 示例直接复制到所有服务器。头部可能采用单值或列表格式，配置位置、执行顺序及站点已有逻辑也会影响结果。
如果需要修改 wp-config.php，应先备份并保留安全访问途径，在测试环境验证 PHP 语法，再部署。故障时恢复本次变更的文件内容，不要同时改地址、禁用插件和切换 CDN 模式，否则难以判断是哪项产生效果。
检查 WordPress 地址，不要把两个字段强行设成一样
WordPress 地址通常对应程序文件所在位置，站点地址对应访客访问的站点入口。普通根目录安装中两者可能一致；将 WordPress 放在子目录、使用特定多站点或自定义架构时，两者可能有合理差异。[2]
在后台“设置 → 常规”中检查协议、域名、端口和子目录。如果后台无法访问，可在站点目录使用已安装的 WP-CLI 读取配置，命令需由有权限的运维人员在正确站点执行。
wp option get home
wp option get siteurl
还要检查 wp-config.php 是否定义了 WP_HOME 或 WP_SITEURL。这些常量会影响实际使用值，仅检查数据库并不充分。多站点应按网络配置和对应站点检查，不能将单站点修改步骤直接套用。
改地址可能导致后台退出、Cookie 失效或资源路径变化。修改前备份数据库与配置文件，记录原值；涉及迁移后的内容链接，应采用支持序列化数据的工具和迁移流程，避免直接全库文本替换。
主域名和路径规则需要在各层保持同一方向
例如 CDN 要求 example.com 跳到 www.example.com，而 Nginx 或 WordPress 又要求反方向，单看任何一条规则都可能合理，合在一起就无法结束。
将 CDN 重定向、负载均衡规则、Nginx 或 Apache 配置、WordPress 地址和重定向插件列在同一张检查记录中。每条记录标明匹配条件、目标协议、域名、路径及是否保留查询参数。
规范地址应有清楚的责任层级。保留必要规则，同时让其他层采用相同方向。不要未经检查就删除全部重定向，旧链接、登录路径和迁移后的 SEO 跳转可能仍依赖这些规则。
修改 Nginx 前保存相关配置，执行 nginx -t 通过后再按现有流程加载；使用 Apache 时检查实际虚拟主机及 .htaccess。配置检查通过只代表语法可接受，最终跳转方向仍要用实际请求验证。
缓存与插件应在规则修正后处理
永久重定向可能被浏览器或中间缓存保留，已有 Cookie 也可能触发不同的应用逻辑。可比较隐私窗口、无 Cookie 的 curl 请求和正常登录浏览器的结果，确定差异来自哪里。
服务端规则改正后，再按影响范围刷新相关 URL 的 CDN 或页面缓存，并重新测试。不要把 HSTS 当作普通缓存随意关闭，它用于强制浏览器使用 HTTPS，关闭安全策略不能修复源站或应用的协议判断错误。
怀疑插件时，优先在测试环境逐项验证重定向、SSL、缓存和安全插件。生产站直接禁用所有插件可能使登录保护、支付或表单功能失效。必须线上调整时，记录插件状态并采用最小范围操作，保留回退步骤。
验收需要覆盖登录和不同入口
修复后分别测试 HTTP 与 HTTPS、裸域名与 www、首页、文章页、后台及登录后页面。预期入口应有限次跳转到同一规范地址，最终返回该页面合理的响应；不要把所有路径都强制跳到首页来制造表面恢复。
继续检查登录 Cookie 的安全属性、退出登录、表单提交、静态资源和带查询参数的链接。涉及重定向状态码时，还应确认请求方法处理是否满足业务，尤其避免只测 GET 就认为提交接口也正常。
若修改后出现新的登录或证书故障，恢复本次变更的配置与原值，按记录逐层排查。最终需要保留一条可解释的跳转链，以及明确的代理信任和协议配置。浏览器不再报错只是恢复的第一项证据。
参考资料
资料核验日期：2026 年 10 月 28 日。具体菜单和行为以部署版本及代理产品文档为准。
[1] WordPress 官方：HTTPS 与反向代理配置。https://developer.wordpress.org/advanced-administration/security/https/
[2] WordPress 官方：迁移及 WordPress 地址、站点地址配置。https://developer.wordpress.org/advanced-administration/upgrade/migrating/
[3] Cloudflare 官方：重定向次数过多的模式冲突与诊断。https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/