Nginx 默认启用 Last-Modified 头，自动基于文件 mtime 设置，匹配静态文件且未禁用时即可响应 If-Modified-Since 并返回 304；需确保文件可读、mtime 准确，且非反向代理覆盖场景。
在 Nginx 中，Last-Modified 是 HTTP 条件请求的核心机制之一，用于实现静态资源的协商缓存。Nginx 默认对静态文件（如 .js、.css、.png 等）自动设置 Last-Modified 响应头，值为文件的最后修改时间（基于文件系统 mtime）。只要客户端在后续请求中带上 If-Modified-Since 请求头，Nginx 就会自动比对并返回 304 Not Modified，无需传输响应体。
确认 Nginx 默认行为是否启用
Nginx 默认开启 Last-Modified 头输出，无需额外配置。但需满足以下前提：
- 请求由
location块匹配到静态文件（例如通过root或alias指向真实路径） - 文件存在且可读，且其 mtime 可被正常获取（注意：某些挂载方式如某些容器卷或网络文件系统可能不准确）
- 未显式关闭该功能（如配置了
last_modified off;）
手动控制 Last-Modified 行为
若需调整默认逻辑，可在 http、server 或 location 块中使用以下指令：
-
last_modified on;：启用（默认值，通常不用写） -
last_modified off;：完全禁用Last-Modified响应头（此时也不会处理If-Modified-Since） -
if_modified_since exact | before;：控制比对逻辑
–exact（默认）：要求时间完全相等才返回 304
–before：只要请求头中的时间 早于或等于 文件 mtime，就返回 304（更宽松，兼容部分客户端时钟偏差）
验证条件请求是否生效
可通过 curl 快速测试：
curl -I http://example.com/style.css
查看响应头中是否有 Last-Modified: ...
curl -I -H "If-Modified-Since: Wed, 01 Jan 2025 00:00:00 GMT" http://example.com/style.css
若文件未更新，应返回 HTTP/1.1 304 Not Modified，且无 Content-Length 和响应体。
注意事项与常见问题
以下情况可能导致 Last-Modified 不起作用：
- 使用了
sendfile on;但底层文件系统不支持精确 mtime（如某些 overlayfs 或只读镜像），导致 mtime 恒为 0 或异常 - 静态文件由构建工具生成，但构建过程覆盖文件时未保留原始 mtime（例如
cp --preserve=timestamps未启用） - 反向代理场景下，上游服务已设置
Last-Modified，而 Nginx 作为中间层未透传或覆盖了该头，建议用proxy_pass_request_headers on;并检查是否误加add_header覆盖 - 浏览器开发者工具 Network 面板中，看到“from memory cache”或“from disk cache”，说明缓存策略已生效，不一定触发网络请求，此时看不到 304 —— 可用无痕模式或禁用缓存重新测试
