海外源站回源带宽优化，重点不是单纯增加缓存时间，而是减少同一内容被重复拉取的次数，并避免缓存规则误伤动态请求。较稳妥的做法，是让 CDN 边缘缓存、区域缓存和源站分工，再用请求合并处理同一时刻涌入的缓存未命中。
先找出带宽消耗在哪一层
先按路径或内容类型查看源站出站字节数、请求数、缓存命中率和响应码。大文件下载可能请求不多但传输量大；热门小文件则可能因频繁过期造成请求密集。还要留意带查询参数的 URL、频繁变化的 Cookie，以及部署后集中失效的缓存，它们都可能让原本相同的内容落到不同缓存对象上。
观察周期应覆盖业务高峰和一次典型发布；如果流量有明显日周期，只看几分钟的数据容易误判。将源站带宽与 CDN 回源请求、回源流量按时间对照，才能分清是缓存未命中增多、对象变大，还是访问量本身增长。
缓存分层：让内容尽量在近处命中
常见链路是用户请求先到 CDN 边缘节点，边缘未命中时再查区域缓存或回源盾，最后才访问源站。边缘缓存适合高频、可共享的内容；区域缓存能把多个边缘节点的重复回源集中起来，尤其适用于用户分布广、单个节点请求量不高的场景。代价是多一层缓存配置与排错路径，且效果取决于 CDN 是否支持相应层级及其规则。
先区分可缓存与不可共享内容
带版本号的图片、字体和下载文件，内容更新时更适合换 URL，并设置较长缓存时间；更新频繁的 HTML 可使用较短 TTL，具体长度应结合发布频率和容忍旧内容的时间决定。账户页面、购物车等个性化响应，通常不应被公共缓存共享。检查缓存键时，保留确实影响响应的参数或请求头，剔除无关参数，避免同一资源被拆成大量缓存副本。
请求合并：减少同一时刻的重复回源
缓存分层解决请求到哪里命中，请求合并解决缓存未命中时多个并发请求是否各自打到源站。若热门对象刚好过期，大量用户同时请求，合并机制可让其中一个请求取回内容，其余等待并复用结果。它对突发并发有效，但对持续高带宽的大文件传输、不同缓存键的请求或慢速源站本身，不能直接消除流量。
以 Nginx 代理缓存为例，可评估 proxy_cache_lock，让同一缓存键的请求等待首个填充请求；配合 proxy_cache_use_stale updating，在更新期间按规则继续提供旧缓存。应同时检查等待超时和缓存更新失败时的行为：等待过久会增加用户延迟，超时后也可能出现重复回源。指令是否适用，还要看现有 Nginx 版本、缓存区配置及代理链路。
按步骤上线并验证效果
- 建立基线：记录源站出站流量、回源请求数、主要 URL 类型和高峰时段，区分缓存命中与未命中。
- 整理缓存规则：按静态文件、可缓存页面和个性化接口分类，检查缓存键、TTL、响应头及查询参数处理。
- 启用分层与合并：先对可安全共享的热门对象试运行，确认区域缓存和请求合并只作用于相同缓存键。
- 逐步放量复核：在相近流量条件下比较源站出站字节、回源请求数、错误率和用户等待时间；若延迟或错误上升，检查锁等待、过期策略和源站响应。
海外源站回源带宽优化要同时看流量与体验：缓存命中上升并不自动代表方案成功，过期内容、个性化数据泄露风险和请求排队都需要纳入验收。
常见问题
缓存命中率高，为什么源站带宽仍然大？
命中率按请求数计算时，大量小文件命中可能掩盖少数大文件回源。还应按字节统计，并检查下载文件、视频片段等大对象。
请求合并会不会让用户一直等待？
可能。为等待设置合理上限，并评估是否可在更新期间提供仍可接受的旧内容；具体策略取决于内容时效要求。
所有查询参数都应从缓存键删除吗？
不应如此。会改变响应内容的参数必须保留；只有确认与内容无关的追踪参数，才考虑规范化或忽略。
先做分层还是先做请求合并？
先梳理缓存规则和缓存键，再启用合并；已有区域缓存时，合并通常应作用在实际负责填充该层缓存的位置。