XML缓存失效主因是MIME类型错误、location匹配偏差、缺失ETag/Last-Modified及gzip与缓存顺序不当；需配置application/xml类型、精准location块、确保校验头存在、压缩前置。
XML 文件被当成 text/plain 返回，浏览器不缓存
Nginx 默认不识别 .xml 后缀的 MIME 类型，常返回 Content-Type: text/plain，导致浏览器拒绝缓存（尤其 Safari 和部分移动端 WebView）。这不是缓存配置没生效，是根本没进入缓存流程。
解决方法很简单：在 http 或 server 块里补上类型声明：
types {
application/xml xml;
}
注意别写成 text/xml —— 现代浏览器对 text/* 类型默认禁用强缓存，application/xml 才能配合 Cache-Control 正常工作。
location 匹配不到 XML 文件，缓存指令无效
常见错误是只在 location / 里加了 expires 或 add_header Cache-Control，但静态 XML 文件实际由其他 location 处理（比如被 location ~ \.xml$ 拦截，或落入 location /static/ 下）。
检查方式：用 curl -I https://yoursite.com/data/config.xml 看响应头是否含 Cache-Control；再查 Nginx 日志里的 access_log，确认命中的是哪个 location。
实操建议：
- 把缓存指令直接写进最具体的
location块，比如location ~ \.xml$ - 避免依赖继承：Nginx 的
add_header不会从外层继承到内层location，必须显式重复写 - 如果 XML 在子目录（如
/api/v1/），优先用前缀匹配：location ^~ /api/v1/，比正则更高效且不易漏
Cache-Control max-age=0 导致每次 304，但没真正提速
很多人设了 add_header Cache-Control "public, max-age=3600"，但发现浏览器仍发条件请求（带 If-None-Match），响应是 304 Not Modified。这说明服务端没生成 ETag 或 Last-Modified，或者文件内容不变但 inode 变了（比如 rsync 覆盖导致 mtime 更新）。
关键点：
-
max-age生效的前提是响应头同时包含ETag或Last-Modified；Nginx 对静态文件默认开 ETag，但若用了sendfile on+ ext4 文件系统，可能因内核行为导致 ETag 不稳定 - 如果 XML 是纯配置、极少更新，直接关掉校验更干脆：
add_header Cache-Control "public, max-age=86400, immutable"（注意immutable需 Nginx ≥ 1.13.9） - 避免用
expires epoch或负值，容易误写成立即过期
gzip 压缩和缓存顺序搞反，XML 变大了
XML 本身可压缩率高，但若把 gzip 放在缓存之后（比如在 location 里先 expires 再 gzip on），Nginx 会缓存未压缩版本，后续请求还得重复压缩——既浪费 CPU，又让首字节时间变长。
正确做法是让压缩发生在缓存之前：
- 确保
gzip_vary on开启，这样 Nginx 缓存会区分Accept-Encoding，存 gzip 和非 gzip 两份 - 不要在
location里单独开gzip，统一在http块配好，靠gzip_types包含application/xml - 验证：用
curl -H "Accept-Encoding: gzip" -I URL看是否返回Content-Encoding: gzip且Vary: Accept-Encoding
缓存 XML 最难的不是配指令，而是确认它真被当二进制资源处理了——类型、路径、压缩、校验，四个环节只要一个断掉，浏览器就退回“每次都问一遍”的状态。
