彻底搞懂 WordPress ERR_TOO_MANY_REDIRECTS:Cloudflare HTTPS 回源与真实 IP 配置全解
很多站长在为 WordPress 站点套上 Cloudflare 的“小黄云”(CDN 代理)之后,满心欢喜地刷新页面,迎来的往往不是速度起飞,而是一个刺眼的浏览器报错——ERR_TOO_MANY_REDIRECTS(重定向次数过多)。
更让人抓狂的是,好不容易通过某些临时手段恢复了访问,后台访客评论、安全插件(如 Wordfence)甚至 Nginx 访问日志里,所有用户的 IP 竟然全变成了 Cloudflare 节点的机房 IP,安全防护和访问统计瞬间形同虚设。
这个问题看似玄学,底层逻辑却非常严密。本文将从死循环产生原理切入,带你彻底修复 Cloudflare 无限重定向,并一步到位搞定 HTTPS 严密回源与访客真实 IP 还原。
准备工作与环境依赖
在动手前,请确认你的服务器环境与权限:
- Web 服务器:Nginx 1.18+(本文以 Nginx 为例,其他服务器逻辑完全相同)
- 应用程序:WordPress 6.0+
- 权限要求:拥有服务器
root或sudo权限 - Cloudflare 状态:域名已托管在 Cloudflare,DNS 记录已开启代理(橙色小云朵)
提示:文中涉及 Cloudflare 官方 IP 列表,Cloudflare 偶尔会微调网段,部署时建议以官方公布的最新的 IP 范围为准。
核心剖析:为什么会出现无限重定向?
在排错之前,先看清楚请求到底是怎么“转圈”的:
[用户浏览器] --(HTTPS 请求)--> [Cloudflare CDN 边缘节点]
|
(默认 Flexible 模式降级为 HTTP 请求)
v
[你的源站 Nginx / WordPress]
- 用户向
https://yourdomain.com发起安全请求。 - Cloudflare 收到请求,由于后台默认配置为 Flexible(灵活)模式,CF 认为源站不支持 SSL,于是剥离 SSL 证书,通过 HTTP 80 端口 向你的源站发起回源请求。
- WordPress / Nginx 收到来自 80 端口的 HTTP 请求。因为你的站点地址配置为
https://...(或配置了强制 301 重定向),Nginx/WordPress 会给客户端返回一个指令:“请去访问 HTTPS 版!”。 - Cloudflare 把这个 301 指令丢给浏览器,浏览器再次请求 HTTPS 版。
- 进入死循环:Cloudflare 再次使用 HTTP 请求源站,直到浏览器抛出
ERR_TOO_MANY_REDIRECTS彻底崩溃。
分步实战修复指南
第一步:修正 Cloudflare SSL/TLS 加密模式
千万不要使用 Flexible 模式!生产环境请至少切换为 Full,强烈推荐 Full (Strict)。
- 登录 Cloudflare Dashboard,进入对应域名。
- 左侧导航点击 SSL/TLS -> Overview(概述)。
- 将加密模式从 Flexible 改为 Full 或 Full (strict)。
- Full:Cloudflare 与源站之间建立 HTTPS 连接,源站即使使用自签名证书也允许通行。
- Full (strict):要求源站具备受信任的有效 SSL 证书。推荐使用 Cloudflare 提供的免费 15 年 Origin CA 证书。
获取 Cloudflare Origin CA 证书(推荐做法):
在 Cloudflare 后台点击 SSL/TLS -> Origin Server(源服务器) -> Create Certificate(创建证书),保留默认配置,点击生成后会拿到:
- Origin Certificate(保存为
/etc/ssl/certs/cf_origin.pem) - Private Key(保存为
/etc/ssl/private/cf_origin.key)
第二步:配置 Nginx 反向代理与 SSL 回源
登录你的服务器,编辑对应的 Nginx 虚拟主机配置文件(通常位于 /etc/nginx/sites-available/yourdomain.com 或 /etc/nginx/conf.d/):
# 1. 强制 HTTP 跳转 HTTPS(由 Cloudflare 或源站双重保障)
server {
listen 80;
listen [::]:80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
# 2. 真正的 HTTPS 处理区块
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name yourdomain.com www.yourdomain.com;
root /var/www/wordpress;
index index.php index.html;
# SSL 证书配置(使用第一步生成的 Origin CA 证书)
ssl_certificate /etc/ssl/certs/cf_origin.pem;
ssl_certificate_key /etc/ssl/private/cf_origin.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# 处理静态文件与路由
location / {
try_files $uri $uri/ /index.php?$args;
}
# PHP-FPM 处理关键点
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock; # 按实际 PHP 版本调整
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# 核心参数:告诉 PHP 当前处于 HTTPS 环境
fastcgi_param HTTPS 'on';
fastcgi_param HTTP_X_FORWARDED_PROTO https;
}
location ~ /\.ht {
deny all;
}
}
配置完成后测试并重载 Nginx:
sudo nginx -t && sudo systemctl reload nginx
第三步:修改 WordPress 的 wp-config.php 识别协议头
有时源站与 CDN 之间存在复杂的反向代理层,WordPress 自身可能无法准确捕获 HTTPS 状态。为了斩草除根,我们需要让 WordPress 正确感知请求协议。
打开站点根目录下的 wp-config.php,在 /* That's all, stop editing! */ 注释之前加入以下代码:
/**
* 识别反向代理的 HTTPS 协议,防止死循环
*/
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
$cf_visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
if (isset($cf_visitor->scheme) && $cf_visitor->scheme === 'https') {
$_SERVER['HTTPS'] = 'on';
}
}
代码解释:
- 当 Cloudflare 回源时,会在请求头中附带
X-Forwarded-Proto: https和CF-Visitor: {"scheme":"https"}。 - 这段代码直接在 WordPress 核心加载前,将 PHP 超全局变量
$_SERVER['HTTPS']强制赋值为'on',从而彻底阻断 WordPress 内部的主动 301 行为。
第四步:恢复访客真实 IP(Real-IP 机制)
套上 Cloudflare 后,在 Nginx 看来,所有的请求均来自 Cloudflare 的边缘节点。这会导致后台评论、安全防护(Fail2ban/Wordfence)全部失效。
我们需要利用 Nginx 的 http_realip_module 模块,将请求头 CF-Connecting-IP 还原为用户真实 IP。
1. 创建 Cloudflare IP 配置文件
新建文件 /etc/nginx/conf.d/cloudflare_realip.conf:
sudo nano /etc/nginx/conf.d/cloudflare_realip.conf
写入 Cloudflare 现役的所有 IPv4 与 IPv6 网段(必须保持更新):
# Cloudflare IPv4
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
# Cloudflare IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
# 使用 Cloudflare 专属请求头覆盖客户端 IP
real_ip_header CF-Connecting-IP;
2. 测试与重载
执行重载指令:
sudo nginx -t && sudo systemctl reload nginx
此时再查看 Nginx 访问日志(tail -f /var/log/nginx/access.log),你会发现记录下来的已经是来自全国乃至全球用户的真实 IP,而非清一色的 172.68.x.x 或 104.x.x.x。
常见排错指南 (FAQ / Troubleshooting)
Q1: 改完之后依然报错 ERR_TOO_MANY_REDIRECTS,是什么原因?
A:
- 浏览器强缓存:301 是永久重定向,浏览器会直接走本地缓存。务必开启无痕窗口或清理该域名的 Cookie 与缓存后再测试。
- Cloudflare 页面规则(Page Rules)冲突:检查 Cloudflare 的 Rules 中是否配置了冲突的“始终使用 HTTPS”或重定向转发。
- WordPress 地址设置错误:进入 WordPress 数据库
wp_options表,核对siteurl和home字段,确保是以https://开头,而不是http://。
Q2: 为什么不建议一直用 Flexible 模式?
A:
Flexible 模式下,CDN 到源站之间的数据全部是明文 HTTP 传输。这意味着任何在源站机房骨干网上的监听者都能看到用户的敏感数据(包括密码、Cookie 和会话),完全达不到 HTTPS 带来的数据完整性与机密性标准。
Q3: 使用 Cloudflare Origin 证书后,直接通过 IP 访问源站提示证书错误?
A:
这是正常现象。Cloudflare Origin CA 证书是由 Cloudflare 内部根证书签发的,公网浏览器并不信任它。它的唯一作用是让 Cloudflare 边缘节点在“Full (Strict)”模式下安全回源。如果需要直接绕过 CDN 访问源站,应当使用 Let's Encrypt 等公网受信任机构颁发的证书。
总结
解决 Cloudflare 代理 WordPress 的核心原则可以概括为三句话:
- 统一通信通道:拒绝 Flexible 模式,全程开启 HTTPS 闭环(Full/Strict)。
- 明确告知后端:通过 Nginx 与
wp-config.php明确注入HTTPS: on标识,避免应用层盲目跳转。 - 信任边缘网络:配置
set_real_ip_from提取CF-Connecting-IP,还原本质访问链路。
按照以上步骤配置完成后,你的站点不仅能免除重定向死循环的困扰,还能获得安全、可靠的 SSL 回源以及精准的访客审计环境。
本文主题:彻底搞懂 WordPress ERR_TOO_MANY_REDIRECTS:Cloudflare HTTPS 回源与真实 IP 配置全解
引用出处:https://isoziyuan.com/p/100127/(作者:Isoziyuan · 发布于爱搜资源网)
登录后参与讨论
注册或登录账户,即可查看并发表文章评论。