nginx中$send_http_etag变量用于记录响应头实际发送的etag值，需1.7.3+版本支持，配合log_format记录并分析304响应与if-none-match匹配情况，可统计协商缓存命中率。
在 Nginx 中，$sent_http_etag 变量记录了响应头中实际发送给客户端的 ETag 值（如果存在），是分析协商缓存（如 If-None-Match 请求是否命中 304）的关键依据。要监控静态资源的协商缓存效率，核心思路是：在日志中记录 ETag 发送情况 + 对应请求是否返回 304，并通过日志分析统计命中率。
确认 $sent_http_etag 在 log_format 中可用且生效
Nginx 1.7.3+ 版本才正式支持 $sent_http_* 系列变量（包括 $sent_http_etag），旧版本会输出空字符串或报错。使用前请检查版本：
在 http 或 server 块中定义带该变量的日志格式，例如：
log_format cache_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$sent_http_etag" "$upstream_http_etag" '
'$request_length $request_time '
'$sent_http_cache_control "$http_if_none_match"';
注意：
– $sent_http_etag 是服务端最终写入响应头的 ETag（可能由 Nginx 自动生成，如启用 etag on; 且未显式设置）；
– $upstream_http_etag 仅在使用 proxy_pass 时有意义，用于对比上游是否透传或修改了 ETag；
– 同时记录 $http_if_none_match，便于关联请求与响应。
确保静态资源正确生成并返回 ETag
协商缓存依赖 ETag（或 Last-Modified）存在且一致。需确认以下几点：
- 静态文件服务配置启用了 ETag 生成（默认开启）：
etag on; - 未用
add_header ETag "";或类似方式清空/覆盖 ETag - 未启用
expires或add_header Cache-Control但忽略验证类指令（如缺少must-revalidate或no-cache会导致浏览器跳过协商） - 对 gzip 压缩后的响应，Nginx 默认为不同编码生成不同 ETag（需确保
gzip_vary on;开启，否则可能因 Vary 头缺失导致缓存混乱）
通过日志识别协商缓存命中行为
典型协商缓存流程：客户端带 If-None-Match: "xxx" 发起请求 → 服务端比对 ETag → 相同则返回 304，不返回响应体，且仍会写出 ETag 响应头（即 $sent_http_etag 非空）。
因此，304 日志中若 $sent_http_etag 有值，且其值与请求头中的 $http_if_none_match 一致，即为一次有效协商缓存命中。
示例日志片段（已用上述 cache_log 格式）：
可据此编写脚本（如 awk / Python）统计：
– 总静态资源 GET 请求（按后缀过滤：.js, .css, .png 等）
– 其中 status = 304 且 $sent_http_etag == $http_if_none_match 的请求数
– 协商缓存命中率 ≈ 304 且 ETag 匹配数 / 总静态 GET 数
补充建议：区分强/弱 ETag 与避免误统计
$sent_http_etag 值可能以 W/"..." 开头（弱校验），此时客户端比对规则略有不同（需忽略 W/ 前缀再比较）。日志分析时建议统一 strip 掉 W/ 和双引号再做匹配，例如：
另外，排除以下干扰项：
– 动态接口（非静态资源）返回的 ETag（建议按 location 或后缀限定日志范围）
– 重定向（301/302）或错误响应（4xx/5xx）中偶然出现的 ETag
– CDN 或中间代理篡改、删除了 ETag 或 If-None-Match 头（可通过比对 $upstream_http_etag 与 $sent_http_etag 判断）
