很多站长把网站接入 CDN（内容分发网络）后，页面加载慢的问题多半解决了，却在回源环节踩坑：图片缓存命中率低、改了源站 Host 整站打不开、源码里暴露源站 IP。这些问题的根子大多在”回源配置”这一层。若想先弄清 CDN 扮演的角色，可参考接入 CDN 后源站的职责变化。本文讲清 Cloudflare 的回源机制，拆解缓存规则与回源 Host的设置方法，教你用几组命令定位故障。
先看清回源到底在做什么
回源（Origin Fetch）指 CDN 边缘节点在缓存未命中时，去源站拉取数据。Cloudflare 的请求链路大致是”用户 → 边缘节点 → 源站”，任一环配置出错，都会表现为页面异常或性能劣化。
回源 Host 与源站地址是两回事
这是最易混淆的一组概念。源站地址（Origin Server）告诉 Cloudflare 往哪个 IP、端口拉数据；回源 Host（Origin Host / Host Header）则决定源站接收请求时 HTTP 头里的 Host 字段。Nginx 等 Web 服务器和 WordPress 等建站程序，就靠 Host 字段决定返回哪个站点。
举例：域名 www.example.com，源站 IP 203.0.113.10，但服务器只配置了 cdn.example.com 站点。把源站填 IP、回源 Host 填 cdn.example.com，请求 Host 就是 cdn.example.com，源站才能匹配对应站点。回源 Host 填错，即使地址正确也会返回默认站点或 404。
缓存规则决定了哪些请求会被命中
Cloudflare 的缓存由一套从宽到严的规则链决定。默认情况下，静态资源（图片、CSS、JavaScript）容易命中缓存，而 HTML 文档、带 Cookie 的动态请求默认不缓存，要判断站点属于”静态为主”还是”动态为主”。
在 Caching 面板可查看每类后缀的缓存层级（Cache Level），从 No Query String、Ignore Query String 到 Standard、Cache Everything 逐级放开，层级越宽边缘节点回源越少。
缓存规则的设置顺序与优先级
Cloudflare 的缓存规则按”从具体到通用”的优先级生效：先匹配 URL 路径或后缀的精确规则，再落到全站默认层级。理解这个顺序，能避免设了规则却不生效的困惑。
用 Page Rule 和 Cache Rules 分层控制
在 Cloudflare 里，控制缓存的入口有两类：老牌 Page Rule（同一 URL 免费额度有限）和更新的 Cache Rules。Cache Rules 支持按域名、路径、扩展名、请求方法等维度组合匹配，配置更灵活。对大多数外贸站点，建议这样规划：
- 静态资源路径（如
/wp-content/、/assets/）匹配Cache Everything，Edge Cache TTL 设 4 小时； - 登录、购物车等带 Cookie 的动态路径排除在缓存之外，避免用户看到别人的登录态或旧购物车；
- HTML 首页设
Cache Everything，Browser Cache TTL 设 5-10 分钟，兼顾回源频率与内容新鲜度。
关于缓存层级与回源频率的取舍，可参考多层缓存架构的实践经验。
用 curl 可快速验证响应头带了哪些缓存标记：
curl -sI https://www.example.com/wp-content/themes/x/style.css | grep -i -E "cf-cache-status|cache-control"
如果出现 cf-cache-status: HIT，说明资源已在边缘节点命中缓存；出现 MISS 则代表刚回源过一次。多跑几遍观察 HIT 是否稳定，是判断规则生效最直接的方法。
缓存命中率低时的排查思路
如果你的站点以图片、静态文件为主，缓存命中率却始终偏低，先别急着调规则。先确认请求是否带了不该出现的 Cookie——带 Cookie 的请求默认不缓存，看响应头里有没有 Set-Cookie；再看是否有查询参数在变化，带问号的动态 URL 会被当成不同对象缓存，必要时开启 Ignore Query String；最后确认资源是否被 Cache Everything 覆盖，有些框架会把图片请求写成带签名参数的 URL，不加规则很难命中。
排查后再调整规则，命中率通常会明显回升，源站的带宽（网络传输能力）占用也会随之下降。
回源 Host 的设置与常见坑
回源 Host 是回源配置里出错率最高的字段，一旦与源站实际站点配置不符，就会出现”CDN 缓存里都正常，但回源瞬间打不开”的怪现象。
三种常见场景的回源 Host 写法
- 域名与源站站点一致（多数单站点的静态站）：回源 Host 直接填主域名，例如
www.example.com； - 源站站点与主域名不同（比如用
cdn.example.com作站点名）：回源 Host 填源站虚拟主机名，源站地址填实际 IP； - 源站通过多站点 Nginx/Apache 虚拟主机承载：回源 Host 必须与对应 server_name 精确匹配，否则会命中默认站点。
一个典型错误是把回源 Host 填成源站 IP。IP 通常不在服务器站点配置里，Nginx 会把它丢给 default_server 或返回 404。
修改回源 Host 后整站打不开的排查
如果改过回源 Host 后出现 521（Web 服务器已宕机）或 522（连接超时），检查三处：
- 源站防火墙是否放行 Cloudflare 边缘节点 IP 段——只允许单个回源 IP 会导致新请求被丢弃；
- 用
curl -H "Host: cdn.example.com" http://源站IP/测试源站，能返回内容才说明站点配置无误； - 是否改成了 HTTPS 回源但源站证书不匹配——可用 Flexible 先行降级验证。
用一台能直连源站的机器执行 curl -H "Host: <回源Host>"，可绕过 CDN 单独验证源站行为，是定位这类问题最快的手段。
防止源站 IP 泄露
很多站长以为源站 IP 藏在 CDN 后面就高枕无忧，实际上地址常会通过几个不起眼的通道泄露出去，一旦被盯上，攻击者可直接绕过 CDN 打源站。
常见的泄露通道与封堵
从下面几处排查源站 IP 是否泄露：
- 历史 DNS（域名解析系统）记录：接入 CDN 前解析过的源站记录仍留在公共记录库，需在服务商侧删改相关 A 记录；
- 邮件头或 MX（邮件交换）记录：邮箱服务器若与 Web 源站同 IP，从邮件头能反查地址，应把邮件拆到独立 IP 或主机；
- SSL（安全传输协议）证书的 SAN 记录：核对证书域名与 IP，防止把源站真实信息带出来；
- 站内路径与报错页：页面源码、
/_debug、/server-status若暴露绝对 IP 或服务器信息，需在源站关闭对应功能。
再配合源站防火墙只放行 Cloudflare 边缘节点 IP 段，可进一步缩小暴露面。
回源方式：Flexible、Full 与 Full (Strict)
Cloudflare 提供三种回源 SSL 模式，严格程度递增：
- Flexible（灵活）：边缘到源站用 HTTP 明文，源站不必配置证书，链路不加密；
- Full（完整）：走 HTTPS 但不强制校验源站证书域名，自签名证书也能通过；
- Full (Strict)（完整严格）：走 HTTPS 且强制校验证书与域名，要求证书由可信机构签发且域名匹配。
对多数业务站点建议用 Full (Strict)，前提是源站已正确部署证书。若暂时没有证书，可先用 Flexible 打通链路，证书就绪后再切换，避免回源过程出现 526（证书验证失败）错误。
总结与行动建议
Cloudflare CDN 的回源配置不难，关键是把三个变量想清楚：源站地址填什么、回源 Host 填什么、缓存规则覆盖哪些路径。三者对齐后，源站负载下降、页面打开稳定、缓存命中率维持高位；三者错位，就会出现回源超时、整站打不开、命中率异常等连锁问题。
建议按下面顺序自查：先确认回源 SSL 模式与源站证书，再用 curl 验证静态资源的 cf-cache-status，随后直连源站确认虚拟主机配置，最后检查源站防火墙是否只放行 CDN 节点 IP 段。如果你需要稳定的海外节点与灵活的 CDN 联动，可考虑 Hostease 的 VPS（虚拟专用服务器）或独服（独立服务器）产品。把回源理顺后，再做整体的网站性能优化和海外访问提速。