出现“重定向次数过多”错误是什么意思？
当您尝试访问某个网页时，浏览器可能会显示一个错误页面，提示“重定向次数过多”（或类似的错误信息，例如 Chrome 中的 ERR_TOO_MANY_REDIRECTS，Firefox 中的“页面未正常重定向”）。这表示您的浏览器在尝试加载该网页时，被连续引导从一个网址跳转到另一个网址，这个跳转链条没有终点，形成了一个循环。
浏览器为了防止这种无限循环导致资源耗尽或程序崩溃，设置了一个最大重定向次数的限制（通常在 10 到 20 次之间）。一旦实际的重定向次数超过了这个限制，浏览器就会中断访问，并显示这个错误信息，阻止页面内容的正常显示。简单来说，就是您的浏览器被困在一个没有出口的跳转迷宫里了。
为什么会出现重定向循环？
重定向的目的是将访问者从旧的或不正确的网址引导到新的或正确的网址。例如，您可能设置了将 HTTP 版本的页面重定向到 HTTPS 版本，或者将带 www 的网址重定向到不带 www 的网址。通常情况下，重定向是单向且最终会到达目标页面的。
然而，当两个或多个重定向规则相互冲突或配置不当，就会形成循环。想象一下，规则 A 说“把所有到网址甲的访问重定向到网址乙”，而规则 B 说“把所有到网址乙的访问重定向回网址甲”。当有人访问网址甲时，他会被重定向到乙，然后又被重定向回甲，如此反复，形成无限循环。
常见导致重定向循环的原因包括：
- 服务器配置错误：在服务器配置文件（如 Apache 的 .htaccess 文件或 Nginx 的配置文件）中设置了相互冲突或错误的重定向规则。
- 网站平台（CMS）设置问题：在使用 WordPress、Joomla 等内容管理系统时，网站地址（URL）设置与实际访问协议（HTTP/HTTPS）或域名（www/非www）不匹配。
- 插件或主题冲突：某些网站插件（尤其是处理 SSL、安全或重定向的插件）或主题中的代码与服务器配置或其他插件发生冲突，导致重定向问题。
- CDN 或缓存服务配置不当：如果您使用了内容分发网络（CDN，如 Cloudflare）或服务器级缓存服务，其设置可能与您的源站服务器配置冲突，尤其是在处理 HTTPS 时。
- 强制 HTTPS 配置错误：设置了强制 HTTPS 的规则，但同时又存在将 HTTPS 重定向回 HTTP 的规则，或者源服务器本身不支持 HTTPS 却强制重定向到 HTTPS。
- 网站数据库中的网址问题：网站数据库中存储的网站 URL 与当前访问方式不一致。
如何诊断和找到重定向循环的源头？
解决重定向循环的关键在于找到是哪个环节导致了循环。这需要一个系统性的诊断过程。
第一步：清除浏览器缓存和Cookie
有时候，问题可能仅仅是由于您浏览器中存储了过时或损坏的缓存和 Cookie 数据。这些旧数据可能会干扰正常的重定向过程。
操作方法：进入您的浏览器设置，找到清除浏览数据或历史记录的选项，选择清除缓存文件和 Cookie。然后尝试重新访问该页面。如果问题解决，那么原因就在于本地浏览器数据。
第二步：使用不同的浏览器或隐身/无痕模式
这有助于判断问题是否特定于您当前使用的浏览器或其配置。
操作方法：尝试用另一个之前没有访问过该网站的浏览器访问，或者在您当前的浏览器中打开一个隐身/无痕窗口进行访问。如果在新环境或模式下访问正常，说明问题可能与您常用浏览器的设置、扩展程序或缓存有关。
第三步：检查网址拼写
尽管这听起来很简单，但输入错误的网址有时也会意外触发重定向，尽管不太可能导致“次数过多”的循环，但排除简单的可能性总是有益的。
第四步：利用在线重定向检查工具
有些在线工具可以模拟访问您的网址，并显示完整的重定向链条。这能帮助您看到访问是从哪个网址开始，经过了哪些中间网址，最终停在了哪里（或进入了循环）。
操作方法：在网上搜索“在线重定向检查工具”或“redirect checker”，输入您出现问题的网址进行检查。观察工具输出的重定向路径，看是否有某个网址反复出现，或者路径没有最终目的。
第五步：使用浏览器开发者工具
这是诊断复杂重定向问题的强大手段。通过开发者工具，您可以查看浏览器发送和接收的所有网络请求，包括重定向。
操作方法：
- 打开您出现问题的页面。
- 按下键盘上的 F12 键（或右键点击页面，选择“检查”或“审查元素”）。
- 切换到“Network”（网络）标签页。
- 如果该标签页是空的，请刷新页面（可能需要勾选“Preserve log”或“禁用缓存”）。
- 观察请求列表。您会看到多个带有 301 或 302 状态码的请求，这些就是重定向。
- 仔细查看这些重定向请求的 URL。如果看到浏览器在两个或多个 URL 之间反复跳转（例如从 A 到 B，又从 B 回到 A），那么您就找到了循环的直接证据，以及参与循环的 URL。
- 记录下参与循环的 URL，这有助于您定位到是哪个配置或代码引起的。
具体的解决方法：如何解除重定向循环？
找到问题源头后，就可以针对性地解决。以下是针对常见原因的解决方法：
方法一：检查并修正网站URL设置（尤其是CMS用户）
对于使用 WordPress 等 CMS 的网站，核心的网站地址设置至关重要。
对于 WordPress 用户：
- 登录到您的 WordPress 后台（如果能够登录）。
- 前往 设置 > 常规。
- 检查“站点地址（URL）”和“WordPress 地址（URL）”这两个字段。
- 确保这两个 URL 是正确的，并且在协议（HTTP 或 HTTPS）和域名格式（带 www 或不带 www）上保持一致，与您希望访问者实际使用的地址一致。
- 例如，如果您网站使用 HTTPS 并带 www，那么两个地址都应该是
https://www.yourwebsite.com。 - 如果您无法登录后台，可能需要通过修改数据库（如使用 phpMyAdmin）或在 wp-config.php 文件中强制定义这些 URL 来修复。
通过 wp-config.php 修复 URL：
使用 FTP 或文件管理器编辑网站根目录下的
wp-config.php文件，在文件顶部添加以下两行（替换为您的实际 URL）：define('WP_HOME','https://www.yourwebsite.com'); define('WP_SITEURL','https://www.yourwebsite.com');添加后，WordPress 后台的这两个字段会变灰不可编辑，以防止再次被意外修改。
方法二：检查和修改服务器配置文件（如 .htaccess）
这是导致重定向循环最常见的原因之一，尤其是在设置 HTTPS 或 www/非www 重定向时。
对于 Apache 服务器（使用 .htaccess）：
- 使用 FTP 客户端或您的主机控制面板提供的文件管理器连接到您的网站空间。
- 找到网站根目录下的
.htaccess文件。请在修改前备份此文件！ 这是非常重要的一步。 - 使用一个文本编辑器打开
.htaccess文件。 - 仔细检查文件中的重定向规则。这些规则通常包含
Redirect或RewriteRule字样。 - 特别查找那些可能将流量从 HTTPS 重定向回 HTTP，或者将 www 重定向到非 www，同时另一个规则又在尝试做相反操作的规则。
- 例如，您可能有一个规则将所有 HTTP 重定向到 HTTPS，但另一个规则错误地将某个特定页面从 HTTPS 重定向回 HTTP。
- 尝试定位有问题的规则： 如果您不确定是哪条规则，可以尝试暂时性地注释掉（在行首加上
#符号）最近添加的或看起来与重定向相关的规则，然后保存文件并测试网站。逐步取消注释，直到找到导致问题的规则。 - 或者，您可以尝试用一个已知的、有效的默认
.htaccess文件替换当前的，然后测试。如果问题解决，说明当前的.htaccess文件有问题。 - 一旦找到问题规则，请仔细修改它，确保它指向正确的最终目标，并且不会与现有规则形成循环。常见的错误是重复的或相互矛盾的 HTTPS/www 重定向规则。
重要警告： 修改 .htaccess 文件可能导致网站无法访问甚至服务器错误。操作前务必备份，并在有经验的情况下进行修改。如果您不确定，最好寻求专业人士的帮助。
方法三：检查和管理网站插件或主题
某些插件（如 SSL 证书安装插件、安全插件、缓存插件或专门的重定向管理插件）或主题中的功能可能会介入重定向过程并导致循环。
对于 WordPress 用户：
- 如果能够登录 WordPress 后台：前往 插件 > 已安装的插件。
- 暂时停用所有插件： 批量选择所有插件，然后从批量操作下拉菜单中选择“停用”，点击“应用”。
- 停用所有插件后，尝试访问出现问题的页面。
- 如果问题解决，说明是某个插件引起的。现在，一个一个地重新启用插件，每启用一个就测试一次网站。当您启用某个插件后问题再次出现，那么该插件就是罪魁祸首。
- 找到问题插件后，您可以尝试更新它、查找其配置中是否存在重定向相关的错误设置、联系插件开发者寻求支持，或者寻找替代插件。
- 如果无法登录 WordPress 后台： 使用 FTP 或文件管理器，找到
wp-content目录。将plugins目录重命名为其他名称（例如plugins_old）。这会强制 WordPress 认为所有插件都被禁用了。然后尝试访问网站。如果问题解决，说明是插件问题。然后将目录名改回plugins，进入plugins目录，一个一个地重命名里面的子目录来隔离问题插件。 - 检查主题： 如果停用插件后问题仍然存在，尝试暂时切换到 WordPress 的默认主题（如 Twenty Twenty-One, Twenty Twenty-Two 等）。如果切换主题后问题解决，说明问题可能出在您当前使用的主题上。
方法四：检查CDN或缓存服务设置
如果您使用了 Cloudflare 等 CDN 服务，或者 LiteSpeed Cache 等服务器级缓存，它们的设置可能会影响重定向。
对于使用 Cloudflare 的用户：
一个非常常见的问题是 Cloudflare 的 SSL 设置与源服务器的 SSL 配置不匹配。
- 登录到您的 Cloudflare 账户。
- 选择您的网站。
- 前往 SSL/TLS 设置页面。
- 检查您的 SSL 加密模式。
- 灵活（Flexible）： Cloudflare 到访客之间使用 HTTPS，但 Cloudflare 到您的源服务器之间使用 HTTP。如果您的源服务器也强制将 HTTP 重定向到 HTTPS，就会形成 Cloudflare (HTTPS) -> Origin (HTTP) -> Origin (HTTPS) -> Cloudflare (HTTPS) 的循环。
- 完全（Full）： Cloudflare 到访客使用 HTTPS，Cloudflare 到源服务器也使用 HTTPS，但不验证源服务器证书。
- 完全（严格）（Full (strict)）： Cloudflare 到访客使用 HTTPS，Cloudflare 到源服务器使用 HTTPS，并验证源服务器证书。
- 如果您的源服务器已经正确配置了 HTTPS 并安装了有效证书，建议将 Cloudflare 的 SSL 模式设置为“完全（Full）”或“完全（严格）（Full (strict)）”。如果设置为“灵活”且源服务器强制 HTTPS，很容易出现循环。
- 此外，检查 Cloudflare 的“页面规则（Page Rules）”，看是否有设置了导致循环的重定向规则。
- 在 Cloudflare 后台清除网站缓存（Purge Cache）。
如果您使用了其他 CDN 或缓存服务，请查阅其文档，检查与 SSL、重定向或缓存相关的设置，并尝试清除缓存。
方法五：清除网站缓存
如果您的网站使用了缓存插件（如 WP Super Cache, W3 Total Cache）或服务器级的缓存机制，在修改了网站配置或文件后，旧的缓存可能仍然导致重定向到错误的地方。
操作方法： 登录到您的网站后台或主机控制面板，找到缓存管理选项，执行“清除所有缓存”或“刷新缓存”操作。
方法六：检查是否有恶意软件
虽然不常见，但恶意软件或病毒代码也可能注入到您的网站文件中，插入恶意的重定向代码，从而导致循环或其他问题。
操作方法： 使用安全扫描工具扫描您的网站文件，或者联系主机提供商寻求帮助，他们通常有工具可以检测和清理恶意代码。
浏览器允许多少次重定向？
如前所述，浏览器对连续的重定向次数设置了限制，以防止无限循环。这个具体的数字没有一个严格的国际标准，不同的浏览器可能会有略微不同的实现。
通常，这个限制在 10 到 20 次 之间。例如，Chrome 浏览器通常在达到 20 次重定向时会显示“ERR_TOO_MANY_REDIRECTS”错误。Firefox 也类似，会在达到某个阈值时显示“页面未正常重定向”。
这个限制是为了保护用户和服务器资源。如果没有限制，一个错误的重定向循环会让浏览器不断地向服务器发送请求，消耗大量的计算资源和网络带宽，最终可能导致浏览器或服务器崩溃。
如何避免将来出现重定向问题？
预防总是好于修复。遵循一些最佳实践可以大大降低出现重定向循环的风险：
- 统一网址规范： 在网站建设初期就确定是使用 HTTP 还是 HTTPS，带 www 还是不带 www，并在所有相关设置（CMS、服务器配置、CDN）中保持一致。
- 谨慎设置重定向： 在添加新的重定向规则（无论是通过 .htaccess、插件还是其他方式）时，要仔细检查规则是否正确，并测试新规则是否会与现有规则冲突。
- 使用可靠的插件和主题： 下载插件和主题时，优先选择那些评价好、更新及时、来源可靠的。避免安装过时或不明来源的插件。
- 测试更改： 在对网站进行任何涉及 URL、SSL、重定向或缓存的配置更改后，务必彻底测试网站，包括首页和几个内页，检查是否存在重定向问题。
- 备份文件： 在修改服务器配置文件（如 .htaccess）、主题或插件文件之前，务必进行备份。这样如果出现问题，可以快速恢复到之前的状态。
- 理解配置规则： 如果您需要手动编辑服务器配置文件，花时间了解其中规则的含义，尤其是正则表达式，可以避免很多错误。
总结
“重定向次数过多”是一个令人沮丧的错误，因为它阻止了页面的正常加载。解决它的关键在于系统性地诊断问题，从简单的浏览器缓存开始，逐步检查网站的各个层面：服务器配置 (.htaccess)、CMS 设置、插件冲突、CDN 或缓存设置，直到找到导致循环的根本原因。一旦定位了问题，修正相应的配置或代码通常就能解决问题。保持警惕并在进行重要更改前做好备份，是避免未来遇到此类问题的最佳策略。
