美国服务器接入CDN后，如何验证静态资源命中率与回源延迟？

验收时，最容易把“CDN 域名能够返回 200”误认为配置已经生效。真正需要确认的是：静态请求是否由边缘节点直接提供，哪些请求仍然触发了美国服务器回源，以及回源过程消耗了多少时间。只有把命中率、源站触达率、回源延迟和终端首字节时间分开观察，才能判断静态资源是否真正摆脱了跨地域访问带来的影响。

静态资源命中率应以 CDN 的缓存状态、请求日志或统计报表为主，不能仅凭浏览器看到的 200 或 Age 响应头判断。回源延迟则应读取 CDN 的 Origin Fetch、Origin Response Time 等源站链路指标；浏览器或 curl 测得的 TTFB 属于客户端到边缘节点的整体体验，不能直接当成回源耗时。下面按交付验收中的关键对象逐项核对。

一、先固定验收范围和统计口径

1. 静态资源范围：只统计真正交给 CDN 缓存的请求

验收前需要列出本次 CDN 规则实际覆盖的资源，而不是直接把整个域名的请求量作为分母。典型静态资源包括：

• JavaScript、CSS、字体文件；
• PNG、JPEG、WebP、SVG、GIF 等图片；
• 视频封面、公开下载文件及其他不包含用户私密数据的文件；
• 带内容版本号的资源，例如 app.8f3a1.js、style.v202501.css。

HTML 页面、登录接口、订单接口、实时数据接口通常不应与静态资源混算。即使 HTML 也经过 CDN，如果它采用短缓存、按 Cookie 区分或每次动态生成，也应单独建立统计口径。

建议在验收表中先固定以下字段：

如果 CDN 控制台同时提供“缓存命中率”和“流量命中率”，应记录两者的定义。前者通常按请求次数统计，后者按响应字节统计；压缩、分片和大文件下载都会使两者出现明显差异。

2. 分母：区分可缓存请求和被主动绕过的请求

缓存命中率最常见的计算方式是：

请求命中率 = 由边缘缓存直接提供的请求数 ÷ 可缓存静态请求总数

但“可缓存静态请求总数”不能简单等于全部请求数。以下请求可能被 CDN 明确标记为绕过缓存：

• 响应包含 Cache-Control: private、no-store；
• 响应带有 Set-Cookie，而 CDN 默认不缓存此类响应；
• 请求携带会参与缓存规则判断的 Cookie；
• 请求包含鉴权信息或特定请求头；
• 路径被配置为不缓存；
• 查询参数、Vary 规则或缓存键策略导致对象分裂；
• 请求使用了不适合当前缓存策略的方法或范围请求。

这些请求不能一边放入分母，一边又用“为什么没有命中”来否定静态缓存配置。正确做法是把它们分为两组：一组是本来就应缓存但未命中的请求，另一组是明确排除在缓存范围之外的请求。

3. 记录两种命中结果，避免把“边缘返回”与“完全不回源”混为一谈

CDN 常见的缓存状态包括 HIT、MISS、BYPASS、EXPIRED、REVALIDATED 等，但具体名称由服务商定义。验收时至少应区分下面三类：

如果 CDN 启用了源站保护层、区域中间缓存或 Origin Shield，边缘节点显示 MISS，并不必然意味着美国服务器收到了一次请求。因此，判断源站压力时应优先查看“Origin Request”“Origin Fetch”或源站访问日志，而不是只统计边缘 MISS 数。

二、验证静态资源是否真正命中 CDN

1. 资源清单：覆盖高频、小文件和大文件

只抽查一个 JavaScript 文件，无法代表整套静态资源。建议从 CDN 报表或源站访问日志中选取三类对象：

• 请求次数最多的资源，例如公共 CSS、主 JavaScript、字体；
• 流量占比高的资源，例如图片、安装包、视频封面；
• 规则容易出问题的资源，例如带查询参数、带版本号、存在多种压缩格式的文件。

每个资源应记录完整 URL、响应状态、Content-Type、Content-Length 或实际传输大小、缓存相关响应头和 CDN 缓存状态。URL 必须保持完全一致，不要在测试时随意追加随机参数。随机参数通常会生成新的缓存键，只能证明“新 URL 如何处理”，不能证明原始资源的命中情况。

