源站回源带宽成本优化，不能简单等同于“把响应压小”。如果大量请求绕过缓存，压缩只能降低单次传输量，无法消除持续回源；若压缩方式又让缓存对象产生多个版本，还可能拉低缓存命中率。先分清请求为什么回源，再决定压缩发生在哪一段，才不容易省下字节却增加请求量。
先判断是缓存穿透，还是正常未命中
缓存未命中可能是新内容首次访问、缓存过期或主动刷新；缓存穿透则常见于请求始终查不到可缓存对象，例如随机拼接的查询参数、反复访问不存在的资源，或因个性化规则被排除缓存。两者都会访问源站，但治理方法不同。只提高缓存时长，对随机请求通常无效。
排查时按路径、状态码和请求特征查看回源日志，同时比较请求命中率与字节命中率：前者反映请求数量，后者反映流量字节。若小响应频繁命中、大响应仍频繁回源，带宽账单未必会随请求命中率改善。源站回源带宽成本优化应以实际回源字节为核心指标，并同步观察回源请求量、响应状态码和缓存绕过原因。
压缩省下的字节，可能被版本分裂抵消
gzip、Brotli 等压缩可缩小适合压缩的文本响应，但效果受内容类型、原始大小和压缩级别影响；图片、视频等已压缩格式往往收益有限。更关键的是，压缩收益发生在哪一段：若源站先压缩再传给边缘节点，源站到边缘的回源字节会减少；若边缘节点取到未压缩对象后才压缩给用户，节省的是边缘到用户的流量，不能直接减少这次回源传输。
还要检查缓存如何处理 Accept-Encoding。若压缩响应和未压缩响应被视为不同对象，缓存键可能出现多个变体；访问分散时，每个变体的命中机会变少，回源次数随之上升。反过来，忽略编码差异却把一种编码的响应交给不支持该编码的客户端，也会造成内容错误。压缩率应与缓存命中率、源站 CPU 和回源字节一起评估，而不是单独追求更高数值。
用分层措施处理高风险请求
先收紧缓存边界
对公开、内容一致且可重复使用的 GET 响应设置缓存；对含用户身份、权限差异或实时个人数据的响应，避免共享缓存。检查随机参数是否确实影响内容：确认无关后再规范化缓存键，不能为了命中率直接删除所有参数。对确定不存在且重复访问的资源，可设置短时负缓存；时间应结合内容变更和误判风险决定，不能把可能很快创建的资源长期当作不存在。
再选择压缩位置和范围
如果瓶颈是源站出口带宽，优先确认源站发往缓存层的响应是否已压缩；如果瓶颈在用户侧流量，则边缘压缩更直接。文本类响应可按内容类型启用压缩，并先从较低风险的级别灰度验证。对于已经压缩的媒体文件，不应仅因“开启压缩”就假设还能明显节流。源站回源带宽成本优化的目标是减少真实回源字节，同时维持正确的内容协商和缓存复用。
按步骤验证，避免只看压缩率
选定一段有代表性的观察窗口，记录回源字节、回源请求数、请求命中率、字节命中率、状态码分布和源站 CPU。
从日志中找出反复回源的路径，区分过期、主动绕过、不可缓存、随机参数和不存在资源等原因。
一次只调整一类规则，例如先处理无关查询参数，再验证压缩策略；避免同时改缓存键、缓存时长和压缩设置，导致结果无法归因。
小范围灰度后，对比调整前后的回源字节与回源请求量，并抽查不同 Accept-Encoding 请求的响应是否正确。若压缩率提升但回源请求增加或字节命中率下降，应检查缓存变体和绕过规则，必要时回退。
常见问题
提高压缩级别就能降低回源带宽吗？
不一定。只有压缩发生在源站到缓存层的传输之前，才会减少该段回源字节；压缩还可能增加源站 CPU。
缓存穿透能靠延长缓存时间解决吗？
通常不能。随机参数或不可缓存请求不会因延长其他对象的缓存时间而停止回源，应先找出绕过原因。
如何判断优化是否有效？
同时观察回源字节、回源请求量和字节命中率，并验证响应正确性。只有压缩率上升而回源数据未下降，不足以证明源站回源带宽成本优化成功。
