Nginx缓存指定URL配置方法详解

本文深入解析了在Linux环境下如何正确配置Nginx缓存指定URL的核心要点与实战陷阱：明确指出仅靠`expires`或`add_header`无法实现Nginx本地磁盘缓存，必须组合使用`proxy_cache`、`proxy_cache_path`和`proxy_cache_valid`，并确保`proxy_pass`存在且指向反向代理后端；同时详解了常见失效原因（如`proxy_cache_path`位置错误、zone名不匹配、响应头限制等）、精准路径缓存技巧（借助正则location与定制`proxy_cache_key`去参防碎片化）、安全清理策略（避免暴力删除，推荐hash定位+reload触发扫描），并强调真实生效需通过`X-Cache`响应头与`$upstream_cache_status`日志字段交叉验证——帮你避开“看似缓存、实则回源”的典型误区。

直接说结论：想缓存指定 URL，必须用 proxy_cache + proxy_cache_path + proxy_cache_valid 这套组合，且 proxy_pass 必须存在；仅靠 expires 或 add_header 只影响浏览器，不缓存到 Nginx 本地磁盘。

为什么 proxy_cache 不生效？常见配置陷阱

很多人配完 proxy_cache my_cache 却发现 /var/cache/nginx 下没文件、curl -I 也看不到 X-Cache: HIT —— 根本原因通常是以下几点之一：

• proxy_cache_path 没写在 http 块顶层，而是错放在 server 或 location 里（Nginx 会静默忽略）
• proxy_cache 后面的 zone 名和 proxy_cache_path 的 keys_zone 名不一致（比如写成 mycache vs my_cache）
• 没配 proxy_pass，或 proxy_pass 指向的是本地 root 或 alias（proxy_cache 只对反向代理生效，不缓存静态文件直出）
• 后端响应头含 Cache-Control: no-cache、Set-Cookie 或状态码非 200/301/302（默认只缓存这些），而你没用 proxy_ignore_headers 覆盖

如何精准缓存某几个 URL 路径？location + proxy_cache_key 是关键

想只缓存 /api/v1/user 和 /status，但跳过其他路径，不能只靠 location = /api/v1/user —— 因为默认 proxy_cache_key 包含 $scheme$request_method$host$request_uri，而 GET /api/v1/user?ts=123 和 ?ts=456 会被当成两个 key，导致缓存碎片化。

实操建议：

• 用 location ~ ^/(api/v1/user|status)$ 精确匹配路径（注意结尾 $，避免匹配到 /api/v1/user/profile）
• 显式重写 proxy_cache_key，去掉查询参数干扰：proxy_cache_key "$scheme$request_method$host$uri";（$uri 不带 $args）
• 若需区分登录态，可加入 header：proxy_cache_key "$scheme$request_method$host$uri$cookie_sessionid";
• 加 proxy_cache_lock on; 防止缓存穿透时多个并发请求同时打到后端

缓存清理：没有 purge 模块时怎么安全删指定 URL？

Nginx 官方不带缓存清理接口。如果没编译 ngx_http_proxy_cache_purge 模块，别直接 rm -rf /var/cache/nginx/* —— 这会清空全部缓存，且可能删到正在写的临时文件，导致 502。

更稳妥的做法：

• 用 proxy_cache_path 的 inactive=10m 参数，让未被访问的缓存自动过期（适合低频更新场景）
• 按 URL 计算 cache key hash，进对应目录手动删：echo -n "http://example.com/api/v1/user" | md5sum → 得到 681ad4c77694b65d61c9985553a2763f → 对应路径是 /var/cache/nginx/f/63/681ad4c77694b65d61c9985553a2763f（levels=1:2 时）
• 删完执行 sudo nginx -s reload 触发 cache manager 重新扫描（不是必须，但保险）

真正难的不是配出缓存，而是确认它在什么条件下失效、是否真的复用、有没有意外缓存敏感数据——这些得靠 curl -I 看 X-Cache、Cache-Control，再结合日志里的 $upstream_cache_status 字段交叉验证。漏掉其中一环，就容易以为缓存生效了，其实每次都在回源。

今天关于《Nginx缓存指定URL配置方法详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于Linux的内容请关注golang学习网公众号！