线上最容易被忽视的故障，往往不是页面彻底打不开，而是用户访问 A 站点时看到了 B 站点的内容：标题、图片、接口响应甚至登录后的片段混在一起，且刷新后依旧存在。排查这类问题时，不能只看源站返回结果，还要确认 CDN 节点用什么条件命中了旧对象。尤其当多个站点共用域名、同一路径或同一套模板时，缓存键归一化、查询参数过滤与源站 Host 隔离只要有一项失效，就可能造成内容串站。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：sebekvps（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一次回源请求最终会被 CDN 归并成一个缓存对象。常见的缓存键并不只有完整 URL，还可能包含协议、主机名、端口、路径以及被允许参与匹配的部分查询参数。真正需要关注的是“哪些差异会生成新键，哪些差异会被故意忽略”。如果站点标识放在 Host 中，而边缘节点默认按 Host 分桶，理论上可以隔离；若配置只保留路径，或把 Host 映射到统一回源域名，A、B 站点的相同路径就可能共用一个缓存键。
查询参数也不是越多越安全。参数名、参数顺序、编码方式和空值处理都可能影响归一化结果，例如同一资源分别以 id=7、id=07 或附加时间戳访问，是否生成独立对象取决于过滤规则。把全部参数纳入键，会造成命中率下降；把业务参数全部过滤，又会让不同内容互相覆盖。正确做法是先列出内容身份所必需的参数，再单独处理缓存版本号、追踪参数等非业务字段。
还要留意缓存键之外的变体，例如内容协商请求头、Cookie 参与缓存、路径大小写、重定向目标以及回源时携带的 Host。若源站依据 Host 返回不同页面，但 CDN 缓存键没有保留它，问题就不在源站，而在“缓存对象身份”和“源站站点身份”不一致。对于多个业务共用模板的场景，建议在路径中加入稳定的站点命名空间，或在回源层明确区分源站 Host，避免依赖隐式配置。
判断时先抓取一条正常请求和一条异常请求，对比 URL、Host、查询参数、响应头中的缓存命中标识、Age、ETag 或 Last-Modified。若响应带有明显的旧内容，同时缓存命中对象与当前请求的站点标识不一致，优先怀疑缓存键冲突。若请求参数不同却命中同一对象，则检查参数过滤规则；若 Host 不同却得到相同对象，则检查源站 Host 隔离和回源映射。
可按“请求是否应区分配置是否实际区分旧对象是否仍在”的顺序排查。第一步给每个内容分支列出唯一身份，例如站点、对象类型和业务 ID；第二步查看 CDN 日志或缓存管理工具中的实际键值，而不是只看后台开关；第三步使用带版本参数的测试 URL 验证新请求是否绕过旧缓存。测试时不要直接清空生产缓存，否则会掩盖根因并扩大流量冲击。
常见踩坑包括把“刷新 URL”误认为“刷新所有变体”，只刷新首页却没有清理相同路径的查询参数版本，或者在修复键规则后仍被旧缓存继续命中。刷新策略应覆盖受影响的对象前缀、站点范围和必要变体，再逐步提高刷新比例观察回源与命中率。ServLlama 可用于集中记录规则变更和缓存命中日志，帮助把临时排查转为长期对照。修复后还应验证不同 Host、不同参数组合及回源响应，确保内容串站不会再次发生。
继续沿着实际请求排查，关键是把缓存键与业务对象的身份对应起来。边缘节点可能对协议、主机名大小写、默认端口、路径中的点段、百分号编码及参数顺序做不同归一化；应用签名若依赖原始 URL，归一化后反而会验签失败。应同时记录客户端请求、边缘回源请求和最终缓存键，确认差异发生在哪一层。
查询参数不要“一刀切”。应按站点建立查询参数白名单：商品 ID 等业务参数必须进入缓存键，语言、分页和实验参数需明确分组；时间戳、随机数、埋点参数通常应过滤。还要定义重复参数、空值、顺序和大小写规则，否则同一页面会分裂成多个对象，或让无意义参数制造大量缓存分片。
源站隔离不能只看 IP。若多个域名共用回源地址，而缓存键只取路径、Host 或 SNI 没有形成独立维度，内容就可能串站。回源时应使用经过校验的规范主机名，并明确 X-Forwarded-Host、X-Forwarded-Proto 与重定向地址的生成规则；边缘配置、源站虚拟主机和应用生成绝对 URL 的规则必须一致。
缓存污染往往源于键设计过宽：登录态、Cookie、Authorization、语言、User-Agent 或响应错误码本不应公开缓存，却与公开页面共用对象。边缘层与源站层都要执行缓存资格判断，尤其尊重 Cache-Control: private/no-store；对 3xx、4xx、5xx 和重定向分别设置策略，避免一次故障把异常页长期固化。
刷新应按影响面选择精确 URL、目录前缀、标签或整站清除，而不是遇到旧内容就全量刷新。带查询参数的变体、重定向、错误对象和 Host 命名空间可能不会被单 URL 刷新覆盖；提交后还要等待任务完成并从多个边缘节点复测。应先修正键与缓存规则，再定向清理旧对象，防止旧键在回源后再次被填充。
可执行检查清单：①分别保存原始请求与回源请求，比对路径、参数、Host、协议及缓存键；②列出必须保留、可忽略和需分组的三类参数；③验证不同域名、端口及重定向不会共享缓存对象；④检查私有响应、错误响应和鉴权请求是否被错误缓存；⑤按 URL、参数变体、前缀和命名空间选择刷新范围；⑥从多个区域复测状态码、响应头、缓存标识、年龄及正文内容，并保留清理前后的对照记录。
