如何根据日志中304响应占比调整Nginx与浏览器缓存协商策略？

本文共计1288个文字，预计阅读时间需要6分钟。

304响应占比是衡量缓存是否有效的直接指标。它本身不体现‘好坏’，但异常波动（如从30%降至1%）常常暴露服务端缓存逻辑、ETag/Last-Modified生成机制或客户端行为链路中的关键问题。优化并非追求100%的304，而是让该比例稳定反映真实数据复用率，并在动态与复用之间取得合理平衡。

从日志中识别 304 异常波动的真实信号

Nginx access log 中可通过 $status 字段统计 304 数量，再结合总请求数计算占比。但仅看比例不够，需联动分析以下字段：

• 关注请求路径一致性：确认统计的是目标 API（如 /api/home/list），排除静态资源或错误路径干扰；
• 检查 User-Agent 分布：若 304 比例暴跌仅发生在某类客户端（如新版 App），说明其请求头可能未携带 If-None-Match 或 If-Modified-Since；
• 比对响应头字段：用 log_format 添加 $sent_http_etag 和 $sent_http_last_modified，验证 200 响应是否稳定输出 ETag/Last-Modified；若大量 200 响应缺失这些头，协商缓存根本无法启动；
• 排查时间窗口特征：是否集中在某次发布后？是否与运营配置变更、CDN 缓存穿透、或服务端本地 cache key 混用（如共享了用户无关的缓存实例）强相关？

定位服务端 ETag / Last-Modified 生成逻辑缺陷

304 失效的常见根源不在 Nginx 配置，而在上游应用生成的响应头不可靠：

• ETag 不稳定：若 ETag 基于动态内容（如插入当前时间戳、用户 session ID、随机数），每次响应都不同，浏览器永远无法命中 304；
• Last-Modified 精度不足：文件系统级修改时间只能精确到秒，若同一秒内多次更新资源，或资源内容未变但元数据被刷新，会导致误判；
• 动态数据混入静态标识：如主页 list 接口含用户进度（动态）+ 关卡配置（静态），却用全量数据哈希生成 ETag，只要任一用户进度变化，所有用户都会失效——这正是知识库中“重量级 list api 304 比例暴跌”的根本原因；
• 建议做法：对混合型接口，将静态部分与动态部分分离计算；例如 ETag = base64(sha256(静态配置版本 + 运营配置 hash))，动态字段不参与哈希。

调整 Nginx 层协商缓存协同策略

Nginx 本身不生成 ETag 或 Last-Modified，但可强化校验逻辑与缓存分发一致性：

• 避免代理层覆盖原始头：确认 upstream 服务返回的 ETag 和 Last-Modified 未被 Nginx 或 CDN 错误清除或重写；禁用 etag off; 等覆盖指令；
• 启用 if_modified_since 精确模式：在 location 块中设置 if_modified_since exact;，使 Nginx 严格比对秒级时间（而非默认的“大于等于”逻辑），减少因时钟偏差导致的误判；
• 配合 Cache-Control 控制协商触发时机：对适合协商缓存的接口，返回 Cache-Control: public, max-age=0, must-revalidate，确保浏览器每次都会发起条件请求，而不是跳过协商直接回源；
• 慎用 add_header 覆盖 ETag：除非有强理由（如统一降级为弱 ETag），否则不要在 Nginx 中用 add_header ETag ... 替换上游值，易造成前后端标识不一致。

验证与持续监控的关键动作

优化后必须闭环验证，而非仅依赖日志比例回升：

• 抓包比对典型请求流：用 curl 或浏览器开发者工具，检查第二次请求是否携带 If-None-Match，服务端是否返回 304 且响应头不含响应体；
• 构造边界用例测试：模拟静态数据未变但用户态更新，验证 ETag 是否不变；模拟运营配置更新，验证 ETag 是否变更并触发 200；
• 建立 304 占比基线告警：对核心接口设置浮动阈值（如 ±8%），当连续 5 分钟低于均值下限即触发告警，早于业务侧感知性能下降；
• 关联后端缓存命中率：若服务端自身有本地缓存（如 Redis），同步监控其命中率；304 比例骤降 + 后端缓存命中率同步下跌，大概率指向缓存 key 设计缺陷。