Nginx proxy_cache反向代理缓存怎么配？给上游应用提速实战

proxy_cache是Nginx当反向代理时，把后端应用服务器返回的响应整页存下来的能力。它和fastcgi_cache缓存PHP-FPM那一套不是一回事——proxy_cache缓存的是proxy_pass转发给上游（Node、Java、Gunicorn、另一台Nginx，甚至另一台机器）的HTTP响应，谁在后端、用什么语言写的它都不关心。

保哥这篇把它和fastcgi_cache的边界、最小可用配置怎么写、X-Cache-Status怎么看、登录态和动态接口怎么绕过、清缓存怎么不把上游压垮、proxy_cache_use_stale和lock怎么扛住后端抖动，一路讲到它在整套缓存体系里站哪一层。配置能抄走就用，坑也都标了出来。

先把一个最常见的混淆理清楚。很多人配缓存时，看到Nginx里有fastcgi_cache，又有proxy_cache，名字像、参数也像，就随手抄一个，结果要么不生效，要么缓存了不该缓存的东西。这两套指令的差别，根子上是Nginx把请求转给谁的差别。

fastcgi_cache用在Nginx直接对接PHP-FPM的场景——Nginx通过FastCGI协议把请求交给本机的php-fpm，再把生成的整页HTML缓存起来。WordPress、Typecho这类PHP站点走的就是这条路，保哥在 Nginx fastcgi_cache全页缓存那篇里讲得很细。

而proxy_cache是另一码事：Nginx此时是个反向代理，它用proxy_pass把请求通过HTTP协议转发给一个上游服务——可能是跑在3000端口的Node应用、跑在8080的Java服务、Gunicorn起的Python后端，甚至是另一台机器上的Nginx。proxy_cache缓存的，就是这些上游回来的响应。

一句话记牢：后端是PHP-FPM走FastCGI，用fastcgi_cache；后端是任何能讲HTTP的应用服务，用proxy_cache。这一篇专讲后者。

proxy_cache和fastcgi_cache到底差在哪？什么时候该用反向代理缓存？

两者机制几乎对称——都是Nginx把上游返回的整页响应按一个key存进磁盘，下次同样的key进来直接吐缓存，不再打扰后端。指令名也成对：fastcgi_cache_path对proxy_cache_path、fastcgi_cache_key对proxy_cache_key、fastcgi_cache_valid对proxy_cache_valid，几乎一一对应。所以会了一个，另一个的配置你看一眼就懂。

真正的差别在“缓存的是什么后端”。FastCGI是一个专门的协议，只有PHP-FPM、以及少数支持FastCGI的运行时（比如某些Python的flup）在用。绝大多数现代应用——Node的Express、Java的Spring Boot、Go的net/http、Python的Django/Flask配Gunicorn——对外都是讲HTTP的，Nginx要在它们前面挡一层，只能用反向代理，那缓存就只能是proxy_cache。

什么时候该上proxy_cache？保哥的判断很直接：当你的站点是“Nginx反向代理 + 后端应用服务”这个架构，而且后端有相当一部分页面或接口是“算一次、所有人看到的结果都一样、而且短时间内不会变”的，就值得加。典型场景有这么几类。

• SSR渲染的前端站：Next.js、Nuxt这类服务端渲染应用，首页、文章页、列表页对匿名访客是一样的，每次都让Node进程重新渲染既慢又费CPU，缓存下来后Node基本可以歇着。
• 后端API的只读热点接口：商品分类树、首页推荐位、配置项、地区列表这种读多写少的接口，缓存几十秒到几分钟，能把数据库和应用层的压力削掉一大截。
• Nginx当边缘节点反代另一台源站：你在多地部署Nginx，回源到中心机房的源站，这时候每个边缘Nginx用proxy_cache缓存源站响应，自己就成了一个迷你CDN。
• 给慢后端兜底：后端偶尔抽风、响应慢甚至挂掉时，用缓存里的旧版本顶住，比直接给用户白屏或502强得多。

反过来，纯静态站（Nginx直接发文件，根本没有上游）、或者每个请求结果都因人而异的强动态接口（购物车、订单详情、个人中心），proxy_cache要么用不上，要么得非常小心地绕过，下文会专门讲。

proxy_cache的最小可用配置怎么写？keys_zone和cache_key一步步来

配置分两块：在http {} 块里用proxy_cache_path划一块缓存区，再在location里用proxy_cache把它启用。先看最小可用的一套，保哥逐行解释。

