要实现nginx反向代理缓存的精准purge，核心依赖第三方静态编译模块ngx_cache_purge，其关键在于proxy_cache_key与purge key严格一致、访问控制严密、且必须通过源码编译集成，不可动态加载。
要实现 Nginx 反向代理缓存的精准 Purge，核心不是“删缓存”，而是“按需命中并删除指定条目”——这必须依赖第三方模块 ngx_cache_purge。它不改变 Nginx 原有缓存逻辑，而是在 proxy_cache 基础上增加一个可寻址、可触发的清除入口。
模块必须静态编译，不能动态加载
ngx_cache_purge 不在官方 Nginx 发行版中，也不支持 .so 动态模块方式加载。安装必须在编译阶段完成：
- 从 GitHub 获取稳定分支（如 release/v2.5+）：
git clone --depth 1 https://github.com/FRiCKLE/ngx_cache_purge.git - 进入 Nginx 源码目录，执行 configure 时加入：
--add-module=/path/to/ngx_cache_purge - 运行
make && sudo make install，完成后用nginx -V 2>&1 | grep cache_purge验证输出是否存在
缓存 key 和 purge key 必须完全一致
这是精准清理成败的关键。Nginx 内部通过共享内存中的红黑树匹配 key，哪怕一个字符或编码差异（如 %20 vs 空格）都会导致 404。
- 推荐统一使用：
proxy_cache_key "$scheme$request_method$host$request_uri"; - 对应 purge location 中的 key 要严格复现，例如：
proxy_cache_purge my_cache "$scheme$request_method$host$1";（其中$1来自正则捕获，代表目标路径） - 若业务需忽略参数清理，可用
rewrite归一化 URI，或用map构建标准化 key，避免$args引入不确定性
暴露 purge 接口必须加访问控制
/purge 路径本质是高危操作端点，绝不能开放给公网或任意 IP：
- 用
allow/deny限定可信网段，例如：allow 10.10.5.0/24;、allow 127.0.0.1; - 生产环境建议叠加请求头校验，如
X-Purge-Token，配合map指令做 token 白名单比对 - 添加限速保护：
limit_req zone=purge_limit burst=2 nodelay;，防探测与误刷 - location 建议独立且路径收敛，例如：
location ~ ^/purge(/.*)$ { ... }
触发与验证：别只看状态码
PURGE 请求返回 200，只表示“Nginx 尝试执行了清除动作”，不代表缓存一定被删掉：
- 测试命令示例：
curl -X PURGE http://example.com/purge/api/user/123 - 真正生效要看后续请求响应头：
X-Cache-Status: MISS或Age: 0 - 注意浏览器或中间代理缓存干扰，建议用
curl -H "Cache-Control: no-cache"直连测试 - 必要时可手动检查缓存目录（如
/var/cache/nginx/my_cache）是否存在对应 hash 文件