2. 响应头：用于确认缓存线索，不作为唯一证据

可以使用 GET 请求读取响应头，同时丢弃响应正文。相比 curl -I，GET 更接近浏览器实际加载静态文件的方式，因为部分 CDN 对 HEAD 和 GET 的缓存处理并不完全相同。

URL='https://static.example.com/assets/app.8f3a1.js'

curl -sS -D /tmp/cdn-headers.txt \
  -o /dev/null \
  -w 'status=%{http_code} size=%{size_download} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  "$URL"

cat /tmp/cdn-headers.txt

重点查看以下字段：

• CDN 服务商提供的缓存状态头，例如 X-Cache、CDN-Cache-Status 或其他专用字段；
• Age，用于观察对象在共享缓存中的存活时间；
• Cache-Control、s-maxage、max-age；
• ETag、Last-Modified；
• Via、Server-Timing、追踪 ID 等链路信息；
• Content-Encoding，确认 gzip、Brotli 等响应表示是否一致。

这些字段只能作为线索。Age 不存在不一定表示未命中，可能是 CDN 不对外暴露；Age: 0 也可能代表刚刚填充缓存或刚完成重新验证。X-Cache: HIT 一类字段的具体含义同样取决于服务商，最终仍应与 CDN 日志或报表中的定义对应。

3. 重复请求：验证同一对象是否从未命中转为命中

对同一个完整 URL连续请求，可以观察缓存状态是否发生变化：

URL='https://static.example.com/assets/app.8f3a1.js'

for n in 1 2 3; do
  printf 'request=%s ' "$n"
  curl -sS -D "/tmp/cdn-headers-${n}.txt" \
    -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    "$URL"
  sleep 1
done

理想情况下，在测试对象尚未进入缓存时，第一次请求可能是 MISS 或等价状态，后续请求变为 HIT。但该过程会受到以下条件影响：

• 第一次请求可能已经由其他访问者提前填充；
• 三次请求可能被调度到不同边缘节点；
• CDN 可能存在多层缓存；
• 对象已过期并进入重新验证流程；
• 查询参数、Cookie、Accept-Encoding 或其他请求头使缓存键不同。

因此，“第一次是 MISS、第二次是 HIT”只是一个可观察现象，不能单独作为整站命中率的证明。正式验收应以一段时间内的 CDN 日志统计为准。

如果生产环境没有专用测试对象，不建议为了验证缓存而随意清空高流量资源。清理生产缓存会造成回源突增，且清理动作通常不能即时恢复。确需进行冷缓存验证时，应使用已审批的测试资源、独立路径或带明确版本号的新对象，并记录测试时间、资源 URL 和影响范围。

4. 缓存规则：检查响应头与 CDN 覆盖策略是否一致

静态资源是否适合缓存，通常要同时看源站响应头和 CDN 规则。常见判断关系如下：

带内容哈希或版本号的 CSS、JavaScript、字体文件，通常适合设置较长的共享缓存时间；文件内容变化时使用新文件名。没有版本号的固定文件如果设置很长 TTL，则必须同时验证发布后的失效或更新机制，否则可能出现“命中率很高，但用户拿到旧文件”的情况。

5. 用 CDN 报表重新计算请求命中率

假设某个统计周期内，过滤掉 HTML、API 和明确绕过缓存的请求后，得到以下模拟数据：

按照“完整命中”口径：

完整请求命中率 = 92,000 ÷ 100,000 = 92%

按照“是否触达源站”口径：

源站触达率 =（3,000 + 5,000）÷ 100,000 = 8%

这两个结果都可能是正确的，但回答的是不同问题。92%表示有多少请求完全由边缘缓存提供；8%表示有多少可缓存请求仍然让源站参与了处理。如果把重新验证也笼统归入命中，就可能高估美国服务器的实际卸载效果。

同时建议计算字节维度：

字节命中率 = 由缓存提供的响应字节数 ÷ 可缓存响应总字节数

