修复主机上的重定向循环 (ERR_TOO_MANY_REDIRECTS)

当您打开网站时看到 "ERR_TOO_MANY_REDIRECTS" 或"此网页无法正常运作——重定向次数过多"，这就是重定向循环。网站迁移、安装 SSL 或启用 Cloudflare 后经常出现这种问题。本文将逐一解释原因并提供修复方法，帮您一次性解决。

什么是重定向循环

重定向循环是指浏览器在多个 URL 之间被无限重定向，始终无法完成加载——例如 A 跳转到 B，B 又跳回 A，如此反复。浏览器有重定向次数限制（通常约 20 次），超过后便停止加载并显示 ERR_TOO_MANY_REDIRECTS 错误。几乎所有情况都源于服务器或应用层面的重定向规则冲突。

最常见的原因

• .htaccess 规则冲突 — 同时强制 www 和 non-www，或存在重复的 HTTP→HTTPS 规则。
• WordPress 网址设置错误 — siteurl 和 home 设置为 HTTPS，但服务器实际上并未启用 HTTPS。
• Cloudflare Flexible SSL — Cloudflare 使用 HTTP 连接源服务器，但服务器将请求重定向到 HTTPS。
• 强制 HTTPS 插件 — 类似 Really Simple SSL 的插件与 .htaccess 规则重复。
• 过期的 Cookie — 浏览器中缓存了旧的重定向 Cookie。

深入了解每种常见原因

在开始修复之前，了解每种原因的成因很有帮助。几乎每个重定向循环都归结为"两方对网站应通过 HTTP 还是 HTTPS、www 还是 non-www 提供服务存在分歧"。当两个层次——例如 Cloudflare 与您的服务器，或 .htaccess 规则与插件——各自尝试向不同方向重定向时，请求就会被无限弹来弹去。以下是每种情况的具体成因及识别方法。

Cloudflare SSL 处于 Flexible 模式

这是我们最常见的原因。当 SSL/TLS 设置为 Flexible 时，Cloudflare 接受访客的 HTTPS 请求，但通过普通 HTTP 与源服务器通信。如果服务器有"若请求为 HTTP 则重定向到 HTTPS"的规则，服务器收到 Cloudflare 的 HTTP 请求后会让其跳转到 HTTPS——但 Cloudflare 又将其转回 HTTP 重新发送，形成无限循环。一个明显特征是：暂停 Cloudflare（灰色云 DNS）后循环消失，重新启用代理（橙色云）后循环恢复，这直接指向 SSL 模式问题。

.htaccess 规则冲突

许多网站随时间积累了多个重定向块——一个强制 www，另一个强制 non-www，或一个强制 HTTPS 但写法宽松到与另一条规则冲突。这在安装插件、迁移主机或从其他网站复制规则而未删除旧规则后尤为常见。结果是 A → B，然后立即 B → A。

WordPress 网址设置错误

WordPress 数据库中的 siteurl 和 home 值告诉网站它应该使用哪个 URL。如果它们被设置为 https://，而服务器实际上并未提供 HTTPS（或 Cloudflare 处于 Flexible 模式），WordPress 会尝试将每个请求重定向到 HTTPS，而服务器则将其视为 HTTP 并弹回，产生循环。典型症状是前端加载正常，而 /wp-admin 循环，或者反过来。

www 与 non-www 冲突

如果您设置 www.yourdomain.com 重定向到 yourdomain.com，而另一条规则（或 CMS 设置）又将 yourdomain.com 推回 www，两条规则就会相互冲突。请求在两个主机名之间来回弹跳，直到浏览器放弃。解决方法是选择一个方向并删除相反的规则。

逐一修复

情况 1 — 首先检查 .htaccess

在 DirectAdmin 中打开文件管理器，查看 public_html 中的 .htaccess 文件。如果发现同时强制 www 和 non-www 的规则，只保留一个方向。以下是一个不会产生循环的正确 non-www + HTTPS 规则：

关键是将所有条件保留在单个规则中，而不是拆分成多个会来回弹跳请求的块。

情况 2 — WordPress

对于 WordPress 网站，在数据库中检查网址设置。在 phpMyAdmin 中打开 wp_options 表，确保 siteurl 和 home 一致（如果使用 SSL 则都为 https）。或在 wp-config.php 中硬性锁定：

情况 3 — Cloudflare

如果您使用 Cloudflare，前往 SSL/TLS → 概述，将模式从 Flexible 更改为 Full 或 Full (strict)。Flexible 模式让 Cloudflare 使用 HTTP 连接服务器，而服务器强制 HTTPS，导致循环——Full 模式使两端都统一使用 HTTPS。

情况 4 — 清除 Cookie 和缓存

修复服务器端问题后，清除该域名的浏览器 Cookie 和缓存，或在无痕窗口中测试以确认循环已真正消除。

使用开发者工具和 curl 查看重定向链

找到循环发生位置最快的方法是查看重定向链——即请求被转发的有序列表。两种工具可以立即提供这些信息。

在浏览器开发者工具中查看

按 F12 打开开发者工具，前往 网络 标签，勾选 保留日志，这样页面重定向时日志不会被清除。输入 URL 并按 Enter。您会看到堆叠的请求列表；每一行带有 301 或 302 状态的就是一次重定向。点击某行并在响应标头中查看 Location 字段，即可看到请求被发送到哪里。如果目标 URL 不断返回相同的值，那就是循环所在。

在命令行中使用 curl 检测

如果您偏好命令行，curl 可以提供干净的重定向链，不受浏览器缓存干扰。使用 -I 只获取标头，使用 -L 跟踪每次重定向：

输出显示每次跳转的状态和 Location:。在循环中，您会看到 Location 在相同 URL 之间永远交替，curl 会自行停止并显示 Maximum (50) redirects followed。循环示例：

这清楚地显示 yourdomain.com 和 www.yourdomain.com 互相冲突，意味着存在两条 www/non-www 规则冲突——只保留一个方向。若要一目了然地查看跳转次数和 HTTP 代码，请使用：

学会读懂重定向链是解决此问题最有用的技能。一旦知道哪个 URL 指向哪里，您就能直接追溯到问题规则，而无需逐一猜测修复。

如何防止再次发生

• 选择一个规范方向——www 或 non-www、HTTP 或 HTTPS——将重定向合并为单个规则。
• 不要同时运行强制 HTTPS 插件和执行相同功能的 .htaccess 规则。
• 安装真实的服务器 SSL 证书（Let's Encrypt），而不是依赖 Cloudflare Flexible。
• 每次修改前备份 .htaccess，以便出现问题时立即回滚。
• 迁移网站或更换域名后，每次都要重新检查 siteurl/home 和重定向规则——不要不加审查地复制旧规则。
• 启用 Cloudflare 时，从一开始就将 SSL/TLS 设置为 Full (strict) 并安装真实的源证书；这可以从根源防止循环。
• 每次修改重定向后，在结束前用 curl -sIL 测试，确认链路以 200 结束而非循环。

常见问题解答