WordPress + 1Panel + Cloudflare Tunnel：一套经典组合中最常见的重定向与 502 问题排查方案

在个人博客部署方案中，WordPress + 1Panel + Cloudflare Tunnel 是一套非常常见的组合：前端通过 Cloudflare 提供 HTTPS 与访问入口，中间使用 Tunnel 打通公网与内网，后端再由 1Panel 承载站点服务。看起来结构清晰，实际部署时却很容易踩坑。

问题的根源在于：WordPress 对站点域名与协议（HTTP/HTTPS）有较强的绑定机制。一旦请求链路中不同环节对协议的认知不一致，例如用户侧访问的是 HTTPS，但源站收到的却是 HTTP，系统就可能触发错误判断，继而出现 重定向循环（Too Many Redirects）、后台无法登录、页面样式错乱，甚至在外网表现为间歇性 502 或页面无法加载。

因此，解决这类问题的关键，不是单纯保证“网络能通”，而是让 Cloudflare、1Panel 与 WordPress 三者对协议和域名的认知完全一致。下面按照一套更稳妥的标准流程，梳理完整配置思路。

一、问题为什么会出现：不是连通性问题，而是“协议认知不一致”

在这套架构中，典型的访问路径通常是：

浏览器 → Cloudflare（HTTPS）→ Cloudflare Tunnel → 1Panel（HTTP 或 HTTPS）→ WordPress

如果 Cloudflare 面向公网提供 HTTPS，而内网回源到 1Panel 时又使用 HTTPS，或者 1Panel 本身还在强制 HTTPS，WordPress 同时又根据收到的请求头判断当前环境是 HTTP，那么整条链路就会出现“多方都在纠正协议”的情况。

这种情况下最常见的结果有两类：

第一类是重定向循环。例如 Cloudflare 已经处理了 HTTPS，但 1Panel 仍然要求强制跳转 HTTPS，WordPress 也试图进一步修正 URL，最终不断跳转，浏览器报出 Too Many Redirects。

第二类是间歇性 502 或页面加载失败。这往往发生在代理转发、证书校验、协议识别之间出现冲突时，前端表现并不稳定，因此更容易误判成网络波动或服务器性能问题。

要彻底解决，核心原则只有一句话：

让 Cloudflare 负责外网 HTTPS，让内网回源尽量保持简单，并让 WordPress 明确知道前端已经完成 HTTPS 终止。

二、第一步：简化 Cloudflare Tunnel 配置，让外部 HTTPS、内部 HTTP

在这一步中，建议把 HTTPS 的处理统一交给 Cloudflare，Cloudflare Tunnel 回源到 1Panel 时直接使用 HTTP。这样做的最大好处，是可以避开 1Panel 本地证书、源站证书不匹配以及重复 SSL 终止带来的复杂问题。

配置建议

登录 Cloudflare Zero Trust，进入对应 Tunnel 的 Public Hostname 配置项，重点确认以下内容：

1. Service Type 选择 HTTP

不要使用 HTTPS 作为回源协议，优先选择 HTTP。

2. URL 指向 1Panel 所在设备的局域网地址

填写 1Panel 所在服务器的内网 IP 与 HTTP 端口，例如：

192.168.x.x:80

如果你的 1Panel 站点并非监听在 80，也应填写实际监听端口。

3. 设置 HTTP Host Header

在 Additional application settings → HTTP 中，将 HTTP Host Header 设置为 WordPress 对外绑定使用的正式域名，例如：

blog.yourdomain.com

这个设置非常关键。它决定了源站接收到的 Host 头是否与 WordPress 实际绑定域名一致。如果这里不一致，WordPress 很容易把请求视为异常来源，从而触发重定向或站点地址修正。

4. 忽略 TLS 相关选项

由于回源协议已经选择了 HTTP，因此 TLS 选项卡中的配置通常不会生效，可以不作为排查重点。

这一阶段的目标

完成这一步后，访问链路会变成：

用户浏览器（HTTPS）→ Cloudflare → Tunnel → 1Panel（HTTP）

这样外层是安全连接，内层是简化后的纯 HTTP，既保留了公网访问安全性，也减少了源站 SSL 配置冲突的可能。

三、第二步：调整 1Panel 网站设置，避免与 Cloudflare 重复处理 HTTPS

当 Cloudflare 已经承担了外网 HTTPS 入口时，1Panel 最重要的任务就不再是“继续强制加密”，而是稳定地接收来自 Tunnel 的回源请求。

如果 1Panel 此时仍然开启“强制 HTTPS”，就会与 Cloudflare 的访问逻辑形成相互干扰，最终引发重定向循环甚至 502。

需要重点检查的三个项目

1. 域名绑定必须完全一致

进入 1Panel → 网站 → 网站列表 → 对应 WordPress 站点设置，先检查域名配置。

这里绑定的域名，必须与 Cloudflare Tunnel 中设置的 HTTP Host Header 完全一致，包括：

• 主域名或子域名是否一致
• 是否遗漏 www
• 是否混用了多个入口域名

域名不一致时，WordPress 往往会主动修正地址，导致访问异常。

2. 关闭“强制 HTTPS”

这是整个配置中最容易被忽略、也最容易导致问题的一项。

在 1Panel 的网站 HTTPS 配置中，确认：

• “强制 HTTPS”必须关闭

即便你此前已经在 1Panel 中签发过 Let’s Encrypt 证书，也不必急着删除。只要不启用强制 HTTPS，就不会与 Cloudflare 的外层 HTTPS 发生正面冲突。