字节命中率适合衡量带宽卸载，不能替代请求命中率。大量小文件可能使请求命中率很高，但大文件频繁回源仍会消耗大量源站带宽；反过来，少量大文件命中也可能迅速抬高字节命中率。

三、验证美国服务器的回源延迟

1. 先确认“回源延迟”具体测的哪一段

回源延迟不是一个固定含义。不同平台可能将以下一个或多个阶段合并统计：

验收记录中应写明指标名称和平台定义。例如，“回源延迟 p95 为 180 ms”还不够，还应注明它是 Origin TTFB、Origin Response Time，还是完整文件传输时间。不能用 ping 美国服务器的结果代替 HTTP 回源延迟，也不能用浏览器 TTFB 直接代替 CDN 到源站的时间。

2. 只在回源请求样本中计算回源延迟

完整命中的请求没有访问美国源站，不能给它填入一个“回源延迟”。正确的统计关系是：

• 命中请求：观察 Edge TTFB 和完整下载时间；
• MISS、过期、重新验证请求：观察 Origin TTFB、Origin Response Time 和 Edge TTFB；
• 源站访问日志：用于核对 CDN 报表中的源站请求数量和处理时间；
• 错误请求：单独统计 4xx、5xx、超时和连接失败。

建议至少查看 p50、p95 和 p99，而不是只看平均值。平均值可能被大量快速命中请求拉低，掩盖少量回源超时。特别是源站位于美国、访问者分布在欧洲或亚洲时，回源链路的尾部延迟可能比平均值更能说明问题。

3. CDN 报表与源站日志交叉核对

CDN 侧的 Origin Fetch 指标可以回答“边缘发起了多少次回源以及耗时多少”；美国服务器日志则可以回答“源站实际收到了多少请求以及处理用了多久”。两者时间范围、时区、请求 ID 和重试机制必须对齐。

如果美国服务器使用 Nginx，可以在已有访问日志基础上增加请求耗时字段。下面是示例配置，适用于 Nginx 的 http 配置上下文：

log_format cdn_audit
    '$time_iso8601 '
    'request="$request" '
    'status=$status '
    'bytes=$body_bytes_sent '
    'request_time=$request_time '
    'upstream_response_time=$upstream_response_time '
    'cache_control="$sent_http_cache_control" '
    'etag="$sent_http_etag"';

access_log /var/log/nginx/cdn_audit.log cdn_audit;

其中：

• $request_time 是 Nginx 从接收请求到完成响应的耗时，单位为秒；
• $upstream_response_time 适用于 Nginx 还要访问上游服务的场景；
• 如果 Nginx 直接从本地磁盘提供静态文件，$upstream_response_time 可能显示为 -，此时应重点看 $request_time；
• 源站日志通常只能反映请求到达源站后的处理和发送过程，不能单独拆出 CDN 到源站之间的 TCP、TLS 和网络耗时。

修改日志配置前，应先备份现有 Nginx 配置并确认日志磁盘空间。完成后使用当前发行版支持的配置检查命令验证，确认无误再按现有运维流程平滑加载；不要直接覆盖原配置。若环境不是 Nginx，应使用对应 Web 服务的访问日志字段，不要照搬上述变量。

如果 CDN 为每次回源请求附带请求 ID，最好将该 ID一并写入源站日志。这样可以将 CDN 报表中的慢请求与源站具体日志关联起来，区分以下情况：

• 请求在 CDN 与源站之间建立连接时变慢；
• 请求已经到达源站，但源站应用或磁盘读取变慢；
• 源站很快返回，但大文件传输时间较长；
• CDN 因超时重试，造成源站看到多次相似请求。

4. 按缓存状态拆分延迟，否则结论会被混合

一个常见的错误是把所有 CDN 请求的 TTFB 放在一起计算。假设某个周期内有 95% 的请求命中边缘，命中请求 TTFB 很低，5% 的请求因大文件 MISS 回源耗时很长，整体平均值可能看起来不错，但首次访问体验仍然较差。

建议至少形成以下数据组：

