可以直接在 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
评论(0)