地区页面缓存测试：验证 CDN 不跨地区返回内容

地区页面缓存测试判断“有没有串区”，不要看两个地区的页面长得像不像，而要看缓存键、Vary 和响应头里的命中证据。做法是在授权测试页上先冷启动，再预热，然后从另一个地区请求同一个 URL，逐项核对实际平台的缓存头、Age、POP/层级、回源内容和页面地区标记。标准 Cache-Status 与厂商头的字段格式不同；例如 Cloudflare 使用 CF-Cache-Status，不要将裸 HIT/MISS 当成通用标准。本文只验自有或已授权的测试页，代理 IP 仅用于切换请求出口，出口 IP 的归属地和代理类型要一并记录。

先选带地区标记、能查看缓存信息的测试页

测试页要满足三个条件：可公开访问或已授权、页面带明确的地区标记（地区码、货币、语言变量）、缓存策略可观察。别拿首页做样本——首页常被 CDN 和站点规则单独排除，命中的可能是边缘规则而不是内容缓存，结论迁移不到内页。

可观察变量分两层：先确认请求对应的地区/语言，以及响应中的地区标记；再结合 CDN 暴露的缓存键、Vary、Age 和 Cache-Status 定位缓存层。并非每个 CDN 都会公开缓存键或提供相同响应头，缺少某个头时应以平台日志或配置面板补证，不能据此直接判通过。基础用例固定一种代理类型；若比较代理类型，固定地区与请求状态单独测试。

如何安排冷缓存、热缓存和跨地区请求？

冷、热、跨区三步必须在同一个 TTL 窗口内完成。以 TTL 300 秒为例，三步控制在 3 分钟内；否则第二次请求可能已经过期回源，MISS 会被误读成“缓存没生效”。

具体做法：先记录清缓存后 A 地区请求的实际响应头与回源内容；同地区再请求时记录命中状态和 Age；随后固定语言只改变到 B 地区请求同一 URL。不同 POP 不一定共享副本，不能用一次 MISS 判定隔离有效。三步都保存完整请求头和响应头——只看页面文字，分不清“命中错误缓存”和“回源到了错误地区”。

第二步没有变 HIT，先查缓存键是否每次请求都不同（Cookie、随机参数都会造成）。第三步返回 B 标记，说明地区隔离符合预期；若仍返回 A 标记，先核对实际 POP/层级、缓存键、variant 和回源内容；MISS 也可能经过上层或应用缓存，不能直接归因为回源地区识别。

如何确认缓存键包含会改变页面的地区信息？

缓存键不是“越多越好”。先列出真正会改变响应内容的请求维度（地区、语言），再确认 CDN 缓存键显式包含这些维度。只有源站按请求头协商内容、且缓存支持时，才配对应 Vary；把完整 Cookie 无差别加入缓存键，会显著降低命中率。

具体看两个组合。HIT 返回另一地区内容是异常线索，应检查缓存键与填充时的回源内容；MISS 返回旧地区内容也可能经过上层缓存或应用缓存，需结合平台日志判断。前者查键，后者查回源，不要都归为“缓存问题”。判断地区识别和缓存命中是否混在一起，可以对照为什么检测网站显示地区不一致。

返回了其他地区内容后，怎样区分缓存与回源问题？

隔离失败常见三种：缓存键缺地区、Vary 配置漏项、CDN 回源到固定地区。修复按顺序来——先补键，再补 Vary，最后查回源；前两种改配置即可，第三种要看回源请求头是否被改写、源站是否按回源地区返回内容。

验证修复时重复“冷缓存 → 热缓存 → 跨地区”三步，确认 B 地区拿到 B 的内容且 Age 小于 TTL。只改一处就宣布修复，下一个地区很可能复现。记录 POP/层级、请求维度、缓存头、Age、variant、源站内容和实际页面内容。

下表是一次三步验证的记录样式，三行都固定同一种代理类型，类型对照另开一组：

读表时先确认 A/B 请求只改变地区，再结合 POP/层级、实际缓存头、variant 和回源内容判断。当前示例第三行仍需核对缓存键与日志，不能仅凭地区标记断定具体责任层。

FAQ

Age 很大但内容是当前地区，正常吗？

正常。Age 大只说明副本缓存得久，只要内容地区标记与请求地区一致，就属于正常命中；需要担心的是内容地区和请求地区不一致。

缓存键应该包含哪些字段？

先看哪些请求维度会改变响应内容（地区、语言），再确认缓存键显式包含这些维度；只有源站按请求头协商内容时，才需要配对应 Vary。完整 Cookie 无差别入键会拉低命中率，不建议照搬。

CDN 回源到错误地区怎么查？

看回源请求头里的地区字段是否被改写，再对比源站直连与经 CDN 的返回内容；两者不同，问题就在回源链路。

缓存测试用共享代理 IP 会污染结果吗？

会，同一出口 IP 可能复用同一个边缘缓存位置，两个地区看起来像串区；用独立会话加两个不同出口对照，才能分清缓存与地区。

需要确认可用出口地区，可查看全球代理支持的出口地区。