Nginx缓存配置指南：使用proxy_cache为动态网站提速10倍

更多云服务器知识，尽在hostol.com

你可能已经知道，Nginx是一位出色的“交通指挥官”（负载均衡）和一位彬彬有礼的“前台接待员”（反向代理）。但今天，我要告诉你，在它朴实的外表下，还隐藏着一个能让你的动态网站性能“原地起飞”、轻松应对数倍流量冲击的终极超能力。

这项能力，就是缓存 (Caching)。它，是Nginx从一个“管理员”，晋升为“性能魔术师”的关键。准备好，我们将一起学习这套能为你服务器大幅减负、为用户体验注入“涡轮增压”的“魔法”。

---

Nginx进阶：轻松掌握Nginx缓存配置，为你的动态网站提速10倍

你的动态网站（比如WordPress博客、PHP论坛、或任何需要连接数据库的应用），是不是有这样一个“幸福的烦恼”？

当一篇文章突然火了，或者你在社区里发布了一个热门话题，海量的用户瞬间涌入。你眼看着服务器的CPU占用率，从10%一路飙升到90%，内存也开始告急。网站的响应速度，从丝般顺滑，变得像在泥潭中行走。

这是为什么？

我们用一个“高级餐厅”的厨房来打比喻，你立刻就能明白。

• 你的后端应用 (PHP, Python, 数据库等): 就是那位厨艺精湛、但一次只能炒一道菜的“米其林大厨”。
• 每一个用户访问： 就是一张全新的“点菜单”。

在没有缓存的情况下，你的餐厅是严格按照“现点现做”的模式运营的。 第一个客人点了“鱼香肉丝”，大厨立刻去切肉、备料、开火、爆炒，5分钟后，一道热气腾腾的菜出锅了。 第二个客人，也点了“鱼香肉丝”。我们的大厨，叹了口气，再次从头开始，切肉、备料、开火、爆炒…… 如果一瞬间来了100个客人都点了“鱼香肉丝”，你可以想象，我们的大厨会立刻累瘫在灶台前，整个厨房都会陷入瘫痪。

这，就是你动态网站的性能瓶颈。对于一篇热门文章，每一个访客的访问，都在强迫你的服务器去重复地、毫无意义地，执行一遍“连接数据库 -> 查询数据 -> 渲染模板 -> 生成HTML”的完整流程。

那么，聪明的餐厅经理（你）会怎么做？你会在出餐口，设置一个“保温配餐台”！

Nginx缓存，就是这个“保温配餐台”！

它的工作逻辑是：当第一个客人的“鱼香肉丝”做出来后，服务员（Nginx）除了把菜端给客人，还会悄悄地，把一份一模一样的、热气腾腾的菜，放在这个“保温台”上。 在接下来的5分钟内，任何再点“鱼香肉丝”的客人，服务员会直接从保温台上，把菜端走。整个过程，快如闪电，而且，完全没有打扰到我们正在休息的大厨！

这，就是Nginx缓存的魔力。它将动态请求的结果，暂时“静态化”，用Nginx那处理静态文件时无与伦比的超高性能，来直接响应用户，从而极大地降低后端服务器的压力，提升网站的响应速度。这个“10倍”提速，绝非夸张。

第一步：建造你的“保温配餐台” —— proxy_cache_path

好了，理论讲完，我们开始动手“装修厨房”。首先，我们要定义我们这个“保温台”放在哪里，它有多大，以及它的管理规则。

这个定义，必须写在Nginx配置文件的**http块**内，server块之外。

Nginx

http {# ... 其他http配置 ...proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;server {# ... 你的server配置 ...}
}

我们来解剖一下这行“装修指令”：

• proxy_cache_path /var/cache/nginx： 告诉Nginx，我们把“保温台”建在服务器的/var/cache/nginx这个目录下。请确保Nginx对这个目录有读写权限。
• levels=1:2： 这是缓存目录的结构。你可以把它理解为在保温台上，设置了“A区01号”这样的两级货架，方便服务员快速找到菜品。
• keys_zone=my_cache:10m： 这是最核心的配置！它就像是给你的配餐台，配备了一个大小为10MB的“大脑”（一块共享内存）。这个大脑，不存放菜品本身，只存放所有菜品的“索引”，也就是“哪个菜（缓存key）放在了哪个货架上（缓存文件路径）”。my_cache是你给这个大脑起的名字，后面会用到。
• max_size=10g： 这是你的“保温台”物理上的总容量。这里我们设置为10GB。当缓存文件超过这个大小时，Nginx会自动清理那些“最冷”的菜品。
• inactive=60m： 如果保温台上的某道菜，在60分钟内，一次都没有被客人点过，那它就说明它“不新鲜了”，服务员会自动把它撤走，腾出空间。
• use_temp_path=off： 一个性能优化选项，建议开启。