3. 暂时关闭 WAF

为了减少变量，建议在排查阶段先将 **WAF（Web 应用防火墙）**关闭。

原因很简单：Cloudflare Tunnel 回源时，请求特征与普通公网直连并不完全相同，某些 CC 防护或规则策略可能误判，导致：

• 请求被拦截
• 后台登录异常
• 偶发 403、502 或加载失败

等站点恢复正常后，再按需重新启用 WAF，并把 Cloudflare 相关节点或可信来源加入白名单，会更稳妥。

四、第三步：修改 WordPress 配置，让它正确识别“前端已是 HTTPS”

前两步完成后，Cloudflare 负责外部 HTTPS，Tunnel 到 1Panel 使用 HTTP，1Panel 也不再强制跳转 HTTPS。此时还有最后一个关键点：

WordPress 看到的请求，依旧可能是 HTTP。

但实际上，用户在浏览器中访问的是 HTTPS 页面。
如果不告诉 WordPress“前端代理已经完成 HTTPS”，它就可能出现以下问题：

• 自动跳转到另一个 URL
• 后台登录循环重定向
• 静态资源引用错误，导致排版错乱
• Cookie 或后台会话异常

因此，需要在 wp-config.php 中主动处理反向代理环境下的 HTTPS 识别。

操作方法

打开 WordPress 根目录下的 wp-config.php 文件，找到这一行：

/* That's all, stop editing! Happy publishing. */

或者对应的中文版注释：

/* 好了！请不要再继续编辑。请保存本文件。使用愉快！ */

在它的正上方加入以下代码：

这段代码的作用是什么

第一段逻辑的核心是：
当 Cloudflare 通过请求头 X-Forwarded-Proto: https 告诉源站“前端访问协议其实是 HTTPS”时，WordPress 就会把当前环境识别为 HTTPS，而不是误判为 HTTP。

第二段 FORCE_SSL_ADMIN 则主要用于后台场景。对于部分站点，如果 /wp-admin 访问时仍然存在循环跳转或登录异常，开启这项通常能进一步稳定后台会话与登录流程。

五、配置完成后，如何验证是否真正生效

三项配置完成后，不建议立即根据旧缓存判断结果，而应该先做一次标准验证。

1. 清理浏览器缓存

建议直接使用无痕模式/隐私窗口重新访问站点，避免旧的 301、302 重定向缓存干扰结果。

2. 检查前台访问

正常情况下，此时页面应该可以直接打开，并且浏览器地址栏会显示安全锁，说明用户端访问的 HTTPS 已由 Cloudflare 正常处理。

3. 检查 WordPress 后台

访问：

https://你的域名/wp-admin

确认后台能够正常登录、跳转稳定、页面资源加载完整。

4. 核对 WordPress 站点地址

进入后台 设置 → 常规，重点确认以下两项：

• WordPress 地址（URL）
• 站点地址（URL）

二者都必须写成：

https://你的域名

注意必须是 https 开头。如果这里仍然是 http://，WordPress 依旧可能继续输出错误链接或发生跳转问题。

六、如果问题还没解决，优先排查什么

如果按以上流程配置后仍然异常，不要立刻回头改动 Cloudflare 或 WordPress，建议先检查 1Panel 与 OpenResty 的基础监听状态。

常见现象：连默认页面都打不开，或者直接返回 404

这种情况通常意味着问题已经不在 WordPress 层，而在更靠后的站点服务层。重点检查：

• OpenResty/Nginx 是否正确监听了 80 端口
• 站点配置是否已加载
• 反向代理目标是否指向了错误端口
• 1Panel 站点根目录与站点配置是否匹配
• 默认站点或其他站点是否抢占了请求

换句话说，如果连 1Panel 的默认页面都无法正常通过回源访问，那么 WordPress 的 HTTPS 识别代码再正确，也无法解决底层路由与监听问题。

七、这套方案为什么更稳定

很多人第一次部署这套架构时，容易陷入一个误区：
“既然 HTTPS 更安全，那 Cloudflare、1Panel、WordPress 每一层都开 HTTPS 应该更稳。”

事实恰恰相反。对于 Cloudflare Tunnel + 内网面板 + WordPress 这类代理链路较长的场景，越多层重复处理 HTTPS，越容易因证书、转发头和跳转规则不一致而出错。

更稳妥的思路是：

• 公网 HTTPS 交给 Cloudflare
• 隧道回源尽量走简单的 HTTP
• WordPress 明确识别代理后的 HTTPS 环境
• 1Panel 只负责稳定接收请求，不重复强制协议跳转

这种分工清晰的模式，既降低了配置复杂度，也更利于后续排错。

WordPress + 1Panel + Cloudflare Tunnel 确实是一套经典而高效的部署组合，但要稳定运行，关键不在“能不能访问”，而在于三者对域名、协议与代理关系的认知是否完全一致。

一套更可靠的实践路径是：

• 由 Cloudflare 统一处理外网 HTTPS
• 由 Tunnel 使用 HTTP 回源到 1Panel
• 在 1Panel 中关闭强制 HTTPS，避免重复跳转
• 在 WordPress 中通过 wp-config.php 正确识别 X-Forwarded-Proto

只要这三个环节配置对齐，绝大多数重定向循环、后台异常、页面样式错乱以及间歇性 502 问题，都能得到根本性解决。对于个人博客来说，这也是一套更易维护、更适合长期运行的部署思路。