Nginx缓存：proxy_cache与purge清理

理解 proxy_cache：缓存机制与核心配置

Nginx 的 proxy_cache 机制本质上是一个基于磁盘的反向代理缓存系统。当客户端发起请求时，Nginx 会先根据 proxy_cache_key 计算缓存键，若命中则直接读取磁盘缓存文件返回，否则将请求转发至上游服务器，并将响应体按规则写入缓存目录。核心配置中，proxy_cache_path 定义缓存存储路径、目录层级及共享内存区大小（如 keys_zone=my_cache:10m）；proxy_cache 指定在哪个 location 启用该缓存区；proxy_cache_valid 控制不同 HTTP 状态码的缓存时长（如 200 302 10m）；proxy_cache_key 决定缓存的唯一标识，默认通常为 $scheme$proxy_host$request_uri。一套最小可用配置需在 http 块定义路径与 zone，在 server 或 location 块启用并设置有效时间，同时建议配合 proxy_cache_use_stale 提升上游宕机时的容错能力。

配置并验证缓存：从 MISS 到 HIT

配置完成后，需通过 nginx -t 检查语法并执行 nginx -s reload 平滑重载。验证缓存是否生效绝不能仅依赖页面加载速度，而应通过 HTTP 响应头或访问日志进行精确判断。使用 curl -I http://your-domain/path 发起请求，首次响应头中通常会出现 X-Cache-Status: MISS（或 BYPASS），表示未命中缓存且请求已回源。再次执行相同命令，若配置正确，响应头将变为 X-Cache-Status: HIT，且 Age 字段会显示缓存已存活的时间。为便于排查，可在 log_format 中添加 $upstream_cache_status 变量，通过 tail -f access.log 实时观察状态流转。若出现 EXPIRED 或 STALE，则说明缓存已过期或正在回源更新，需结合业务容忍度调整 proxy_cache_valid 参数。

purge 清理缓存：配置、执行与范围控制

需要明确的是，原生 Nginx 并未内置 purge 指令，实际生产中通常依赖第三方模块（如 ngx_cache_purge）或通过 Lua 脚本、OpenResty 生态实现缓存清理。以 ngx_cache_purge 为例，需在独立 location 块中配置 proxy_cache_purge 指令，并严格限制访问来源（如 allow 127.0.0.1; deny all;），防止恶意清空缓存。清理的核心在于精准匹配缓存键，执行 curl -X PURGE http://localhost/path 时，Nginx 会按当前 proxy_cache_key 规则计算目标路径对应的磁盘文件并删除。为避免误删，建议采用精确匹配优先策略，仅开放特定 URL 的清理接口，或结合业务标签实现按规则批量失效。切勿在生产环境直接开放通配符清理，否则极易引发缓存雪崩。

清理后验证与常见避坑

执行 purge 后，应立即发起一次新请求，观察日志中 $upstream_cache_status 是否由 HIT 转为 MISS，并确认响应头中 Age 字段归零，以此验证旧缓存已彻底失效且新缓存正在生成。常见避坑点包括：第一，缓存键不一致导致清理无效，例如 proxy_cache_key 包含 $http_host 而清理请求未携带相同 Host 头；第二，缓存目录权限不足（需确保 Nginx worker 进程对 proxy_cache_path 有读写权限），否则写入失败会静默降级为回源；第三，带查询参数的 URL 会被视为独立缓存键，清理时需完整传递参数或使用正则匹配；第四，修改缓存配置后必须重载 Nginx，否则新规则不生效。通过结合 error.log 中的 cache 级别日志与 strace 跟踪文件操作，可快速定位缓存未命中或清理失败的根因。