proxy_cache_purge仅支持按完全匹配的key精准秒级删除缓存元数据，不清理磁盘文件；成功前提为purge key与原始cache_key严格一致，需显式定义并复用相同变量组合，且必须限制访问权限、验证响应头与日志。
Nginx 本身不支持自动清理“已过期”的缓存，proxy_cache_purge 模块也不是用来扫过期文件的定时工具，它只做一件事：按指定 key 精准、秒级、主动删除某条缓存条目。真正让缓存过期的是 proxy_cache_valid 和 inactive 机制，而 purge 是你在发布、修复、灰度时手动“点名清除”的高效手段。
高效精准的前提是 key 完全对齐
purge 能否成功，90% 取决于你构造的 purge key 是否和原始缓存 key 一字不差。
Nginx 不会智能匹配 URL，它只比对哈希值。如果 key 对不上，请求返回 200（看似成功），实际什么都没删。
- 原始缓存 key 必须显式定义，别依赖默认值
proxy_cache_key "$scheme$request_method$host$request_uri";
- purge location 中的 key 必须复用相同变量组合
location ~ ^/purge(/.*)$ { proxy_cache_purge my_cache "$scheme$request_method$host$1"; } -
$request_uri包含参数（如/api/user?id=123），$uri不包含，务必用前者 - 若后端区分大小写或重写了 URI，purge 也得走同样路径，否则 key 失配
秒级生效靠的是内存索引操作，不是删文件
proxy_cache_purge 删除的是共享内存中该 key 对应的缓存元数据（metadata），不是直接 rm 文件。
磁盘上的缓存文件会在后续由 Nginx 的 cache manager 进程按 inactive 或 max_size 规则异步回收。
所以 purge 后：
- 下次请求立即回源（
MISS），不再命中旧缓存 -
X-Cache-Status响应头立刻变为MISS或BYPASS - 整个过程在毫秒级完成，无 IO 阻塞
安全可控的清理入口必须严格限制
/purge 接口一旦暴露，可能被扫描、误点、甚至恶意批量调用，引发缓存雪崩。
- 只允许最小必要 IP 段访问，例如：
allow 10.10.5.0/24; # CI/CD 发布节点 allow 127.0.0.1; # 本地运维脚本 deny all;
- 生产环境建议加一层 Basic Auth：
auth_basic "Cache Purge Only"; auth_basic_user_file /etc/nginx/.purge_htpasswd;
- 路径别用通用名，改用带随机后缀的隐蔽路径，比如
/purge-7f2a9e，降低被撞库风险
清理操作要可验证、可集成、可回溯
每次 purge 后不能只看 200 就认为成功，要三重确认：
-
状态码判断：
CPA Update - Secure CLI Proxy API Maintenance下载安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
200：key 已从缓存索引中移除（无论原缓存是否存在） -
404：该 key 当前无缓存（正常，说明已过期或未被缓存过） -
405：请求方法错误（检查是否用了GET而非PURGE）
-
-
响应头验证：
在被缓存的 location 中加：add_header X-Cache-Status $upstream_cache_status;
purge 后发起一次
GET请求，确认响应头为X-Cache-Status: MISS -
日志留痕：
在 purge location 中记录访问：access_log /var/log/nginx/purge.log main;
-
CI/CD 自动集成示例（Jenkins 或 GitHub Actions）：
curl -X PURGE -u admin:pass "https://cdn.example.com/purge-7f2a9e/static/v2.3.1/app.js"
不复杂但容易忽略
