源站已经用Cache-Control安排好缓存节奏，CDN却把它静音，静态文件被频繁回源拉高费用，动态接口又可能被意外缓存，用户看到旧页面。
CDN加速配置里的“忽略缓存头”，说到底是把源站响应的缓存指令全部作废，节点不再读取Cache-Control、Expires，也不看Last-Modified和ETag，它只认控制台里设置的默认缓存时间，或者自定义规则，问题是，多数人并不会为所有文件类型单独配一套精确规则，开关一开，规则又不全，麻烦就开始在账单和用户反馈里冒头。
忽略缓存头有什么后果？它先把“源站指令”静音了
源站每次返回文件,都会在响应头里写明：这个文件能缓存多久、能不能被公共缓存，可以把这些响应头理解为源站写给CDN节点的便签，节点拿到便签，就知道哪些能缓存、缓存多久、什么时候必须回源再要一份，开启忽略缓存头后，这些便签被直接揉掉，节点只能按照控制台里的默认策略处理，或者干脆不缓存，结果就是，源站精心设计的缓存策略失效。
源站缓存头被静音后，节点只能靠默认策略猜测
主流CDN平台的默认缓存时间往往比较保守,部分平台对未识别文件类型默认不缓存，或者只缓存几分钟，对于已经通过Cache-Control: max-age=86400明确缓存一天的静态文件，如果忽略了源站缓存头，节点可能只缓存十分钟，缓存时间变短，意味着同一个文件会被更多用户触发回源，源站请求量上升，CDN命中率下降，很多时候，运维人员看到命中率突然变差，查半天才会发现忽略缓存头这个开关被误开了。
静态资源设置了Cache-Control却被CDN忽略怎么办？先看响应头
如果怀疑线上文件没有按源站策略缓存,不要急着改源站代码，先做几件事：
- 用curl -I命令查看文件响应头，curl -I https://example.com/static/app.js
- 重点看Cache-Control、Expires、Age、X-Cache、Via这几个字段。
- 如果Cache-Control明明是max-age=86400，但Age一直很小，或者X-Cache频繁显示MISS，就要进CDN控制台排查缓存配置。
- 进入域名管理的缓存配置页面,找“忽略源站缓存头”或类似开关。
- 确认该开关是否开启,开启后，源站写得再标准也没用。
curl -I返回的信息很直观，正常命中时，Age会随着缓存时间的推移逐步增长，X-Cache显示HIT，如果Cache-Control: max-age=86400，但Age始终停在个位数，X-Cache频繁显示MISS，基本可以判断源站缓存头没有被执行，此时再查CDN缓存配置中的“忽略源站缓存头”，大概率已经开启。
忽略Cache-Control和遵循缓存头哪个好？一张对比表说清
不少人在配置时纠结：忽略Cache-Control和遵循缓存头哪个好，答案不是绝对的，要看业务里静态资源和动态接口的比例。
| 对比维度 | 遵循源站缓存头 | 忽略源站缓存头 |
|---|---|---|
| 静态资源更新 | 源站改Cache-Control即可生效 | 必须同步改CDN配置，容易漏改 |
| 动态接口安全 | 源站可精确控制no-cache | 可能被默认长缓存，用户看到旧数据 |
| 回源频率 | 按源站计划执行 | 取决于CDN默认值，常偏高 |
| 流量费用 | 相对稳定 | 回源流量项容易异常增加 |
| 多地域一致性 | 节点遵循同一源站指令 | 节点各自回源时间不同，缓存时长可能不一致 |
行业共识认为,动态接口的缓存时间不应超过业务可容忍的延迟窗口，忽略缓存头以后，这个窗口可能被拉长到不可控，静态文件倒是可以统一管理，但前提是规则足够细，如果只是简单开启忽略缓存头，却没有针对路径和文件类型做拆分，基本等于让CDN盲目执行一套半成品策略。
忽略缓存头带来的三类隐性成本：价格、源站、用户
CDN回源流量费用增加原因：忽略缓存头常被忽视
回源流量计费是CDN账单里容易被忽略的一项,缓存命中率低，节点就要向源站请求文件，产生回源
流量，忽略缓存头往往不会直接报错，但会让缓存命中率缓慢下降，短期内看，每一次回源多出的流量不大，时间一长，回源流量费用会明显增加，从公开的CDN计费规则看，回源流量通常按GB计费，单价不像普通流量那样容易被注意，多数情况下，静态资源流量占大头，一旦这些文件不再被长缓存，回源流量费用增加就会比预想更快。
源站压力上升与高峰雪崩
缓存时间缩短后,源站压力不会立刻失控，但遇到活动高峰、突发事件或大流量场景，问题会被放大，原本缓存一天的文件，在忽略缓存头后只缓存几分钟，大量用户同时访问，节点集中回源，源站可能被打到响应变慢，响应变慢后，用户刷新页面，又触发更多回源，高峰雪崩往往不是源站本身变差，而是缓存策略被一个配置项悄悄破坏。
被缓存导致用户看到旧数据
忽略缓存头还有反向麻烦,有些动态接口适合短缓存或不缓存，源站通常会返回Cache-Control: no-cache或private，一旦开启忽略缓存头，CDN可能按照控制台里给全站设置的长缓存时间处理这些接口，用户看到的登录状态、价格、库存、订单信息就可能变成旧数据，这种问题比回源费用更难查，因为接口本身没有报错，只是数据不对。
北京企业CDN缓存配置忽略缓存头的典型场景
一家北京的信息服务平台,源站部署在北京，CDN节点覆盖全国，该平台运营人员为了让活动页加载更快，在CDN控制台开启了忽略缓存头，并设置统一缓存时间一小时，活动页里有一部分接口返回实时库存和价格，源站本已对这些接口返回no-cache，忽略后，华北节点和华南节点的回源时间不同，缓存版本也有差异，北京用户看到的价格和广州用户看到的价格不一致，客服收到投诉后，排查发现接口响应头正常，问题出在CDN配置，恢复遵循源站缓存头后，不同地域的价格才重新一致，这个场景说明，忽略缓存头不单影响速度，还会放大地域间缓存不一致的问题。
正确的缓存配置思路：让配置项各司其职
忽略缓存头并不是完全不能开,它适合某些源站缓存头混乱、无法统一修改的情况，但多数业务更稳妥的做法，是让源站管策略，CDN管分发。
- 静态目录,如图片、JS、CSS，源站统一返回长Cache-Control，CDN选择遵循源站。
- 动态目录,如/api/、/user/，源站返回no-cache或private，CDN不缓存或短缓存。
- 对特殊文件使用版本号或文件指纹,更新时直接换文件名，避免旧缓存影响。
- 在CDN控制台按路径和文件类型设置自定义缓存规则,优先级高于默认策略。
- 定期查看命中率、回源流量、X-Cache状态，出现异常时优先检查缓存相关开关。
实际操作中,进入域名管理后，依次检查缓存配置、回源配置、HTTP头配置，多数问题都藏在这些选项里，修改后不要只看控制台报表，用curl命令从多个地域模拟请求，确认Age和X-Cache符合预期。
忽略缓存头相关常见问题
CDN忽略缓存头导致回源增加，日志里有什么特征？
回源日志里,同一个静态文件会被反复请求，缓存命中率下降，MISS占比明显升高，如果源站响应头里Cache-Control设置正常，但CDN日志显示同一URL频繁回源，就需要检查忽略缓存头是否开启，日志本身不会直接写上“忽略缓存头”几个字，但MISS比例和回源频率会给出很直接的提示。
忽略缓存头一定会增加回源流量费用吗？
不一定,如果CDN默认缓存时间设置得比源站更长，且内容本身适合长缓存，费用可能不增反降，但这种情况风险更高，因为动态接口一旦被长缓存，用户看到旧数据的概率会明显增加，多数配置不当的案例里，回源流量费用减少不是主要表现，异常缓存才是。
北京地域节点缓存不一致和忽略缓存头有关吗？
有关,忽略缓存头后，不同地域节点依赖统一规则但不一定在同一时间回源，源站内容更新后，各节点刷新缓存的时间窗口不同，华北和华南可能出现版本差异，CDN节点会各自按统一规则执行，但实际回源时间不一致。