可直接在 log_format 中引用 $sent_http_cache_control 变量记录实际发出的 Cache-Control 响应头，实现全站缓存策略落地审计；该变量真实反映最终生效值，不受配置静态值或后端覆盖影响，配合日志分析工具可快速识别缺失、违规或未控缓存行为。
可以直接在 log_format 中引用 $sent_http_cache_control 变量，把每个响应实际发出的 Cache-Control 头记录进访问日志，从而实现对全站缓存策略的落地审计。
为什么用 $sent_http_cache_control 而不是其他变量
这个变量代表 Nginx 实际发送给客户端的 Cache-Control 响应头内容，它能真实反映最终生效的缓存指令。不同于配置中写的静态值或程序动态设置但可能被覆盖的情况，$sent_http_cache_control 是“结果导向”的——只要响应里真发了这个头，它就一定有值；没发就是空字符串。这对审计是否真正合规非常关键。
- 它不依赖后端是否设置了该头，而是抓取 Nginx 最终打包发出的内容
- 如果用了
add_header、proxy_hide_header或expires指令，它的值会自动体现最终效果 - 配合日志分析工具（如 ELK、Grafana Loki），可快速统计：哪些路径缺失缓存头、哪些设成了
no-store、哪些 max-age 违反安全基线
如何配置 log_format 记录缓存头
在 http 块中定义一个带缓存头的日志格式，例如：
log_format cache_audit '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$sent_http_cache_control';
然后在 server 或 location 中启用：
access_log /var/log/nginx/cache-audit.log cache_audit;
- 建议单独使用一个日志文件，避免和主日志混在一起影响分析效率
- 若某些 location 明确不走缓存（如登录接口），其
$sent_http_cache_control为空，也会被如实记录，便于识别“漏控”区域 - 注意：该变量仅对 HTTP/1.1 响应有效；HTTP/2 下部分头字段处理逻辑略有差异，但
Cache-Control仍会被映射并捕获
结合日志分析做合规检查
拿到日志后，可按以下维度快速判断是否符合常见合规要求（如等保2.0、GDPR、内部安全规范）：
-
敏感接口禁缓存：筛选含
/api/user/profile、/admin/等路径的日志，检查$sent_http_cache_control是否为no-store或private，而非public, max-age=3600 -
静态资源强缓存：对
.js、.css、.png等资源，检查是否普遍设置了public, max-age=31536000类长时效策略 -
缺失缓存头即风险：日志中出现大量空白值（即未设置任何
Cache-Control），说明该响应受浏览器默认启发式缓存影响，不可控，应列为整改项
注意事项与边界情况
这个方法高效，但也有几个细节必须留意：
-
$sent_http_cache_control是大小写敏感的变量名，拼错（如$sent_http_Cache_Control）会导致始终为空 - 若使用了
proxy_buffering off或流式响应（如 SSE），部分早期 Nginx 版本可能无法捕获该头，建议使用 1.19.0+ 版本 - 当多个
add_header Cache-Control ...出现在同一作用域时，Nginx 默认只保留最后一个，$sent_http_cache_control记录的就是那个最终生效的值 - 它不会记录
Expires或ETag，如需全面审计缓存策略，需额外加入$sent_http_expires和$sent_http_etag