例如，一组模拟验收结果可能是：边缘命中请求 Edge TTFB 的 p95 为 48 ms，MISS 请求 Origin Response Time 的 p95 为 180 ms，MISS 请求最终返回给访问者的 Edge TTFB p95 为 260 ms。这个结果可以说明缓存命中时访问者不必等待美国源站，但不能说明所有请求都能保持 48 ms，也不能把 180 ms直接理解成完整页面加载时间。

四、确认是否达到“接近本地体验”

1. 终端测试看 Edge TTFB，不把它当作回源指标

从访问者角度，浏览器或 curl 测得的 time_starttransfer 更接近“客户端收到首字节需要多久”。它包含客户端到 CDN 边缘节点的网络延迟、TLS、边缘处理，以及在 MISS 时的回源等待。

因此，应将它与 CDN 内部的 Origin Response Time 放在一起看：

• Edge TTFB 明显下降、Origin 延迟不变：说明访问者多数请求已经在边缘命中；
• Edge TTFB 仍然较高、Origin 延迟较低：可能是访问者到边缘的网络、TLS 或边缘排队问题；
• Edge TTFB 与 Origin 延迟都较高：需要继续关注源站处理、美国出口或回源连接；
• 命中率高但完整下载时间仍长：可能是文件过大、边缘出口或客户端带宽限制，而不是缓存未生效。

浏览器开发者工具中的“from disk cache”“from memory cache”只代表浏览器本地缓存，不代表 CDN 命中。测试时应关闭浏览器缓存或使用新的浏览器会话，并在 Network 面板中确认请求确实发往 CDN 域名；同时结合 CDN 日志核对，避免把本地缓存误报为 CDN 命中。

2. 按实际访问区域建立测试矩阵

美国服务器作为源站时，测试至少应覆盖实际用户较多的边缘区域。例如可以按美国东部、美国西部、欧洲、东亚等区域建立观察组，具体位置以业务用户分布为准。

每个区域都应测试同一组资源，并分别记录：

• 完整命中和 MISS 两种状态；
• HTTP 状态码和响应大小；
• Edge TTFB 的 p50、p95；
• 完整下载时间；
• 是否发生连接失败、超时或 5xx；
• CDN 实际命中的边缘节点或区域信息。

测试时应尽量保持协议、URL、请求头和文件版本一致。若一个区域请求到的是 app.8f3a1.js，另一个区域却请求了新版本文件，两者不能直接比较。对于大文件，还要单独记录文件大小，因为 500 KB 文件和 50 MB 文件的完整下载时间没有可比性。

3. 建立允许的源站基线，但不要为测试公开源站

要判断 CDN 是否改善体验，需要有一个可比较的基线。基线可以来自：

• 接入 CDN 前同一监控点访问原域名的历史数据；
• 受控监控环境访问美国源站的授权地址；
• 内部网络或专用测试通道对源站的测量；
• 同一时间段内的 MISS 请求与 HIT 请求对比。

如果源站域名或 IP 仅用于 CDN 回源，不应为了方便测试而将其公开暴露。直接访问源站时还可能绕过 CDN 的安全策略、压缩策略和协议协商，测试结果只能作为链路基线，不能等同于真实用户体验。

4. 用相同资源比较命中与未命中

“接近本地体验”不是只看一个时间阈值，而是看同一资源在不同缓存状态下的差异。可以采用如下验收表：

如果命中请求的 Edge TTFB和完整下载时间相对源站直连明显降低，同时 CDN 报表显示源站请求量下降，才可以认为 CDN 分离对静态资源交付产生了可观察效果。若只看到命中率上升，却没有看到边缘 TTFB改善，应继续检查访问者是否命中了浏览器缓存、测试是否被调度到远端边缘、资源是否过大，以及 CDN 是否对响应进行了重新验证。

五、常见误判与异常核对

1. 200 不等于 HIT

缓存命中和未命中都可能返回 200。HTTP 状态码只说明这次请求成功返回了资源，不说明资源来自哪里。应同时查看 CDN 状态字段、源站请求日志和 Origin Fetch 指标。

同样，304 也不能直接视为 CDN 完整命中。304 可能是浏览器向 CDN 发起条件请求，也可能是 CDN 向美国源站进行条件验证。需要结合请求链路和 CDN 状态判断。

