WordPress 挂上 Cloudflare 后询盘和后台异常：缓存规则、SSL 模式和真实 IP 怎么核

上周有个外贸站把域名橙云代理开了之后，前台看起来快了不少，麻烦也跟着来：联系表单提交显示成功，后台却收不到询盘；编辑偶尔会被踢下线；有时样式像抽风，半边 CSS 丢了。直连源站 IP 一切正常，问题几乎都落在 Cloudflare 这一层。

别急着关代理或换插件。先把现象拆开，再对照缓存、SSL、真实 IP 三块核对，通常半天内就能收敛。

先把现象分成三类

同一站点上，这三类经常混在一起，分开查会快很多。

A. 表单 / nonce / 会话类

表现：表单提示成功但无邮件、无后台条目；购物车偶发丢；登录后不久掉线；预览页和正式页内容不一致。根因多半是 HTML 或带 Set-Cookie 的响应被边缘缓存了，nonce、cookie、CSRF 全错乱。

B. SSL / 混合内容 / 跳转环

表现：后台强制 HTTPS 后反复跳转；部分脚本、样式变成 http://；浏览器控制台 Mixed Content；Cookie 的 Secure 标志和实际协议对不上。根因常见于 Cloudflare SSL/TLS 模式选了 Flexible，边缘到源站仍是明文。

C. 真实 IP / WAF / 限流误伤

表现：自己的办公网被 ban；登录页频繁验证码；安全插件日志里全是 Cloudflare 节点 IP，而不是访客 IP。根因是源站没还原 CF-Connecting-IP，把整片 CDN 节点当成了攻击者。

三类可以并行核对，不必按顺序死磕。实务里我习惯先问两句：直连源站（改 hosts 或临时灰云）症状是否消失？无痕窗口是否必现？前者把锅钉在 Cloudflare / 边缘规则，后者排除本机 Cookie 和插件缓存干扰。两个都确认后，再进下面三份清单，避免在源站插件堆里空转。

核对清单一：缓存规则别「一刀切」

橙云默认会缓存静态资源，这没问题。危险的是把带会话的 HTML 也缓存了。建议至少保证：

