...
虚拟主机标志

识别和修复 WordPress 中的重定向循环 - 原因和解决方案

我将简明扼要地解释如何创建一个 重定向循环 WordPress 并可靠地分析和解决这些问题。针对 SSL 冲突、错误的 .htaccess 规则、不正确的网站 URL、缓存/cookies、插件问题和服务器设置，我将向您展示可立即实现的解决方案，包括测试和预防。

中心点

在我详细解释这些步骤之前，下面的列表总结了最重要的步骤。

  • 原因 快速缩小范围：SSL、.htaccess、URL、插件、缓存
  • 标准-检查规则：.htaccess 和 wp-config.php
  • HTTPS 正确设置：证书、混合内容、HSTS
  • 插件 在测试基础上关闭：通过仪表板或 FTP
  • 预防 建立：备份、文档、监控

重定向循环究竟是什么意思？

A 转发回路 当 URL A 跳转到 URL B，而 B 又跳转回 A，或多次跳转回到起始地址末尾时，就会出现这种情况。浏览器会以ERR_TOO_MANY_REDIRECTS取消并阻止调用。我通常会在正确输入后再次加载登录表单，从而识别出循环。对于访问者来说，这就像一个无休止的循环，而对于搜索引擎来说，这就像一个技术错误。这样做会降低信任度、阻止登录后台并占用宝贵的抓取预算。

WordPress 中出现循环的主要原因

我发现最常见的触发因素是 错误 WordPress URL、咄咄逼人的 .htaccess 规则、双重 SSL 强制或混乱的插件重定向。旧的 cookie 和浏览器缓存也会将请求送入歧途。域名变更或 HTTPS 转换后，由于 http 和 https 混用，错误会更频繁地发生。在自带重定向或安全插件的主题中，规则可能会相互屏蔽。在极少数情况下，恶意软件会故意设置重定向以锁定管理员。

在浏览器中进行快速测试：Cookie 和缓存

我从 客户-检查，因为它能在几分钟内使问题得到澄清。我删除受影响域的 cookie 和整个缓存。私人窗口有助于排除旧会话。如果登录成功，说明是本地数据而不是服务器的问题。如果错误继续发生，我就转到服务器和 WordPress 层面。

检查 .htaccess 并重置为默认值

我确保 .htaccess 并将其重置为 WordPress 标准作为测试。这就是我从以前的实验或搜索引擎优化规则中删除冲突重定向的方法。

# BEGIN WordPress
重写引擎开启
RewriteBase /
RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule.
# 结束 WordPress

一旦一切就绪并开始运行，我将逐步添加其他重定向。关于清洁条件，我参考 htaccess 重定向 并举例说明。重要提示：切勿强制使用两次 http→https，在服务器级别使用一次即可。

在设置和 wp-config.php 中自定义 WordPress 网址

之间的偏差 WP_HOME 和 WP_SITEURL 经常引发无休止的循环，尤其是在域名转移之后。我首先检查设置 > 常规。如果后台无法访问，我会在 wp-config.php 中简要设置值：

define( 'WP_HOME', 'https://deinedomain.de' )；
define( 'WP_SITEURL', 'https://deinedomain.de' )；

如果出现管理 SSL 问题，我也会暂时取消访问权限：

define('FORCE_SSL_ADMIN', false)；

一旦进入仪表板，我就会设置正确的 URL 并再次删除常量。标准化的地址可以防止重复循环。

干净利落地解决 HTTPS/SSL 冲突

出现冲突的原因是 密码锁 在服务器端执行，插件也会设置重定向。我首先会测试证书是否有效，HSTS 或代理头是否会干扰识别。然后，我确保有一个执行 https 的明确位置，最好是在服务器级别。我始终坚持消除混合内容错误和不正确的转发链。在实际转换过程中，这些说明有助于我 WordPress 中的 HTTPS 转换.

限制插件和主题是错误的根源

我打开可疑的 插件 尤其是重定向、搜索引擎优化和安全工具。如果无法进入后台，我会通过 FTP 将 wp-content/plugins 文件夹重命名为 plugins.old。然后，我在仪表板上逐个激活每个插件，直到错误再次出现。切换到标准主题（如 Twenty Twenty-Four）也会显示该主题是否贡献了规则。这样我就能快速找到原因并创建无冲突的配置。

结束登录循环：Cookie、会话、安全

如果登录失败，尽管正确 数据 再次跳转回来，我检查了 cookie 域、路径和 https 标志。我清除所有级别的缓存：浏览器、WordPress 缓存、对象缓存、CDN。对于安全插件，我会检查重定向管理 URL 或限制登录的规则。我暂时设置清除默认值以进行诊断，然后一点一点地重建安全性。目标：没有重复重定向的稳定会话。

