应使用ngx_cache_purge模块发起PURGE请求精准清理，因其依据proxy_cache_key自动匹配删除，避免手动删文件出错；需确认模块已编译、purge配置与cache_key严格一致，并用curl -X PURGE验证返回200。
要清理 Nginx proxy_cache 中指定 URL 的物理缓存文件，不能靠“猜路径”或手动遍历查找，因为缓存文件名是基于 proxy_cache_key 计算出的 MD5 值，且按哈希散列到多级子目录中（如 /data/nginx/cache/0/32/ab3f）。直接删文件既不可靠也易出错。真正可行、生产推荐的方式是**精准触发失效**，而非手动定位物理文件。
用 ngx_cache_purge 模块发起 PURGE 请求
这是最标准、最安全、线上环境首选的方法。它不依赖路径猜测，而是由 Nginx 内部根据当前配置的 proxy_cache_key 规则，自动匹配并删除对应缓存实体。
- 确认模块已启用：运行
nginx -V 2>&1 | grep -o ngx_cache_purge，有输出才表示已编译支持 - 在 server 或 location 块中添加 purge 配置，key 必须与 proxy_cache_key 完全一致，例如：
allow 192.168.10.0/24;
deny all;
proxy_cache_purge my_cache $scheme$host$1$is_args$args;
}
注意：$scheme$host$is_args$args 要和你实际的 proxy_cache_key（比如 "$scheme$request_method$host$request_uri"）逻辑等价；漏掉 $is_args$args 就会导致带参数的 URL 清不掉。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 执行清理命令：
curl -X PURGE "https://example.com/api/user?id=123" - 返回
200表示命中并删除成功，404表示未缓存或 key 不匹配
手动计算并删除（仅限调试或离线场景）
不推荐用于生产，但有助于理解机制或做事后验证。步骤如下：
- 从配置中提取完整的
proxy_cache_key字符串，例如："$scheme$request_method$host$request_uri" - 构造该 URL 对应的原始请求信息：假设请求是
GET https://api.example.com/v1/data?x=1，则拼出："httpsGETapi.example.com/v1/data?x=1" - 对该字符串做 MD5（小写）：
echo -n "httpsGETapi.example.com/v1/data?x=1" | md5sum | cut -d' ' -f1→ 得到类似ab3f7e8c2a1b... - 按
levels=1:2规则拆分哈希值：取最后 1 位 + 倒数第 2–3 位 →ab3f7e8c2a1b...→ 目录为/ab3f7e8c2a1b.../f/7e/ab3f7e8c2a1b...（具体取决于 levels 设置） - 进入对应缓存根目录（如
/var/cache/nginx），定位并rm该文件
为什么不该直接删整个缓存目录
虽然 sudo rm -rf /var/cache/nginx/* 看似简单，但它会清空所有缓存条目，导致：
- 缓存命中率瞬间归零，后端服务在接下来几分钟内承受突发流量冲击
- 无法区分哪些 URL 已更新、哪些仍应保留，属于“杀鸡用牛刀”
- 若使用了共享内存 zone（keys_zone），删文件后 Nginx 仍可能因内存索引未同步而短暂返回 stale 内容
补充：清理后如何验证是否生效
不要只看响应头 X-Proxy-Cache，要结合行为判断：
- 首次访问目标 URL 后，响应头中
X-Proxy-Cache: MISS→ 表明缓存未命中，说明旧缓存已失效 - 再次访问同一 URL，出现
HIT→ 新缓存已建立，说明 purge 成功且配置无误 - 对比前后端日志：PURGE 后，后端应收到新请求（若之前是 HIT）
