Nginx可通过proxy_cache_purge模块实现按需精准缓存清理，需编译启用该模块、配置purge location并严格限制IP访问，结合业务语义（如标签、路径前缀）设计清理策略，再通过管理API联动调用。
Nginx 本身不提供 HTTP 接口来清理缓存，但通过合理组合配置与扩展模块，完全可以构建出「缓存自动生效 + 按需精准清理」的 API 联动服务。核心思路是：用 Nginx 原生 proxy_cache 实现高性能缓存，再借助 proxy_cache_purge 模块暴露清理端点，最后用简单规则绑定业务语义（如按资源 ID、路径前缀或标签）。
启用 proxy_cache_purge 模块
该模块非 Nginx 默认内置，需确认已编译安装（主流发行版包通常含此模块；若源码编译，需加 `--with-http_proxy_cache_purge_module`）。验证方式：nginx -V 2>&1 | grep -o with-http_proxy_cache_purge_module
若无输出，需重装或升级 Nginx（1.5.7+ 支持）。定义带 purge 能力的缓存区域
在 http 块中声明缓存路径时，无需额外参数，但 location 中需显式启用 purge：proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:100m inactive=10m max_size=5g use_temp_path=off;
server {
listen 80;
server_name api.example.com;
# 允许 PURGE 方法访问特定路径
location ~ ^/purge(/.*)$ {
allow 127.0.0.1;
allow 10.0.0.0/8;
deny all;
proxy_cache_purge api_cache "$host$1$is_args$args";
}
location /api/ {
proxy_cache api_cache;
proxy_cache_key "$host$request_uri";
proxy_cache_valid 200 5m;
proxy_ignore_headers Cache-Control Expires;
proxy_pass http://backend;
}
}
- /purge/xxx 路径将触发清除对应 $host$1$is_args$args 的缓存项（即把请求 URI 映射为 cache key）
- allow/deny 严格限制 purge 来源 IP，避免被恶意调用
- purge 不影响正在使用的缓存文件，仅标记为“待删”，下次 inactive 清理或磁盘满时回收
按业务维度设计清理策略
单纯按 URI 清理易遗漏或误删。推荐结合上游返回头或请求参数增强语义：- 后端在响应中注入自定义头：X-Cache-Tag: product-123,user-profile
- Nginx 用 map 指令提取 tag，并写入 cache key 或独立存储（需配合 Lua 或 OpenResty）
- 更轻量做法：约定清理路径语义，例如
→ PURGE /purge/tag/product-123 → 清除所有含product-123的 key（需 Lua 脚本遍历匹配）
→ PURGE /purge/path/api/v1/users/ → 清除该前缀下全部缓存（利用 $1 正则捕获）
API 层联动建议
真实业务中，不应让前端或运营直接调用 PURGE。应封装一层管理 API：- 接收业务事件（如“商品ID 123 已更新”），生成对应 purge 请求发往 Nginx
- 记录 purge 日志，含时间、操作人、目标路径、是否成功
- 支持批量清理（如发布新版本时清空整个 /api/v2/ 下缓存）
- 配合健康检查：PURGE 后可立即 GET 验证是否已失效
curl -X PURGE http://api.example.com/purge/api/product/123 -i
响应头中 X-Cache-Status: BYPASS 或 204 No Content 表示成功。不复杂但容易忽略