正确设置反向代理、CDN 和服务器标头

背后 代理 如果转发或 X-Forwarded-Proto 头信息丢失或到达不正确，应用程序很容易混淆 http 和 https。我检查了 Nginx/Apache 配置、负载平衡器设置和 CDN 转发。重要的是，WordPress 能正确识别实际的客户端 URL。对于使用上游代理的设置，本指南可以帮助我 设置反向代理.这样可以防止服务器、CDN 和插件之间出现相互矛盾的规则。

恶意软件是最后的疑点来源

如果尽管进行了所有修正，回路仍然可以闭合 不 我扫描安装中的恶意代码。将核心文件与原始文件进行比较，检查较新的管理员和 cron 作业。通过搜索 window.location、元刷新或晦涩难懂的 Base64 字符串，揭露头文件、模板文件或 JavaScript 中的重定向。清理之后，我会重置密码并重新备份。防止再次感染可节省大量时间。

日常生活中的预防和监测

我防止循环的方法是 变化 集中管理重定向，并在正式部署前在暂存环境中进行测试。我还会自动创建备份，并及时更新插件和主题。域名变更后，我会检查网站 URL、SSL 和重定向链。一个小型监控系统会在早期阶段通知我状态代码跳变。下表有助于在运行过程中进行快速诊断。

症状 可能的原因 直接测量 测试工具
Er_too_many_redirects 双重 https 执行 只使用一个重定向位置 HTTP 标头检查、Curl
登录跳回 Cookie/ 会话冲突 删除 cookie，清空缓存 私人窗口、DevTools
主页无法加载 .htaccess 循环 激活标准 .htaccess 服务器日志，差异
仅在代理情况下有故障 不正确的 Proto 标头 正确设置 X-Forwarded-Proto 代理配置、标头跟踪
突然从排名 重定向链 减少链条，纠正 301 爬行者、尖叫青蛙

精确跟踪重定向标题跟踪和 curl

在讨论配置问题之前，我提请大家注意 精确链 到。在 DevTools（网络选项卡）中，您可以看到每个跳转的状态代码和位置标头。在外壳上通常就足够了：

curl -IL https://deinedomain.de
# 或显示每个重定向的详细信息
curl -IL --max-redirs 20 https://deinedomain.de

我注意 http→https→http（来回）或 www↔non-www 等模式。301 之后的 302 也很可疑。如果第一个请求也重定向到 /wp-login.php，原因通常是插件/主题或 cookie；如果是全局重定向，通常是 .htaccess 或服务器。

有针对性地使用服务器和 WordPress 日志

日志节省时间。我在 wp-config.php 中激活了调试日志，但没有向访客显示：

define('WP_DEBUG', true)；
define('WP_DEBUG_LOG', true)；
define('WP_DEBUG_DISPLAY', false)；
@ini_set('display_errors', 0)；

然后，我检查 /wp-content/debug.log 是否有提示（例如，在重定向前 "无法修改页眉信息"）。同时，我还会检查网络服务器日志。对于 Apache：access.log 和 error.log，对于 Nginx：access.log（状态为 301/302）。 查看用户代理有助于确定受影响的是机器人还是所有用户。

WP-CLI：通过控制台快速救援

如果无法访问仪表板，我可以通过以下方式解决很多问题 WP-CLI:

# 检查和设置 URL
wp 选项获取主页
wp 选项获取 siteurl
wp 选项更新主页 'https://deinedomain.de'
wp 选项更新 siteurl 'https://deinedomain.de'

# "通过保存 "永久链接一次
wp rewrite flush --hard

# 清空缓存
清除缓存
wp 瞬时删除 --all

# 全面停用/测试插件
wp 插件停用 --all
wp 插件激活经典编辑器

这样，我就可以无风险地返回系统，找到罪魁祸首，并只激活真正需要的东西。

www、斜线和无循环规范化

循环通常由 小差错www 与非 www、缺少/增加斜杠或混合原型。我决定支持一种变体，只设置 a 规则链。Apache 中的非 www→www 示例（不执行双重 https）：

RewriteEngine 开
# 仅在主机不是 www 时转发
RewriteCond %{HTTP_HOST} !^www\.[NC］
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]

在 Nginx 中，我设置了明确的服务器阻塞转发，避免了 PHP/插件中的混合规则。重要：首先是规范化（www/斜线），然后是 https，并且只转到 a 职位：

清除代理/CDN：正确识别 HTTPS

