必须使用 ngx_cache_purge 模块实现精准清理，该模块需静态编译进 Nginx，且 purge 请求的 key 必须与原始缓存 key（如 "$scheme$request_method$host$request_uri"）完全一致，并严格限制访问权限以防止缓存雪崩。

要实现在生产环境对特定 URL 的手动缓存清理，核心是让 Nginx 具备“按需精准删除”能力——而原生 proxy_cache 不支持该操作，必须依赖 ngx_cache_purge 模块。它通过复用相同的缓存 key 逻辑，在内存索引中定位并移除对应条目，不碰磁盘文件，安全高效。

模块必须静态编译集成

ngx_cache_purge 不支持动态加载，必须在构建 Nginx 时加入：
– 下载与当前 Nginx 版本兼容的 release（如 v2.5+），避免运行时崩溃
– configure 命令中显式添加：--add-module=/path/to/ngx_cache_purge
– 编译安装后执行 nginx -V | grep cache_purge，确认输出含该字符串
– 若已上线 Nginx，需备份原二进制文件，用新编译的 objs/nginx 替换，再 reload

缓存 key 必须严格对齐

purge 能否命中，取决于 purge 请求生成的 key 是否与原始缓存 key 完全一致。常见配置示例：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 原始缓存 key 配置：proxy_cache_key "$scheme$request_method$host$request_uri";
• 对应 purge location：location ~ ^/purge(/.*)$ { proxy_cache_purge my_cache "$scheme$request_method$host$1"; }
• 若原始 key 包含参数（如 $args），purge 时也必须带相同参数，否则无法匹配
• 建议统一使用 $request_uri（含参数）而非 $uri（不含参数），减少遗漏

清理接口必须做访问控制

/purge 接口一旦暴露，可能被恶意扫描或批量调用，导致缓存雪崩。务必限制来源：

• 只允许运维跳板机、CI/CD 发布节点、内部监控系统 IP 段访问
• 配置示例：allow 10.10.0.0/16; allow 127.0.0.1; deny all;
• 高敏感环境可叠加 Basic Auth：auth_basic "Purge Access"; auth_basic_user_file /etc/nginx/purge_users;
• 避免将 purge 路径设为 /purge 这类通用名，改用带随机串的路径（如 /purge-8a3f2e）提升隐蔽性

触发清理的操作方式

清理动作本质是一次 HTTP PURGE 请求，不是 GET 或 POST：

• 清除首页：curl -X PURGE http://example.com/purge/
• 清除带参接口：curl -X PURGE "http://example.com/purge/api/v1/product?id=1001"
• 返回码含义明确：200 表示 purge 成功（无论原缓存是否存在），404 表示未命中，405 表示方法不被允许（检查是否误用 POST）
• 可集成到发布脚本中，例如 Jenkins 执行完部署后自动触发对应 URI 的 purge