If-Unmodified-Since 是 HTTP 标准请求头，Nginx 不提供同名指令但支持其语义，通过 $http_if_unmodified_since 变量配合 if、map 或透传至后端实现 412 响应，用于并发防护、CDN 协同等缓存场景。
if_unmodified_since 并不是 Nginx 的原生命令，而是 HTTP 协议标准请求头 If-Unmodified-Since 的名称。Nginx 本身不提供名为 if_unmodified_since 的配置指令，但它**完全支持该请求头的语义处理**，并在条件匹配时配合 add_header、return 或 error_page 等指令实现缓存协同控制。
理解 If-Unmodified-Since 的作用机制
该请求头由客户端（如浏览器或 API 客户端）发送，格式为：If-Unmodified-Since: Wed, 21 Oct 2024 07:28:00 GMT
它表示：“仅当资源自指定时间后未被修改过，才执行后续操作（如返回 200）；否则返回 412 Precondition Failed”。
Nginx 不主动校验该头，但会将其透传给上游（如后端应用），或借助内置变量 $http_if_unmodified_since 进行条件判断。
在 Nginx 中实现 Precondition 检查的常用方式
要让 Nginx 响应 If-Unmodified-Since，需结合资源最后修改时间（Last-Modified）进行逻辑判断。典型做法包括：
- 使用
map指令将$http_if_unmodified_since与$sent_http_last_modified做时间比较（需注意时区与格式统一） - 用
if块配合return 412实现简单拦截（⚠️ 注意：Nginx 中if在 location 外不可用于重写，且不推荐嵌套复杂逻辑） - 更可靠的做法是：将该头透传给后端应用（如 Node.js/Python），由业务代码完成时间比对和状态码返回
- 若静态文件服务场景，可配合
expires和add_header Last-Modified ...，再通过if ($http_if_unmodified_since) { ... }触发拦截
适用于哪些复杂缓存场景
该机制在以下场景中体现价值：
-
并发写冲突防护：多个客户端同时编辑同一资源（如 JSON 配置），通过比对上次读取时的
Last-Modified时间，避免“后写覆盖先写” -
CDN 与源站协同缓存：CDN 回源时携带
If-Unmodified-Since，Nginx 源站快速响应 412，减少无效内容传输 - 条件性更新接口：前端调用 PUT/PATCH 接口前附带该头，服务端据此决定是否拒绝过期版本的提交
- 离线优先应用的同步校验：PWA 应用本地缓存资源后，下次同步前检查服务端是否已被他人修改
注意事项与常见陷阱
实际部署时需特别留意：
- Nginx 默认不生成
Last-Modified响应头（静态文件除外），动态接口需后端显式设置 -
$http_if_unmodified_since是原始字符串，不能直接与$time_iso8601等比较，需用 Lua 模块（如ngx_lua）或透传至后端解析 - 避免在
if中使用proxy_pass，会导致变量失效；应改用map + proxy_pass或 upstream 分流 - 浏览器对
If-Unmodified-Since支持良好，但部分移动端 WebView 或旧版客户端可能忽略该头
