304 Not Modified是Nginx对客户端条件请求的合规响应，非主动生成；其带宽节省依赖源站正确返回Last-Modified/ETag及304响应体跳过机制，单次可节省约49.9–299.7 KB。
304 Not Modified 不是 Nginx 主动“生成”的响应，而是它在满足 HTTP 协议协商缓存规则时，对客户端条件请求的合规响应。它的带宽节省效果直接取决于响应体是否被跳过——而这一点由 Nginx 的静态文件处理机制和源站行为共同决定。
304 触发的前提：两个头必须协同工作
浏览器能否发出 If-Modified-Since 或 If-None-Match，取决于上一次响应是否携带了 Last-Modified 或 ETag。Nginx 对静态文件（如 .js、.css、.png）默认基于文件系统 mtime 自动设置 Last-Modified；若启用了 etag on，还会计算并返回 ETag。这两个头缺一不可——没有它们，浏览器不会发起条件请求，304 就无从谈起。
- 检查你的 location 块是否误用了
add_header Last-Modified ""或unset $sent_http_last_modified，这会主动抹掉关键头 - 确保 Nginx 有权限读取文件元数据；否则 mtime 获取失败，Last-Modified 可能为空或为 epoch 时间，导致条件验证失效
- 对于动态接口（如 /api/list），Last-Modified 和 ETag 必须由后端显式生成并返回，Nginx 不会自动补全
Nginx 如何判断是否返回 304
当收到带 If-Modified-Since 的请求时，Nginx 并不执行复杂比对逻辑。它只做一件事：检查目标文件的修改时间是否 ≤ 请求头中的时间戳。如果成立，且文件未被删除或权限异常，就立即返回 304，且完全不读取文件内容、不构造响应体。
- 响应仅含状态行（HTTP/1.1 304 Not Modified）和基础头（如 Date、Server、Connection）
- 响应体大小通常为 0 字节，极少数情况含空行或极简头（如 Content-Length: 0），但标准实现中不应出现
- 这个过程发生在内核态文件系统调用层面，开销远低于读取并传输 KB 级资源
单次 304 节省多少带宽？可量化估算
节省量 = 原始资源响应体大小。假设一个 CSS 文件为 120 KB，首次返回 200 响应体为 120 KB + 约 300 字节头；第二次命中 304，则响应仅为约 250 字节头。单次节省 ≈ 119.75 KB，压缩率超 99.8%。
- 实测典型静态资源（JS/CSS/图片）平均体积在 50–300 KB 区间，对应单次 304 节省 49.9–299.7 KB
- 对移动端用户，按 1 Mbps 下行带宽计算，120 KB 传输耗时约 960 ms；304 响应耗时通常
- 若某资源日均被复访 1 万次，其中 85% 走 304，则日省带宽 ≈ 10,000 × 0.85 × 120 KB ≈ 1.02 TB
为什么有时看到 304 却没省带宽？常见陷阱
表面返回 304，但实际仍传了完整响应体，往往是配置或源站行为破坏了协议语义。
- 后端动态接口返回 304 时附带了响应体或 Content-Length: 非零头，Nginx 可能拒绝解析或降级为 200
- 使用了
proxy_pass但源站未正确支持协商缓存：Nginx 发出 If-Modified-Since 后，源站返回 200（哪怕内容未变），则缓存被覆盖，304 机会彻底丢失 - location 中错误设置了
expires off或add_header Cache-Control "no-cache"，导致浏览器不缓存，也就不会带 If-Modified-Since 再来