# —— 写在 http {} 块里 ——
proxy_cache_path /var/cache/nginx/proxy
                 levels=1:2
                 keys_zone=app_cache:10m
                 inactive=60m
                 max_size=2g
                 use_temp_path=off;

upstream backend {
    server 127.0.0.1:3000;
    keepalive 32;
}

proxy_cache_path这一行的每个参数都不是摆设：

• /var/cache/nginx/proxy 是缓存文件落盘的目录，得保证Nginx运行用户（一般是www-data或nginx）有写权限。
• levels=1:2 是目录分级。Nginx把缓存文件名（key的MD5）打散到两级子目录里，避免一个目录塞几十万文件把文件系统拖垮。1:2表示用哈希末位建一级、再用末两位建二级，是最常用的写法。
• keys_zone=app_cache:10m 最关键。app_cache是这块缓存区的名字，后面location里要靠它引用；10m是内存里存放key元数据的共享内存大小，1MB大约能放8000个key，10MB能放约8万个，按你的页面数量估。注意这只是key的元数据占的内存，真正的响应体是存在磁盘上的。
• inactive=60m 指一个缓存项60分钟内没人访问就被清理器删掉——注意它和缓存有效期（proxy_cache_valid）是两回事，inactive管的是“多久没人用就回收”，nginx.org上这个值默认是10m。
• max_size=2g 是这块缓存占磁盘的上限，超了Nginx的cache manager会按最近最少使用淘汰旧的。
• use_temp_path=off 强烈建议加。默认Nginx先把响应写到一个临时目录再挪到缓存目录，跨目录移动有额外开销；设成off让它直接写进缓存目录，省一次拷贝。

然后在server / location里启用它：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_cache app_cache;
        proxy_cache_key $scheme$proxy_host$request_uri;
        proxy_cache_valid 200 301 302 10m;
        proxy_cache_valid 404 1m;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

这里几行的门道：

• proxy_cache app_cache; 启用刚才那块缓存区，名字必须对上。
• proxy_cache_key 决定“什么算同一个请求”。nginx.org上的默认值是 $scheme$proxy_host$request_uri，多数情况够用。但要当心：默认key不含Host，如果你一台Nginx反代多个域名共用一块缓存，得把 $host 加进key，否则a.com和b.com的同路径页面会串成一份，这是高频事故，下文坑里还会强调。
• proxy_cache_valid 200 301 302 10m; 给不同状态码设不同的缓存时长。成功页缓存10分钟，404这种只缓存1分钟避免把临时的找不到也长期记住。不写这一行，Nginx默认什么都不缓存（除非上游响应头自带Cache-Control）。
• add_header X-Cache-Status $upstream_cache_status; 是你的眼睛。配好后用curl就能看到这次是命中还是没命中，没有它你根本不知道缓存有没有在干活。

配完 nginx -t 测试语法，nginx -s reload 平滑重载，最小可用版就跑起来了。

缓存命中状态怎么看？X-Cache-Status各种值是什么意思？

判断缓存到底有没有生效，唯一靠谱的办法是看 $upstream_cache_status 这个变量的值。用curl带上 -I 看响应头：

curl -I https://example.com/products
# 第一次：X-Cache-Status: MISS
# 第二次：X-Cache-Status: HIT

它一共有这么几种值，每一种都对应一种情况，看懂了排障事半功倍：

• MISS：缓存里没有，这次回源去问了后端，并把响应存了下来。第一次访问必然是MISS。
• HIT：直接命中缓存，没碰后端。这是你想看到的状态。
• BYPASS：因为命中了proxy_cache_bypass的条件（比如带了登录Cookie），这次主动跳过缓存去问后端了。
• EXPIRED：缓存里有，但过期了，这次回源拿了新的。
• STALE：缓存过期了、后端又出问题了，Nginx给你吐了过期的旧版本兜底（需要配proxy_cache_use_stale）。
• UPDATING：缓存过期了，已经有另一个请求在回源更新，这个请求先拿旧的（需要配proxy_cache_use_stale updating）。
• REVALIDATED：开了proxy_cache_revalidate，Nginx带着If-Modified-Since去问后端“变了没”，后端回304没变，于是继续用旧的（省了传输响应体）。

