清洗链路接入后，访问请求会经过新的处理节点再到达源站。配置看起来正确，不代表回源时的协议、请求头和转发条件都能按预期工作。开展CDN回源与流量清洗链路的兼容性测试，重点是逐项比对接入前后的请求路径与源站响应，而不是只看页面能否打开。
先画清请求路径，再确定测试边界
先记录用户请求经过的节点，例如 CDN 边缘、流量清洗中心和源站，并标明每一段使用的协议、端口、证书及转发规则。确认清洗中心是直接连接源站，还是仍由 CDN 发起回源；两种拓扑的来源地址、TLS 终止位置和日志位置可能不同。
测试前选定可观测的页面或接口，并保留一份未接入清洗链路时的基线：响应状态、关键响应头、耗时区间、源站日志和错误日志。可用一台 NGINX 源站作为受控验证对象，但实际测试应以自己的源站配置和业务请求为准。
按顺序验证协议与回源行为
- 核对协议组合。分别确认客户端到边缘、边缘到清洗节点、清洗节点到源站采用的协议。若回源使用 HTTPS，检查证书有效期、证书名称与回源主机名是否匹配，以及中间节点是否按预期校验证书。不要把前端协议可用当作回源协议可用。
- 检查主机名和端口。核实回源 Host、SNI（TLS 握手使用的服务器名称）与源站虚拟主机配置一致。用不同站点或环境的测试域名分别验证，避免请求落入默认站点后仍返回一个看似正常的页面。
- 覆盖请求类型和响应。测试常见读取请求、带请求体的提交请求、较大响应，以及需要长时间保持连接的业务。检查重定向、压缩、分块传输和源站超时设置；若经过任一节点后响应状态、内容长度或关键响应头变化，应定位是哪一段产生变化。
- 验证健康检查和回退。确认健康检查访问的是有效路径，成功条件与源站实际响应相符；再在可控环境中模拟源站不可用，观察是否切换到备用源站或按预期返回错误。不要在生产高峰期直接制造故障。
转发规则要测“命中”和“未命中”
规则测试不应只验证预期转发成功，还要检查相邻路径和不符合条件的请求。对每条规则记录匹配条件、动作、优先级及预期源站，重点检查路径前缀边界、尾部斜杠、大小写处理和查询参数是否影响匹配。若规则按请求头或来源网络区分流量，应确认清洗节点传递的值可信，源站只信任受控代理写入的转发信息，避免客户端伪造数据绕过判断。
可以按“明确命中、边界输入、明确不命中”三类逐条验证，并从 CDN、清洗设备和源站日志交叉核对最终去向。若 CDN 缓存可能掩盖源站变化，测试时使用受控的未缓存资源，或先确认缓存状态；否则看到旧内容，无法判断回源规则是否生效。
记录结果并分阶段放量
CDN回源与流量清洗链路的兼容性测试应形成可复查的记录：测试时间、请求条件、预期路径、实际响应、各节点日志和结论。先在测试环境或小范围流量中完成协议与规则验证，再逐步扩大覆盖；每一步都对比错误率、响应耗时和源站负载，并设定可执行的回退条件。具体阈值应依据已有基线、业务容忍度和监控能力制定，不宜套用统一数值。
如果出现异常，按链路逐段缩小范围：先确认 CDN 是否发起回源，再看清洗节点是否接收并转发，最后检查源站日志和访问控制。这样比一次性调整多条规则更容易找到不兼容点。完成所有路径验证后，再将CDN回源与流量清洗链路的兼容性测试结果纳入配置变更记录，便于后续升级或切换时复测。
常见问题
只检查首页是否能打开够吗？
不够。还要覆盖不同转发规则、提交请求、错误响应及缓存状态，否则部分路径故障可能被遗漏。
回源加密后，最容易忽略什么？
常见遗漏是回源主机名、SNI 与证书名称不匹配，以及清洗节点是否实际执行证书校验。
怎样判断故障来自哪一层？
用相同测试请求对照 CDN、清洗节点和源站日志，按请求是否到达各节点逐段排查，并保留时间戳与响应结果。
每次规则变更都要重测吗？
至少复测受影响的协议、路径和相邻规则；涉及共用转发条件或回源设置时，应扩大回归范围。