要用 proxy_cache_purge 实现特定 url 缓存的手动清理，核心是让 purge 请求生成的缓存 key 与原始缓存 key 完全一致，从而在内存索引中精准定位并失效对应条目；需确认模块已编译启用、显式定义 proxy_cache_key、严格对齐变量与参数、配置安全访问控制，并通过三重验证确认清理生效。
要用 proxy_cache_purge 实现特定 URL 缓存的手动清理，核心不是“删文件”，而是让 purge 请求生成的缓存 key 和原始缓存 key 完全一致，从而在内存索引中精准定位并失效对应条目。
确认模块已编译启用
该模块非 Nginx 原生功能，必须静态编译进二进制文件。执行：
nginx -V 2>&1 | grep -o 'cache_purge'
若无输出，说明未启用。解决方式包括：
- 改用 OpenResty（默认集成）
- 从源码重新编译，添加
--add-module=/path/to/ngx_http_proxy_cache_purge - 注意模块版本需与当前 Nginx 版本兼容（如 v2.5+）
保证 cache key 严格对齐
purge 能否命中，90% 取决于 key 是否一字不差。不能依赖默认值，必须显式定义：
proxy_cache_key "$scheme$request_method$host$request_uri";
对应 purge location 中的 key 必须复用相同变量组合：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
location ~ ^/purge(/.*)$ {<br> proxy_cache_purge my_cache "$scheme$request_method$host$1";<br>}
关键细节：
-
$request_uri包含参数和大小写，$uri不含参数，务必用前者 - GET 参数顺序、编码、大小写必须完全一致（
?a=1&b=2≠?b=2&a=1） - 若原始 key 含
$args，purge 中也得补上$is_args$args
配置安全的 purge 接口
/purge 是高危路径，绝不能开放给公网。典型配置示例：
location ~ ^/purge(/.*)$ {<br> allow 127.0.0.1;<br> allow 10.10.0.0/16; # 运维内网段<br> deny all;<br> proxy_cache_purge my_cache "$scheme$request_method$host$1$is_args$args";<br>}
增强防护建议：
- 路径避免用通用名，改用带随机串的路径（如
/purge-7f2a9e） - 叠加 Basic Auth：
auth_basic "Purge Access"; auth_basic_user_file /etc/nginx/purge_users; - 禁止通过 POST/GET 触发，只响应大写的 PURGE 方法
验证清理是否真实生效
别只看 HTTP 状态码，要三重验证：
- 首次访问目标 URL：响应头含
X-Cache: MISS - 二次访问：变为
X-Cache: HIT（确认缓存已建立） - 执行
curl -X PURGE http://example.com/purge/path后再访问：应再次出现MISS - 检查
proxy_cache_path对应目录下，该 key 的 hash 文件是否被移出索引（物理文件暂留，由 inactive 机制后续回收）
返回码含义：
-
200：purge 操作成功（无论原缓存是否存在） -
404：当前无该 key 的缓存（不是错误，是正常情况） -
405：方法不被允许（检查是否用了 GET 或未在location中允许 PURGE）