• /wp-admin/*、/wp-login.php、预览 URL（带 preview=true）、购物车 / 结账 / 我的账户路径：绕过缓存（Bypass / Dynamic）
• 联系表单、AJAX 端点、任何会写 Cookie 的页面：不要 Cache Everything
• 响应头里出现 Set-Cookie 的 HTML：不要缓存
• 发文、改主题、改插件后：对首页和受影响 URL Purge，不要只清「全部」却忘了某个语言子路径

WordPress 这边若还挂着页面缓存插件，要和 Cloudflare 规则对齐：边缘缓存的是谁、源站缓存的是谁，别两边都以为对方负责动态页。更完整的分层说明可以看 WordPress CDN 与缓存加速的排查要点。

另外留意控制台里 Cache Rules 与旧版 Page Rules 混用：两条规则优先级打架时，经常出现「后台 Bypass 了，首页带查询参数的落地页却被 HIT」。改规则后用无痕窗口打开表单页，提交一次，再看后台是否立刻出现条目------比只看前台「成功」提示靠谱。若表单走 AJAX，Network 里还要看那条 POST 有没有被边缘直接返回缓存响应。

核对清单二：SSL/TLS 模式别停在 Flexible

Cloudflare 控制台 → SSL/TLS → Overview，常见三档：

模式	浏览器 ↔ CF	CF ↔ 源站	适合场景
Flexible	HTTPS	HTTP	几乎不该给生产 WordPress 用
Full	HTTPS	HTTPS（证书可自签）	过渡期可接受
Full (strict)	HTTPS	HTTPS（受信任证书）	生产推荐

Flexible 的坑在于：访客以为全程加密，源站收到的是 HTTP。于是会出现：

• WordPress 按 is_ssl() / X-Forwarded-Proto 判断协议时摇摆，后台 Cookie、重定向循环
• 强制 HTTPS 插件和 CF 互相 301/302
• 部分主题资源 URL 写成 http://，触发 Mixed Content，看起来像「CSS 坏了」

生产站点优先 Full (strict) ，源站装好有效证书（Let's Encrypt 等）。证书过期或域名与证书 SAN 不一致时，Full (strict) 会直接 526，别因此退回 Flexible------应修源站证书。改完后清一次浏览器 Cookie，再测后台登录和表单提交。若站点还有强制 HTTPS 插件，确认它认的是 X-Forwarded-Proto: https（CF 会带），否则容易和边缘跳转叠成环。

快速看跳转链可以用：

curl -sI https://你的域名/wp-admin/ | grep -iE 'HTTP/|location:|cf-ray'

若连续出现 http:// 与 https:// 来回 Location，先查 SSL 模式和源站强制 HTTPS，再查缓存。

核对清单三：把访客真实 IP 还原回来

Cloudflare 代理后，源站 Nginx / Apache 默认看到的是边缘节点 IP。限流、登录保护、评论反垃圾、安全插件若按这个 IP 计数，几分钟就能把正常访客（其实是 CF 节点）封掉，或者反过来放过真正的恶意 IP。

常见做法：

1. 信任 Cloudflare 公布的 IP 段，用 CF-Connecting-IP（部分环境还有 True-Client-IP）还原。
2. Nginx 示例（IP 段请按官方列表更新，勿照抄过期段）：

# 示意：real_ip 模块；正式环境请引入 Cloudflare 当前 IP 列表
set_real_ip_from 173.245.48.0/20;
# ...其余 CF 段...
real_ip_header CF-Connecting-IP;

3. 若暂时不便改 Nginx，可用可靠的「还原真实 IP」类插件，但最终仍建议落到 Web 服务器层，避免插件被绕过。
4. 改完后看访问日志：同一访客多次请求应显示稳定的客户端 IP，而不再是一串 Cloudflare 节点。

安全插件、Fail2ban、主机面板的「CC 防护」都要确认读的是还原后的 IP，否则 ban 名单会越来越离谱。还原前后各抓一段访问日志对比：同一办公出口 IP 应收敛成一条，而不再是十几个 Cloudflare 节点轮换。WAF 自定义规则里若写死了「按连接 IP 计数」，也要改成按还原后的访客 IP，否则限流阈值在橙云打开后会瞬间失真。

两分钟验证：缓存状态和回源头

表单、后台都测过之后，用 curl 确认边缘行为：

# 看是否被错误缓存
curl -sI https://你的域名/联系表单页路径 | grep -iE 'cf-cache-status|cache-control|set-cookie|cf-ray'

# 对比首页（可缓存）与后台（应动态）
curl -sI https://你的域名/ | grep -i cf-cache-status
curl -sI https://你的域名/wp-admin/ | grep -iE 'cf-cache-status|cache-control'

经验上：

• 表单页、后台：cf-cache-status 多为 DYNAMIC / BYPASS，且不该把带 Set-Cookie 的 HTML 标成 HIT
• 纯静态资源：HIT / EXPIRED 都正常
• 若表单页反复 HIT，先回缓存规则，再谈插件

发文后若前台仍是旧内容，优先 Purge 该 URL，再查浏览器自身缓存。

验收清单（改完打勾再收工）

• /wp-admin/、登录、预览、结账、表单相关路径已 Bypass，未对带 Cookie 的 HTML 做 Cache Everything
• SSL/TLS 为 Full 或 Full (strict)；无痕窗口后台可稳定登录，无协议来回跳
• 访问日志里能看到访客真实 IP；安全 / 限流插件未再大面积 ban CF 节点
• 联系表单提交后，后台立刻有条目（或邮件到达），且刷新表单页 nonce 仍有效
• curl 核对：表单/后台为 DYNAMIC 或 BYPASS；改完内容后 Purge 生效

Cloudflare 本身不是问题，问题是「橙云一开、规则照抄静态站」。WordPress 有会话、有 nonce、有后台，边缘规则必须按动态站点来配。把缓存范围、SSL 模式、真实 IP 三块钉死，询盘丢失和后台抽风这类症状，大多会一起消失。若三块都核对过仍偶发，再往下看源站页面缓存插件、对象缓存、以及主题是否把资源 URL 写死成 http------那已经超出 Cloudflare 配置本身，但仍常和橙云症状叠在一起，分开验证会少走弯路。

---

延伸阅读：按站点现状出问题清单的免费诊断