本文约 3,078 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
你像往常一样打开自己的网站，浏览器却弹出这样一行字：”该网页将您重定向的次数过多。”（英文提示是 This page isn’t working. ERR_TOO_MANY_REDIRECTS.）清缓存、换浏览器、开无痕都没用，无语的是，有时是网站刚上线给了朋友看，打开就报这个错；有时是刚在后台开启了 HTTPS 或装了个 SSL 插件，自己反而被挡在门外。这个问题本质上是”跳转死循环”：浏览器从一个地址被跳到另一个地址，又跳回来，跳了几十次后浏览器干脆放弃并报错。它并不代表服务器宕机，多半是域名、协议或者跳转规则之间打架了。本文先帮你判断循环发生在哪一层，再按”后台能进”和”后台进不去”两条路线给出修复方法。
故障原因分析
- HTTP 与 HTTPS 互相强制跳转。 服务器（比如 Nginx 或宝塔）已经配置了”把所有 HTTP 请求跳转到 HTTPS”，但 WordPress 后台的”站点地址”仍然写着
http://，用户一访问 https 又被 WordPress 改回 http，两边来回顶，形成死循环。
- 带 www 与不带 www 冲突。 服务器规则强制跳转到
www.域名，而 WordPress 站点地址填的是不带 www 的版本，两者互相把对方跳走，循环就此产生。
- SSL 插件与服务器/CDN 重复跳转。 像 Really Simple SSL 这类插件会接管 HTTPS 跳转，如果服务器或 CDN 已经做过同样的跳转，两套规则叠加就容易循环。
- 反向代理下 WordPress 识别不到 HTTPS。 站点跑在 Nginx 反代或 CDN 后面时，PHP 里的
is_ssl()可能判断为”当前不是 HTTPS”，于是 WordPress 主动把用户跳回 HTTP，又被前端跳回 HTTPS。
.htaccess里存在重复或冲突规则。 迁移、插件、手动编辑可能留下多段互相矛盾的RewriteRule，产生自跳转。
分步解决方案
先判断：后台能不能进？
- 后台能进 → 直接走方法一，改”设置 → 常规”。
- 后台进不去 → 走方法二，改数据库或
wp-config.php。
方法一：统一”WordPress 地址”和”站点地址”（后台能进时）
进入 设置 → 常规，确认两项完全一致，并都使用 https://、且是否带 www 与你实际访问的域名相同：
WordPress 地址(URL): https://mimangfei.com
站点地址(URL): https://mimangfei.com如果网站还没配 SSL 证书，就别急着开 HTTPS，先把两项改回 http:// 恢复正常访问。
方法二：后台进不去时改数据库
用 phpMyAdmin 打开站点对应的数据库，找到 wp_options 表（表前缀可能不是 wp_），修改 option_name 为 siteurl 和 home 的两条记录，把值统一改成正确地址。
也可以用 SQL 直接执行（把域名替换成你自己的）：
UPDATE wp_options SET option_value = 'https://mimangfei.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://mimangfei.com' WHERE option_name = 'home';方法三：用 wp-config.php 强制锁定地址（最稳妥）
在 wp-config.php 里写死地址，优先级高于数据库，能避免来回改：
// wp-config.php，写在 "/* That's all, stop editing! */" 之前
define( 'WP_HOME', 'https://mimangfei.com' );
define( 'WP_SITEURL', 'https://mimangfei.com' );方法四：让反代/CDN 环境正确识别 HTTPS
如果站点在反向代理或 CDN 后面，在 wp-config.php 中加入以下判断，让 WordPress 知道”用户其实是走 HTTPS 进来的”：
// wp-config.php
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}方法五：检查跳转来源插件与服务器规则
- 临时停用跳转类插件： 通过 FTP 把
wp-content/plugins/really-simple-ssl之类的目录改名，插件会自动停用。若网站立刻恢复，说明是插件与服务器重复跳转，之后二选一保留。 - 重置
.htaccess： 备份后，把 WordPress 根目录的.htaccess恢复为默认规则（只保留# BEGIN WordPress到# END WordPress那段），删除自己添加的重复跳转。 - 检查 Cloudflare： 如果用了 Cloudflare，进入 SSL/TLS → Overview，把加密模式设为
Full或Full (strict)。若设为Flexible，Cloudflare 到源站走 HTTP，源站又强制跳 HTTPS，就极易循环。
检查跳转链路
想更精准地定位，可以在命令行追踪跳转：
curl -I -L --max-redirs 10 https://mimangfei.com-I 看响应头，-L 跟随跳转，输出的 Location: 头会清楚地告诉你它在哪几个地址之间来回跳。
常见踩坑点
- 改了站点地址但没清缓存。 CDN、浏览器、缓存插件都可能缓存了旧跳转，改完要清一遍再用无痕窗口验证。
http和https只改了一处。siteurl和home必须同时改，改一个更容易循环。- 证书没配好就强开 HTTPS。 服务器没有有效证书时强制跳 HTTPS，用户会直接看到证书错误或循环。
- 插件停用后忘了彻底处理。 靠改名停用只是临时手段，问题排除后要在后台正常停用或卸载，避免目录残留。
- Cloudflare 模式选错。
Flexible模式是最典型的循环来源，务必改成Full (strict)。 - 直接删
.htaccess。 删掉后虽然可能暂时正常，但会丢失伪静态规则；正确做法是备份后恢复为默认内容。
总结
“重定向过多”听起来吓人，其实只是域名和协议在”互相踢皮球”。排查的核心就一句话：让服务器规则、SSL 插件、CDN 和 WordPress 站点地址四者的 HTTPS 与 www 策略保持一致，只保留一套跳转。后台能进就改”设置 → 常规”；进不去就改数据库或 wp-config.php 里的 WP_HOME/WP_SITEURL。用 Cloudflare 的站点，优先检查 SSL 模式是否为 Full (strict)；用反向代理的，记得补上 X-Forwarded-Proto 判断。理顺之后，建议把正确的地址写死进配置文件防止再次漂移，并给跳转规则做一次记录，下次迁移或换域名时就能少踩坑。
