15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用
31.10.2024
1 +1
Category icon安全 Category icon管理

如何修复”重定向过多”错误：完整故障排除指南

“过多重定向”错误——也称为重定向循环——是网站所有者或管理员可能遇到的最令人沮丧的问题之一。您的浏览器尝试跟随一系列 HTTP 重定向，陷入无限循环，最终放弃，让访问者看到错误页面而不是您的内容。

在这份全面指南中，您将了解到底是什么导致重定向循环、如何系统地诊断它们，以及如何应用正确的修复——无论您运行的是 WordPress 站点、VPS Hosting 计划上的自定义应用程序，还是共享网络托管上的简单站点。

“过多重定向”错误是什么？

当浏览器请求一个 URL 时，服务器可能会响应一个 HTTP 重定向（状态代码 301、302、307 或 308），指示浏览器加载不同的 URL。这是正常的预期行为——例如，将 HTTP 流量重定向到 HTTPS，或将 www 重定向到非 www。

当 URL A 重定向到 URL B，而 URL B 重定向回 URL A（或通过最终循环回来的更长链）时，就会发生重定向循环。在达到浏览器定义的阈值（通常为 10-20 次重定向）后，浏览器会中止请求并显示：

> ERR_TOO_MANY_REDIRECTS（Chrome）

> 页面重定向不正确（Firefox）

> 此网页有重定向循环（Safari/Edge）

无论浏览器如何，错误都是相同的——只是措辞不同。

“过多重定向”错误的原因是什么？

在尝试修复之前，理解根本原因至关重要。最常见的原因包括：

1. 重定向规则配置错误

最经典的例子：http://example.com 重定向到 https://www.example.com，同时 https://www.example.com 重定向回 http://example.com。每个重定向都会触发另一个，创建无限循环。

2. HTTP 到 HTTPS 重定向设置不当

如果您的服务器强制 HTTPS 但您的 SSL 证书配置未正确应用，服务器可能会将 HTTPS 请求重定向回 HTTP，在两个协议之间无限循环。

存储在浏览器中的过时 Cookie 或陈旧的缓存重定向数据可能会导致它跟随旧的、不正确的重定向路径——即使服务器端问题已解决。

4. CMS 配置错误（WordPress 和其他）

在 WordPress 中，数据库中的 WordPress 地址（URL）和站点地址（URL）字段必须与您的实际域名配置匹配。不匹配——例如，一个字段使用 http://example.com 而您的服务器强制 https://www.example.com——是重定向循环的常见原因。

5. 插件冲突

缓存插件、安全插件和 SEO 插件都可以实现自己的重定向逻辑。当两个或多个插件同时尝试管理重定向时，它们可能会冲突并创建循环。

6. 服务器级重定向冲突

在您的托管控制面板中配置的重定向可能与 .htaccess、Nginx 配置或您的 CMS 设置中定义的重定向冲突，导致相互矛盾的指令无限循环。

如何修复”过多重定向”错误：分步指南

按顺序执行这些方法。在进行服务器级更改之前，先从最简单的修复开始。

在触及任何服务器配置之前，先排除浏览器端问题。陈旧的 Cookie 和缓存的重定向响应是一个令人惊讶的常见原因。

Google Chrome：

  1. 按 Ctrl+Shift+Delete（Windows/Linux）或 Command+Shift+Delete（Mac）
  2. 将时间范围设置为所有时间
  3. 检查 Cookie 和其他网站数据和缓存的图片和文件
  4. 点击清除数据

Mozilla Firefox：

  1. 转到设置 → 隐私和安全
  2. 在 Cookie 和网站数据下，点击清除数据
  3. 选择两个选项并确认

Microsoft Edge / Safari：

在每个浏览器的隐私设置中遵循等效步骤。

清除后，重新加载页面。如果错误消失，问题是浏览器端的。如果它仍然存在，继续下一个方法。

> 专业提示：立即在私密/隐身窗口中测试 URL。隐身模式不使用任何缓存数据或 Cookie，所以如果站点在那里正确加载，问题肯定是浏览器端的。

方法 2：检查 CMS URL 设置（WordPress）

如果您运行 WordPress，不正确的 URL 设置是重定向循环最常见的原因之一。

通过 WordPress 管理仪表板：

  1. 导航到设置 → 常规
  2. 验证 WordPress 地址（URL）和站点地址（URL）都相同，并使用正确的协议（http:// 或 https://）和子域（www 或非 www）
  3. 保存更改

如果您无法访问管理仪表板（因为重定向循环阻止登录），通过 FTP 或您的托管文件管理器直接编辑 wp-config.php 文件：

