缓存是提升网站性能的重要手段，但在后台管理系统、支付回调页、接口联调环境这类场景里，我们恰恰需要内容实时生效，这时候就要用到nocache策略。nginx本身不直接提供一个叫nocache的开关，它需要通过组合多条指令来实现，而配置位置稍有偏差，结果就会大相径庭。本文从响应头原理入手，给出几种可落地的配置方案，并把常见的坑逐一说明。
一、理解nginx中的缓存体系与nocache的真实含义
很多人把nocache简单理解为“不缓存”，这其实是第一个误区。HTTP协议中的Cache-Control: no-cache并不代表禁止缓存，它的含义是“可以缓存，但使用前必须向源服务器重新验证”。真正禁止任何缓存存储的是no-store。如果混淆了这两者，配置出来的效果可能与预期完全相反。
nginx中涉及缓存的层面有三个：浏览器本地缓存、nginx自身的proxy_cache代理缓存、以及上游CDN节点的缓存。做nocache策略时必须想清楚要禁掉哪一层。比如只给浏览器发了no-cache，但nginx的proxy_cache还在工作，用户拿到的依然可能是几分钟前的旧内容。反过来，只关闭了proxy_cache而没管响应头，浏览器仍会按默认启发式规则缓存页面，表现为刷新无效、强制刷新才有效。
此外还有一个容易被忽略的点：Cache-Control: max-age=0与no-cache在大多数浏览器上行为接近，都会触发条件请求（携带If-Modified-Since或If-None-Match），服务器返回304时仍然能节省流量。而no-store则完全不留下任何副本。根据业务需求选择合适的值，比一刀切地全部禁掉更高效。
二、三种实现nocache的配置方案与对比
第一种方式是使用expires指令。这是最简洁的写法：
location /api/ {
expires -1; # 返回Expires为过去时间
add_header Cache-Control "no-cache";
}
expires -1会把Expires头设置为1970年附近的时间，迫使浏览器认为响应已过期。需要注意的是，expires指令默认会同时生成一个Cache-Control: max-age头，与后面手动add_header的内容可能重复或冲突，所以建议显式写明，避免出现两个Cache-Control头导致浏览器行为不确定。
第二种方式是完全手动控制响应头，适合需要精细区分的场景：
map $request_uri $is_nocache {
default 0;
~*^/admin/ 1;
~*^/order/detail 1;
~*\.(json|do)$ 1;
}
server {
listen 80;
server_name example.ipipp.com;
location / {
proxy_pass http://127.0.0.1:8080;
# 满足条件时不使用代理缓存也不存储到缓存
proxy_no_cache $is_nocache;
proxy_cache_bypass $is_nocache;
add_header Cache-Control $is_nocache;
# 借助map把1和0翻译成完整的头值
# 见下方说明
}
}
上面的map只输出了0或1，还需要一层转换。更实用的写法是直接在map里映射完整的头值：
map $request_uri $cache_policy {
default "max-age=3600, public";
~*^/admin/ "no-cache, no-store, must-revalidate";
~*\.(css|js|png)$ "max-age=2592000, immutable";
}
server {
listen 80;
add_header Cache-Control $cache_policy;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
这种map加add_header的组合是生产环境中最推荐的做法，规则集中管理，新增路径只需改map，不用到处修改location块。第三种方式是针对已经启用了proxy_cache的服务，使用proxy_cache_bypass和proxy_no_cache配合cookie或变量，实现“同一URL对登录用户不缓存、对匿名用户缓存”的精细化控制，这在内容型网站里非常实用。
三、常见问题与容易踩的坑
第一个高频问题：add_header写了却不生效。原因通常是add_header具有继承的特殊性——当当前层级（server或location）中出现了任何add_header指令时，上层所有的add_header都会被覆盖，而不是叠加。很多人在某个location里加了一条自定义头，结果发现server层写的Cache-Control消失了，就是这个原因。解决办法是把Cache-Control的add_header在需要的location里重复声明一次。
第二个问题是与后端应用服务器响应头的冲突。如果Tomcat或PHP已经输出了自己的Cache-Control，nginx再用add_header追加，客户端可能收到两个同名头。规范做法是用proxy_hide_header Cache-Control;先隐藏上游的头，再由nginx统一输出，保证头唯一且可控。
第三个问题是304与no-cache的配合。设置no-cache后浏览器每次都会发条件请求，如果后端没有正确处理If-None-Match，每次都返回200全量内容，性能反而下降。所以要确认后端支持ETag或Last-Modified的校验逻辑，让验证请求能命中304，这样既保证了实时性，又不会浪费带宽。
最后提醒两点：一是调试时用curl -I配合-H "Cache-Control: no-cache"来观察真实响应头，不要只依赖浏览器开发者工具，因为浏览器可能命中本地缓存而不发请求；二是修改配置后务必用nginx -t检查语法再nginx -s reload，同时注意fastcgi缓存、proxy缓存、CDN三层是否都按预期工作，缺一层都可能出现“配置了nocache却还是旧内容”的怪现象。把这些细节理顺，你的缓存策略才能真正精准落地。