Nginx 如何在 Nginx 中配置 if_modified_since 指令优化文件修改时间匹配

Nginx中if_modified_since指令用于优化协商缓存，支持exact（严格相等）、before（服务端修改时间≤客户端时间则返回304）和off（忽略请求头、始终返回200）三种模式，配合expires modified可实现文件不变时全程本地缓存、一改即更新的智能缓存效果。

在 Nginx 中配置 if_modified_since 指令，核心目标是让浏览器在重复请求静态资源时，能根据文件真实修改时间智能返回 304 Not Modified，而不是无条件重传。它不改变文件内容，只优化协商缓存的判断逻辑。

理解 if_modified_since 的三种行为模式

该指令控制 Nginx 如何比对响应头中的 Last-Modified 与客户端请求头里的 If-Modified-Since：

1. exact（默认）：严格时间相等才返回 304。只要服务端文件修改时间与客户端携带的时间毫秒级不一致，就返回 200 —— 最保守、最常见，适合大多数场景。
2. before：只要服务端文件的最后修改时间 ≤ 客户端的 If-Modified-Since 值，就返回 304。更宽松，适合希望延长缓存命中率、且能接受“略旧但未变”判定的场景。
3. off：完全忽略客户端发来的 If-Modified-Since 请求头，始终返回 200 和完整资源 —— 等价于禁用协商缓存，一般仅用于调试或特殊兜底策略。

在 location 块中正确启用并调优

无需额外模块（Nginx 1.7.34+ 默认内置），直接在对应静态资源路径下配置即可：

location /assets/ {root /var/www/app;expires modified 7d;# 主动缓存 + 关联文件修改时间if_modified_since before;# 启用宽松比对etag on;# 保持 ETag 协商（默认已开）}

注意点：

1. 不需要手动添加 Last-Modified 头，Nginx 会自动基于文件系统 mtime 生成；
2. 避免写 add_header Last-Modified ""，除非你明确要清除上游注入的错误值；
3. 若使用容器或只读挂载，mtime 可能不可靠，此时 before 或 exact 都可能失效，建议配合 ETag 或构建时注入版本哈希。

验证是否生效的关键检查项

打开浏览器开发者工具 → Network 标签页，观察一个静态资源的两次请求：

1. 首次请求：响应头应含 Last-Modified 和 ETag，状态码为 200；
2. 刷新后请求：请求头应带 If-Modified-Since 和 If-None-Match，若配置正确且文件未改，响应应为 304，且响应体为空；
3. 手动 touch 修改文件后再刷新：应看到新 Last-Modified 值，并返回 200 + 新内容。

搭配 expires modified 提升时效性

expires modified 365d 不是设固定过期时间，而是将缓存有效期动态锚定到文件修改时刻之后一年。它和 if_modified_since 是互补关系：

1. expires modified 决定浏览器是否发起条件请求（即是否带 If-Modified-Since）；
2. if_modified_since 决定收到条件请求后，Nginx 怎么比对并返回 304 还是 200。

两者合用，才能实现「文件不变则全程走本地缓存，一改即立刻更新」的效果。