第二步：给每一道“菜品”贴上“标签” —— proxy_cache_key

Nginx怎么知道，用户A请求的首页，和用户B请求的首页，是同一道“菜”呢？它需要一个“标签”系统。

Nginx

http {# ... proxy_cache_path 配置 ...proxy_cache_key "$scheme$request_method$host$request_uri";server {# ...}
}

这行配置，定义了缓存的“钥匙”(key)。它把“协议(http/https) + 请求方法(GET/POST) + 域名 + 请求URI”这几个变量组合起来，作为每一道菜独一无二的“身份证”。通常，我们保持这个默认值即可。

第三步：开启“保温”功能，并设置“保鲜期”

现在，“保温台”已经建好，我们需要在“出餐口”（你的server或location块）正式启用它。

打开你网站的反向代理配置文件，在location块里，加入以下几行“魔法指令”：

Nginx

server {listen 80;server_name yourdomain.com;location / {# --- 缓存核心配置 Start ---# 1. 启用哪个“保温台”？proxy_cache my_cache; # my_cache就是我们刚才在keys_zone里起的名字# 2. 设置“保鲜期”proxy_cache_valid 200 302 10m; # 对状态码为200和302的成功响应，缓存10分钟proxy_cache_valid 404 1m;      # 对404页面，只缓存1分钟# --- 缓存核心配置 End ---proxy_pass http://your_backend_app;# ... 其他proxy配置 ...}
}

• proxy_cache my_cache;：告诉Nginx，对这个location下的所有请求，启用名为my_cache的那个“保温台”。
• proxy_cache_valid 200 10m;：这是在设定“保鲜规则”。它告诉服务员：“所有由大厨做出来的、成功的菜品（状态码200），都可以在保温台上放10分钟。10分钟后，这份缓存就‘过期’了，需要让大厨重新做一份。”

第四步：像“专家”一样，配置“高级规则”

有些地方，我们不希望被缓存。比如，WordPress的后台管理页面 /wp-admin，或者用户登录后的个人中心。这些页面是“千人千面”的，绝不能把A用户的个人中心，缓存起来发给B用户！

Nginx

location / {# ... 其他缓存配置 ...# --- 缓存高级规则 ---# 如果是POST请求，或者URL里带了查询参数，就不缓存if ($request_method = POST) {set $skip_cache 1;}if ($query_string != "") {set $skip_cache 1;}# 对于包含特定Cookie或路径的请求，不缓存if ($request_uri ~* "/wp-admin/|/xmlrpc.php|/wp-login.php") {set $skip_cache 1;}if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {set $skip_cache 1;}# 定义是否跳过缓存proxy_no_cache $skip_cache;proxy_cache_bypass $skip_cache;# 在响应头里，加上一个“小彩蛋”，方便我们调试add_header X-Cache-Status $upstream_cache_status;proxy_pass http://your_backend_app;# ...
}

这段配置，就是我们“工作手册”里的“特殊条款”。它通过变量$skip_cache，精准地告诉Nginx，在遇到什么情况下，应该“绕过保温台，永远都去找大厨现做”。

最后那句add_header X-Cache-Status $upstream_cache_status;，是我们留下的一个“秘密暗号”，它能让我们清楚地知道，我们收到的这份“菜”，到底是“现做的”，还是从“保温台”拿的。

最终检验：你的“保温台”，上岗了吗？

保存所有配置，重新加载Nginx：sudo nginx -t && sudo systemctl reload nginx。

现在，是时候检验我们的“魔术”了。打开你的命令行终端，使用curl命令，像一个访客一样，连续两次请求你的网站首页：

Bash

curl -I https://yourdomain.com

• 第一次请求，你会看到这样的响应头： X-Cache-Status: MISS MISS，意味着“未命中”。这说明，保温台上没有这道菜，服务员（Nginx）亲自去后厨，麻烦大厨（后端应用）现做了一份。
• 间隔几秒钟，再次执行同样的命令： X-Cache-Status: HIT HIT！“命中”！看到这个词，你就可以欢呼了！这说明，这一次，服务员直接从我们的“保温台”上，取了一份热气腾腾的缓存，递给了我们。整个过程，大厨全程在“带薪摸鱼”，服务器后端，几乎没有任何压力！

你的网站，从此快如闪电

现在，你的Nginx，已经完成了它最后的、也是最华丽的一次进化。

它不再仅仅是一个被动转发请求的“传菜员”，它成了一个拥有“智慧”和“记忆”的“首席配餐师”。它懂得如何智能地缓存结果，如何为你的“米其林大厨”（后端应用）扛下80%以上的重复劳动，如何将那些最受欢迎的“招牌菜品”，以闪电般的速度，满足你那些最没有耐心的“食客”（用户）。

去享受这份由智慧架构带来的宁静吧。你的服务器，从此将变得无比从容，而你的网站，在大多数用户眼中，将快得不像一个动态网站。