很多人把业务放在香港大带宽服务器上，再接入 CDN，本以为万事大吉：用户访问走 CDN，源站压力应该很小。但实际运行中常见一个反直觉的问题——用户侧看起来还行，源站带宽却被打满，一到高峰就出现回源拥堵，甚至拖慢整站。
这类问题本质上不是“CDN 没用”，而是CDN 没有真正替你分担流量。要解决，就得把“回源为什么发生、发生在哪、发生多少”搞清楚，而不是直接加带宽。
先从一个关键认知说起：CDN 只有在命中缓存时才省源站带宽，一旦未命中，请求还是会打到源站。所谓“回源带宽瓶颈”，本质就是 MISS 太多或回源方式不合理，导致源站被频繁访问。
排查的第一步，不是看服务器，而是看 CDN 侧数据。绝大多数 CDN 控制台都会提供“命中率”“回源流量”“回源请求数”等指标。这里重点看两个数：命中率和回源带宽。
如果命中率只有 60% 或更低，那问题基本已经很明确了——缓存没有生效。一个健康的静态资源站点，命中率通常应该在 90% 以上，甚至更高。如果远低于这个值，说明大量请求在不断回源。
接下来就要搞清楚：为什么没命中?
最常见的原因，是缓存策略没配好。比如很多人部署完 CDN 后，默认规则是“动态内容不缓存”，而你的网站恰好是图片没设置缓存头，CSS/JS 没设置过期时间，接口返回带有 no-cache
结果就是：每次请求都被 CDN 判定为不可缓存，直接回源。
可以从响应头入手检查，比如：
curl -I https://yourdomain.com/image.jpg如果看到 no-cache、no-store，或者根本没有缓存头，那基本可以确定是缓存策略问题。
修复方法通常有两种：一是在源站(Nginx/Apache)上设置缓存头，二是在 CDN 控制台强制缓存某些路径(如 /static/*)。
另一个非常常见的问题是“动态参数导致缓存失效”。对于 CDN 来说，这些参数可能会被当成不同资源，每一个请求都变成新的缓存键，结果就是“看起来是同一个文件，实际上全部 MISS”。这种情况在前端构建工具或接口请求中非常常见。
解决思路是：在 CDN 侧开启“忽略参数缓存”或指定只保留关键参数。
再往下排查，就要看是否存在“缓存穿透”。比如：用户请求大量不存在的文件，爬虫扫路径(/abc123.jpg) ，恶意请求随机URL，这些请求永远不会命中缓存，每一次都会回源。如果量大，就会直接拖垮源站带宽。
这类问题可以通过访问日志看出来。比如：
tail -f access.log如果看到大量 404 请求，路径杂乱无章，那基本就是被扫了。解决方法包括：CDN 开启缓存 404(短时间)，增加 WAF 或防护规则，限制异常请求频率
还有一种隐蔽情况是“缓存时间太短”。比如你设置了缓存，但 TTL 只有 10 秒或 30 秒。这样在高并发下，缓存刚过期，大量请求同时回源，就会形成“回源风暴”。
这时候需要把静态资源缓存时间拉长，比如：图片1 天以上，JS/CSS几小时到几天，不常变的资源甚至可以一周，配合版本号(如文件名带 hash)，可以避免更新问题。
如果缓存策略没问题，但回源依然高，那就要看是否使用了“私有资源”或“鉴权访问”。比如：登录后才能访问的内容，带 token 的URL，防盗链参数
这些内容通常无法缓存，或者 CDN 不敢缓存。这种情况下，回源是正常现象，只能通过架构优化，比如拆分静态与动态内容、引入分层缓存等方式来缓解。
再一个容易被忽略的点，是“回源节点选择”。有些 CDN 在全球有多个回源节点，如果你的源站在香港，但 CDN 回源节点在美国或其他地区，就会产生额外跨境延迟，甚至带宽瓶颈。
可以通过 CDN 设置“回源区域”或“回源加速”来优化，让回源尽量在同区域完成。
如果以上都正常，还可以进一步看服务器侧。比如用工具观察实时带宽，看看是不是某些 IP 或某些路径占满带宽。结合日志分析，可以定位是否是某类请求导致。
同时也要确认服务器本身没有其他流量来源，比如：被直接绕过 CDN 访问(源站 IP 暴露)，API被直接调用，其他服务占用带宽。
如果源站 IP 被公开，用户或攻击者可以直接访问服务器，绕过 CDN，这部分流量是不会被缓存的，也会直接占用带宽。解决方法是限制源站只允许CDN IP访问，使用防火墙或安全组控制。
从整体来看，回源带宽瓶颈通常不是单点问题，而是多个因素叠加：缓存策略不合理、参数导致 MISS、缓存时间过短、异常请求、源站暴露等。真正有效的排查方式，是从 CDN 指标入手，再逐层往下看请求类型、缓存规则和源站行为。
最后给一个实用的排查思路：先看命中率，如果低就查缓存;命中率正常但回源高，就查请求类型;如果是异常请求，就做防护;如果是正常业务，那就考虑架构优化，而不是单纯加带宽。
