更多云服务器知识，尽在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: MISSMISS，意味着"未命中 "。这说明，保温台上没有这道菜，服务员（Nginx）亲自去后厨，麻烦大厨（后端应用）现做了一份。 - 间隔几秒钟，再次执行同样的命令：
X-Cache-Status: HITHIT！"命中 "！看到这个词，你就可以欢呼了！这说明，这一次，服务员直接从我们的"保温台"上，取了一份热气腾腾的缓存，递给了我们。整个过程，大厨全程在"带薪摸鱼"，服务器后端，几乎没有任何压力！
你的网站，从此快如闪电
现在，你的Nginx，已经完成了它最后的、也是最华丽的一次进化。
它不再仅仅是一个被动转发请求的"传菜员"，它成了一个拥有"智慧"和"记忆"的"首席配餐师"。它懂得如何智能地缓存结果，如何为你的"米其林大厨"（后端应用）扛下80%以上的重复劳动，如何将那些最受欢迎的"招牌菜品"，以闪电般的速度，满足你那些最没有耐心的"食客"（用户）。
去享受这份由智慧架构带来的宁静吧。你的服务器，从此将变得无比从容，而你的网站，在大多数用户眼中，将快得不像一个动态网站。