如果 WordPress 位于负载平衡器或 CDN 后面，虽然客户端使用 https，但后台通常只接收 http。WordPress就会错误地识别is_ssl()并产生循环。我很早就在 wp-config.php 中更正了服务器变量：

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on'；
}

我还在代理服务器上设置了 X-Forwarded-Proto 和 Forwarded clean 头信息。我很少使用 HSTS：如果 HSTS 处于活动状态，它可能 无 http 路径，否则浏览器就会挂起。我只在所有子域都在 https 上稳定运行时才使用预加载。

解除登录和 cookie 陷阱

一个常见的原因是 Cookie 设置错误。我通常设置 无 COOKIE_DOMAIN。如果已经定义过一次，我就会更改它作为测试：

define('COOKIE_DOMAIN', false)；

我还会检查 https 下是否设置了管理 cookie 标志 "Secure"，路径是否设置为"/"。如果问题持续存在，我会删除服务器端会话（例如重启 php-fpm），并清空对象缓存/redis，使旧的非ces 不再生效。

多站点和域映射的特殊功能

在 多站点-设置、不同的映射很快就会导致循环：子域与目录模式、不同的协议或带有自己重定向功能的旧域映射插件。我会检查博客和网站表，同步协议和主机，并短暂停用自动重定向功能，以便进行语言切换。主博客的 "超级管理员 "登录有助于集中查看网络重定向。重要：只有一个实例可以决定规范域。

WooCommerce、多语言和 "隐藏登录"

商店和多语言网站有额外的重定向逻辑：强制 SSL 页面（结账/账户）、语言重定向到接受语言或安全插件中的 "隐藏登录 "功能。为了进行诊断，我停用了自动语言重定向，并暂时允许 /wp-login.php，而不进行分流。在 WooCommerce 中，我在服务器端干净利落地设置了 "只有这些页面使用 SSL"，或者完全在系统范围内设置了 "只有这些页面使用 SSL"，这样就不会出现混合状态。

坐标对象缓存、操作码和边缘缓存

多个缓存层可以 彼此 放大：PHP 操作码 (OPcache)、对象缓存 (Redis/Memcached)、插件页面缓存和 CDN 边缘。我按顺序清空它们，这样就不会有任何层返回旧的重定向。在规则更改后，我会彻底清空边缘缓存。只有这样，测试才有意义。

典型的 Nginx 陷阱

使用 Nginx 时，当位置块被重写两次或 /index.php 同时存在于内部和外部时，就会出现循环。我使用的是单一的简洁配置：首先是服务器块转发（www/https），然后是 /index.php 上清晰的 try_files。我始终避免 add_header 刷新和 301/302 的混合使用。

核对表：10 分钟内找到原因

  • 在本地删除 cookie/缓存，在隐身模式下进行测试
  • 运行 curl -IL 查看链
  • 将 .htaccess/Nginx 重置为默认路径
  • 同步 WP_HOME/WP_SITEURL（如有必要，通过 WP-CLI 进行同步）
  • 只有一个实例执行 https（首选服务器）
  • 停用插件/主题，逐步激活
  • 正确设置代理标头，检查 is_ssl()
  • 清空对象/页面/边缘缓存
  • 检查日志：debug.log、access/error.log
  • 特殊功能：多站点、Woo、语言、隐藏登录

经典循环之外的错误模式

并非每个 301/302 都是真正的循环，但 路由错误 成本也很高。将 301 改为 404 会向搜索引擎发出 "此资源永远存在 "的信号，但会带来空洞。或者用 302 而不是 301 来防止信号的永久性整合。我最多将链保持在一到两级，永久性的设置为 301，临时性的设置为 302，并通过正确传递 QSA 标志或参数来避免查询字符串丢失。

稳定的部署和文档

为了从一开始就防止出现循环，我将以下内容记录在案 凡规则谁把什么路由到哪里，为什么？我使用一个暂存环境，在那里对规则进行修改，记录标题和时间，然后在生产环境中分发相同的服务器和插件设置。部署后的简短检查（开始页面、登录、签出、语言）可防止失败。

结论简述

我要发布一个 转发回路 系统化：检查 cookie、将 .htaccess 重置为默认值、自定义 WP URL、正确设置 SSL、隔离插件/主题并正确发送服务器头。这些步骤通常会在短时间内结束循环。然后，我会确保安装的安全性，记录重定向并保持更新。这样就能保持登录的可访问性，访客能访问正确的页面，搜索引擎抓取也不会浪费时间。有条理的方法可以避免重复--也能让人省心。

当前文章