define(‘WP_HOME’, ‘https://www.example.com’);
define(‘WP_SITEURL’, ‘https://www.example.com’);

将 https://www.example.com 替换为您的实际域名。这些常量会覆盖数据库值，并立即打破循环。

通过 WordPress 数据库（phpMyAdmin）：

  1. 打开 phpMyAdmin 并选择您的 WordPress 数据库
  2. 打开 wp_options 表
  3. 找到 option_name = siteurl 和 home 的行
  4. 确保两个值都与您的预期 URL 完全匹配

方法 3：临时禁用 WordPress 插件

缓存、安全和 SEO 插件在重定向冲突方面是常见的罪魁祸首。识别有问题插件的最快方法是一次性禁用所有插件。

如果您可以访问管理仪表板：

  1. 转到插件 → 已安装的插件
  2. 选择所有插件并从批量操作菜单中选择停用

如果您无法访问仪表板（重定向循环阻止登录）：

  1. 通过 FTP 或 SSH 连接到您的服务器
  2. 导航到 /wp-content/
  3. 将 plugins 文件夹重命名为类似 plugins-old 的名称
  4. WordPress 将自动停用所有插件

重新加载站点。如果错误消失，将文件夹重命名回 plugins 并一次一个重新激活插件，在每次激活后进行测试以识别冲突的插件。

常见的罪魁祸首包括：Really Simple SSL、Redirection、Yoast SEO、W3 Total Cache 和 Wordfence。

方法 4：审计您的 .htaccess 文件（Apache 服务器）

在基于 Apache 的服务器上，.htaccess 文件控制 URL 重写和重定向规则。此处冲突或重复的规则是重定向循环的常见原因。

访问 .htaccess：

  • 通过 FTP/SFTP：该文件位于您网站的根目录中（例如 /public_html/.htaccess）
  • 通过 cPanel 文件管理器：启用”显示隐藏文件”以查看 .htaccess

要查找的内容：

搜索 RewriteRule 和 RewriteCond 指令。查找可能创建循环逻辑的规则——例如，即使请求已经是 HTTPS，也会触发 HTTPS 重定向的规则。

HTTPS + www 的正确、非循环 .htaccess 配置：

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

关键原则：每个重定向规则必须包含一个条件，防止它在请求已经与目标匹配时触发。RewriteCond %{HTTPS} off 条件确保 HTTPS 重定向仅对 HTTP 请求触发——永远不会对 HTTPS 请求触发。

如果您不确定您的 .htaccess 规则，请临时将文件重命名为 .htaccess.bak。WordPress 和大多数 CMS 会自动重新生成一个干净的版本。

方法 5：检查控制面板中的服务器级重定向

许多托管控制面板（cPanel、Plesk、DirectAdmin）允许您独立于 .htaccess 文件或 CMS 配置重定向。这些服务器级重定向可能与应用程序级重定向冲突。

步骤：

  1. 登录您的托管控制面板
  2. 查找重定向部分（在 cPanel 中，它位于域 → 重定向下）
  3. 查看所有配置的重定向
  4. 删除任何与您的 CMS 或 .htaccess 已处理的重定向重复或矛盾的重定向

如果您在专用服务器上管理高流量站点，还要检查您的 Nginx 或 Apache 虚拟主机配置文件中可能与应用程序级规则冲突的重定向指令。

方法 6：验证您的 SSL/HTTPS 配置

如果重定向循环仅在 https:// URL 上发生，问题可能与您的 SSL 证书和 HTTPS 强制的配置方式有关。

常见场景：您的托管控制面板启用了”强制 HTTPS”，AND 您的 .htaccess 也包含 HTTP 到 HTTPS 重定向，AND 您的 CMS 有一个 HTTPS 插件处于活动状态。所有三个都同时触发并冲突。

修复：选择一个层来处理 HTTPS 重定向，并在所有其他层中禁用它。推荐的方法是在服务器级别（虚拟主机配置或控制面板）处理它，并从 .htaccess 和任何插件中删除它。

确保您的 SSL 证书有效且正确安装。过期或配置错误的证书有时会导致意外的重定向行为。如果您需要新证书，来自 AlexHost 的 SSL 证书易于部署和维护。

验证修复

应用上述任何修复后：

  1. 再次清除浏览器缓存和 Cookie（如果旧重定向被缓存，更改将不可见）
  2. 在隐身/私密窗口中测试以确认修复在没有任何缓存数据的情况下有效
  3. 使用在线重定向检查器，例如 Redirect Checker 或 httpstatus.io，来追踪完整的重定向链并确认没有循环
  4. 测试多个 URL 变体：http://example.com、https://example.com、http://www.example.com 和 https://www.example.com——所有四个都应解析为单个规范 URL，最多只有一个或两个重定向

如何在将来防止重定向循环

修复重定向循环是一回事——防止它再次发生是另一回事。遵循这些最佳实践：

建立单个规范 URL

明确决定您的域名的一种规范形式：http://example.com 或 https://www.example.com。配置每个层（服务器配置、.htaccess、CMS 设置、插件）中的所有重定向以指向此单一版本。记录您的决定，以便将来的更改不会无意中重新引入冲突。

仅在一个层实现重定向

不要在您的控制面板、.htaccess 和插件中同时配置相同的重定向。选择一个权威层并禁用其他层。这大大降低了冲突的风险。

最小化重定向链

每个重定向都会增加延迟并增加循环的风险。目标是直接重定向：example.com → www.example.com。避免链，如 example.com → www.example.com → https://www.example.com。Screaming Frog 等工具可以审计您的站点以查找重定向链。

在部署前测试

每当您添加新的重定向规则、切换到 HTTPS 或安装处理 URL 的新插件时，请先在暂存环境中彻底测试。单个配置错误的规则可能会导致整个站点离线。

保持您的 CMS 和插件更新

过时的插件更可能包含导致重定向冲突的错误。保持 WordPress 核心、主题和插件最新可以显著降低此风险。

结论

“过多重定向”错误几乎总是由您的网络堆栈的一个或多个层中的冲突重定向逻辑引起的——浏览器缓存、CMS 设置、插件、.htaccess 规则或服务器级配置。通过系统地执行本指南中的故障排除步骤，您可以精确定位循环的确切来源并快速解决它。

关键要点：

15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用