保哥的经验是，上线后别用浏览器测——浏览器自己还有一层缓存，会把你骗得团团转，明明Nginx在MISS你却以为命中了。一律用curl -I看头，或者干脆把 $upstream_cache_status 写进access_log的日志格式里，统计一段时间的HIT率才是真实命中情况。命中率怎么看、日志怎么配，可以参考保哥在 Redis对象缓存运维那篇里讲的同一套观测思路，缓存这东西不观测就是玄学。

哪些请求绝对不能缓存？登录态和动态接口怎么绕过？

这是proxy_cache最容易出大事故的地方，没有之一。缓存的本质是“一份响应给很多人看”，那凡是“因人而异”的响应就绝对不能进缓存，否则就是把A用户的个人页缓存下来，原封不动发给后面访问的B用户——轻则信息错乱，重则把别人的订单、地址、手机号泄露出去。保哥见过不止一次匿名访客刷新首页，结果看到了某个管理员的后台，根因都是这一条没做对。

正确做法是设一个标记变量，命中“不该缓存”的条件就跳过。proxy_cache_bypass控制“读的时候要不要跳过缓存直接问后端”，proxy_no_cache控制“拿到响应后要不要存进缓存”，这两个必须成对配，缺一个都会出漏洞。

map $http_cookie $skip_cache {
    default            0;
    "~*sessionid"      1;   # 带登录会话 Cookie
    "~*logged_in"      1;
}