2. Cache-Control: no-cache 测试会改变结果

为了“强制刷新”而在测试命令中加入 Cache-Control: no-cache、Pragma: no-cache 等请求头，可能触发重新验证或绕过缓存。这样的结果不能用于衡量正常访问下的命中率。

如果要测试正常命中，应使用普通 GET 请求；如果要测试重新验证，则应单独标记为另一类测试，不要与正常请求混在一起。

3. 查询参数可能制造大量缓存碎片

以下 URL 对缓存键来说可能是不同对象：

/assets/app.js
/assets/app.js?v=202501
/assets/app.js?utm_source=mail
/assets/app.js?device=mobile

需要确认 CDN 是否忽略特定跟踪参数、是否保留版本参数，以及源站是否会根据参数返回不同内容。不能在没有核对缓存键规则的情况下直接把带参数和不带参数的请求合并统计。

如果业务确实需要多个版本或设备表示，应分别统计；如果参数只是无关的营销标记，则应由业务和 CDN 管理员共同确认是否可以规范化，不能仅为提高命中率而随意删除参与内容生成的参数。

4. Cookie、鉴权和 Vary 可能使看似静态的文件无法共享

公共静态文件通常不应依赖用户 Cookie 生成内容。如果静态响应携带 Set-Cookie，或请求中的 Cookie 参与缓存规则判断，CDN 可能主动绕过缓存。Vary: Accept-Encoding 用于区分压缩表示较为常见，但 Vary: User-Agent、语言或自定义请求头可能显著增加缓存版本数量。

验收时应抽查高频资源的请求头和响应头，确认缓存键中的差异确实有业务必要。对于字体、图片和 JavaScript 等公共对象，若不同用户拿到的是相同内容，却因为无关 Cookie 被拆成多个缓存对象，命中率会被明显拉低。

5. 命中率上升但源站仍然很忙

出现这种情况时，重点核对以下对象：

• 是否只统计了请求命中率，却忽略大文件的字节回源量；
• CDN 是否存在中间缓存，边缘 MISS 但源站未收到请求；
• HTML、API 或下载接口是否仍然占用了源站带宽；
• 重新验证请求是否被算成命中；
• 查询参数是否生成了大量低频缓存键；
• 缓存过期时间是否过短；
• 源站是否收到 CDN 重试请求；
• 统计周期是否包含发布、批量失效或缓存预热。

命中率只能说明缓存结果的比例，不能单独代表源站负载。源站 CPU、出口带宽、请求数、5xx 和响应时间仍需单独核对。

六、交付验收记录应保留哪些证据

验收留证不需要保存所有访问日志，但应能让后续人员复核“统计范围、命中结果和回源耗时”。建议保留以下内容：

• CDN 缓存规则及适用路径；
• 参与统计的静态资源清单；
• 统计周期、时区和请求过滤条件；
• 请求命中率、字节命中率、源站触达率；
• CDN 缓存状态字段的定义或控制台截图；
• Origin Response Time、Origin Fetch Time 的 p50、p95、p99；
• 关键资源的响应头样本；
• 不同区域的 Edge TTFB 和错误率；
• 源站同一时间段的访问量、状态码和请求耗时；
• 测试对象、测试时间以及是否为冷缓存或热缓存。

可以用下面的表格作为最终核对单：

如果完整命中率符合项目目标，但源站触达率仍高，应优先检查重新验证、缓存键和中间缓存；如果源站触达率已经下降，但边缘 p95 仍高，应把问题转向用户到边缘的网络、边缘节点选择、TLS 和文件大小；如果只有某一类资源异常，则应回到该资源的响应头和 CDN 路径规则，而不是重新调整整站缓存策略。

最终验收应以“静态资源是否被边缘稳定交付”“美国服务器实际回源次数和耗时是否下降”“目标区域的 Edge TTFB 是否改善”三组证据共同判断。命中率解决的是缓存是否生效，回源延迟解决的是未命中时源站链路是否可接受，二者必须分开记录，再结合实际访问区域和资源类型进行复核。