# 动态路径直接标记跳过
location /api/cart   { set $skip_cache 1; proxy_pass http://backend; ... }
location /account    { set $skip_cache 1; proxy_pass http://backend; ... }

location / {
    proxy_pass http://backend;
    proxy_cache app_cache;
    proxy_cache_bypass $skip_cache;   # 这两行
    proxy_no_cache     $skip_cache;   # 必须成对
    ...
}

需要跳过的典型清单，保哥给你列全：

• 带登录态Cookie的请求：只要Cookie里有会话标识，一律跳过，这是底线。
• 购物车、结算、订单、个人中心、收货地址：这些路径本身就因人而异，整段跳过。
• POST / PUT / DELETE等写请求：Nginx默认只缓存GET和HEAD，但你最好显式确认proxy_cache_methods没被乱改。
• 带认证头（Authorization）的接口：API鉴权请求基本都是因人而异的。
• 后端主动声明不缓存的：如果上游返回了 Cache-Control: no-store 或 Set-Cookie，Nginx默认会尊重它不缓存（这个行为可以用proxy_ignore_headers改，但改之前先想清楚为什么后端要发这个头）。

一个真实的翻车案例。保哥接手过一个跨境独立站，前端是Nuxt服务端渲染，运维图省事给location / 一把全开了proxy_cache，没设任何bypass。平时没事，因为大部分是匿名流量；直到有个客户登录后把商品加进购物车，那个带购物车数量的页面响应被缓存了，结果后面十几分钟内所有匿名访客打开首页，购物车角标都显示着别人的“3件商品”，点进去还能看到别人选的货。

排查半天才定位到是缓存把登录态页面串了。修法就是上面那套map + bypass，把带Cookie的请求全部放行到后端。缓存这层，省事和安全是真会打架的，宁可少缓存一点，也不能把因人而异的东西缓存了。

缓存怎么清才不会一清就把上游压垮？

内容更新了、缓存还是旧的，得清。清缓存有被动和主动两条路，用错了会出大问题。

被动清理靠proxy_cache_valid设的过期时间——到点了自然失效，下次访问回源拿新的。这是最省心的方式，对“不需要即时更新、晚几分钟没关系”的内容完全够用，能不主动清就别主动清。

主动清理是“现在马上让某个URL的缓存失效”。开源版Nginx本身不带按URL精确清除的能力，要装第三方模块ngx_cache_purge（需要重新编译Nginx或用带这个模块的发行版），配好后能发一个特殊请求点名清掉某个key。商业版Nginx Plus自带proxy_cache_purge指令，开箱即用。

# 用 ngx_cache_purge 模块的写法
location ~ /purge(/.*) {
    allow 127.0.0.1;        # 只允许本机/内网发清除请求
    deny  all;
    proxy_cache_purge app_cache $scheme$proxy_host$1;
}

这里要敲黑板的是：千万别动不动就把整块缓存全清了。保哥见过有人发版后图省事，直接 rm -rf /var/cache/nginx/proxy/*，结果一瞬间所有缓存全没了，几千个请求同时回源，后端Node进程CPU直接打满、数据库连接池被占满，站点反而比不开缓存还慢，这叫“缓存雪崩”。

正确做法是：能精确清就精确清（只清改动的那几个URL），实在要全清也得分批、或者趁低峰，最好配合下文的proxy_cache_lock防止回源风暴。如果你后端还接着数据库和对象缓存，记得这几层的更新要协调，别只清了Nginx这层、底下 Redis缓存的对象还是旧的。

怎么用stale和lock扛住上游抖动和缓存击穿？

proxy_cache真正拉开差距的，是它处理“后端不稳定”和“热点key同时过期”这两个老大难的几个指令。配好了，你的站点在后端抽风时照样稳。

第一个是 proxy_cache_use_stale，让Nginx在后端出问题时拿过期缓存兜底：

location / {
    proxy_pass http://backend;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;

    # 后端报错/超时/5xx 时，先拿过期的旧版本顶住
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    # 同一个 key 过期时只放一个请求去回源更新，其余先吃旧的
    proxy_cache_background_update on;
    # 防击穿：同一 key 只允许一个请求回源，其余排队等它
    proxy_cache_lock on;
    proxy_cache_lock_timeout 5s;
}

逐个说清楚这几个的价值：

• proxy_cache_use_stale：默认是off，意味着缓存一过期，后端又恰好挂了，用户就直接吃502。开了它，列出来的这些情况（错误、超时、5xx、正在更新）下，Nginx会把过期的旧缓存发出去，用户压根感觉不到后端出过问题。这是给后端兜底的最有效一招，外贸站尤其要配——后端跨机房、网络抖一下是常事。
• proxy_cache_background_update on：配合use_stale的updating，当缓存过期，Nginx一边把旧版本立刻发给当前用户、一边在后台默默回源更新缓存。用户永远拿到的是秒开的旧版本，新版本悄悄在后台备好给下一个人，体验最顺。
• proxy_cache_lock on：解决“缓存击穿”。设想一个热门页面缓存刚过期的那一瞬间，同时来了500个请求，没有lock的话这500个会全部回源去问后端，把后端瞬间打垮。开了lock，Nginx只放第一个请求去回源，其余499个在门口排队等它把缓存填好，然后一起吃新缓存。lock_timeout是排队的最长等待时间，超了就放它们也去回源，避免无限等。

这三个搭配起来，就是生产环境抗压的标准组合：use_stale管后端挂了的兜底，background_update管更新时的体验，lock管热点过期时的击穿。保哥的实战默认会把这三行都配上，代价几乎为零，收益是后端抖动时站点稳如老狗。这套“用旧版本扛抖动”的思路，和Magento用Varnish做全页缓存时的grace机制异曲同工，保哥在 Magento性能调优那篇里讲过Varnish那一套，原理是相通的。

反向代理缓存这一层，和CDN、整页缓存、对象缓存怎么配合？

proxy_cache不是孤立的，它在整套缓存体系里站的是“源站服务器的页面缓存”这一层，前面有CDN，后面有应用缓存和对象缓存，各管一段，配合好了才不会互相打架。

几个配合上的关键点。CDN和proxy_cache用的缓存控制头是同一套（Cache-Control、Expires），所以源站这层别和CDN那层对着干——比如源站发了no-store，CDN那层就缓存不住，你在CDN配的规则全白费。理清楚每层各缓存多久，是个系统活，保哥在 Cloudflare缓存与回源率那篇里画过一棵决策树专门讲多层怎么协调。

还有个反直觉的点：上了CDN是不是源站proxy_cache就不用配了？不是。CDN只能缓存“可公开缓存”的内容，而且CDN节点很多、各自回源，源站这层proxy_cache能把这些回源请求再削一道；更别说很多动态页面CDN默认不缓存，但在源站这层缓存几十秒（微缓存）就能挡掉绝大部分重复回源。两层是叠加关系，不是替代关系。

实战里最容易踩的坑有哪些？

把保哥这些年配proxy_cache踩过和见过的坑集中列一遍，配之前对一遍，能少走很多弯路：

• 多域名共用缓存，cache_key没加 $host：一台Nginx反代好几个站，默认key不含Host，结果a.com和b.com的 /about串成一份，访客看到别站内容。多域名场景，cache_key必须带 $host。
• bypass和no_cache只配了一个：只配bypass，登录用户的请求虽然跳过了读缓存，但响应还是被存了进去，下一个匿名访客就命中了这份个人化页面。两个必须成对。
• 把因人而异的页面缓存了：购物车、个人中心、带Authorization的接口忘了排除，直接造成数据串用户，这是最严重的事故，配完务必拿登录账号实测一遍。
• rm -rf全清缓存导致雪崩：发版后一把全清，几千请求同时回源压垮后端。要么精确清，要么配lock + use_stale兜底。
• keys_zone太小：页面多但keys_zone只给了1m，老key不停被挤出去，命中率怎么都上不去。按页面数量估够内存。
• 磁盘写满：max_size没设或设太大，缓存目录把磁盘撑满，整个Nginx写不进日志直接出问题。给max_size留余量，或单独挂一块盘放缓存。
• 没设add_header X-Cache-Status：缓存到底有没有生效全靠猜，排障时两眼一抹黑。这一行几乎零成本，必加。
• 用浏览器测命中率：浏览器本地缓存会骗你，看到的“秒开”可能是浏览器自己缓存的，不是Nginx命中。一律用curl -I或看access_log。
• 缓存目录权限不对：proxy_cache_path指的目录Nginx进程没写权限，缓存一直建不出来，全是MISS还不报错。建目录后chown给Nginx运行用户。
• 动态接口缓存时间设太长：API数据缓存了一小时，结果后端数据早变了前端还在拿旧的。读多写少的接口用微缓存（几十秒）就够，别贪长。

proxy_cache这东西，配置不难，难在“想清楚每个请求该不该缓存、缓存多久、串了会不会出事”。把上面这套机制和坑过一遍，先用curl反复验证命中状态，再逐步收紧bypass规则，基本就能稳稳地把后端压力削下来，还不出安全事故。它和服务器上其他缓存层不是二选一，而是各守一段、叠加发力。

常见问题解答

proxy_cache和fastcgi_cache能在同一个Nginx里同时用吗？

能，而且很常见。它们是两套独立的指令，缓存区也各自划分，互不干扰。比如一个location用fastcgi_pass对接PHP-FPM配fastcgi_cache，另一个location用proxy_pass反代Node服务配proxy_cache，完全可以共存。只要记住：对接谁决定用哪套——PHP-FPM用fastcgi_cache，HTTP上游用proxy_cache，别把两套的指令混着写在同一个location里就行。

为什么我配了proxy_cache，X-Cache-Status一直是MISS，从不命中？

最常见的几个原因：一是上游响应带了Set-Cookie或Cache-Control: no-cache/no-store，Nginx默认尊重它不缓存，可以用proxy_ignore_headers显式忽略（但要想清楚后端为什么发这个头）；二是请求带了登录Cookie命中了你自己配的bypass；三是没写proxy_cache_valid，Nginx不知道该缓存多久干脆不缓存；四是缓存目录权限不对，文件根本写不进去。按这个顺序排查，配合error_log看具体原因，基本都能定位到。

缓存的内容更新了，但用户还看到旧的，怎么让它立刻更新？

三个办法按场景选。能等就等——靠proxy_cache_valid的过期时间自然失效，最省心。要即时更新且改动的URL明确，装ngx_cache_purge模块（开源版）或用Nginx Plus的proxy_cache_purge，发个清除请求精确清掉那几个URL。要全站更新（比如换了模板），别rm -rf一把清，那会引发回源雪崩，应该配合proxy_cache_lock和use_stale，分批或趁低峰清。日常内容站，把有效期设短一点（几分钟）往往比折腾主动清更划算。

proxy_cache缓存的文件存在内存还是磁盘？会不会很占内存？

响应体（也就是真正的页面内容）存在磁盘上，由max_size控制总量；内存里只放key的元数据，由keys_zone的大小控制，1MB大约8000个key。所以它不会像Redis那样吃大量内存，主要吃的是磁盘空间和磁盘IO。如果你想榨干性能，可以把缓存目录挂在tmpfs（内存盘）上，读写快但重启就没了、且要严格控制大小别把内存撑爆，这是进阶玩法，一般机械盘换SSD放缓存就够用了。

上了Cloudflare这类CDN，源站还需要配proxy_cache吗？

需要，两层是叠加不是替代。CDN只缓存可公开缓存的内容，而且CDN有很多节点各自回源，源站这层proxy_cache能把这些回源请求再削一道；很多动态页面CDN默认不缓存，但源站用几十秒的微缓存就能挡掉大量重复回源，保护后端。注意两层用的是同一套缓存控制头，配的时候别让源站的no-store把CDN规则架空了，每层缓存多久要统一规划，这部分保哥在Cloudflare那篇里有专门的决策树。

权威参考资料