HTTP PURGE是专为Nginx反向代理缓存设计的精准失效机制，需通过ngx_cache_purge模块启用，配置受控location限制IP、确保proxy_cache_key与PURGE路径严格一致，并依据200/204、404、405等状态码验证结果。
HTTP PURGE 是一种专为反向代理缓存（如 Nginx 的 proxy_cache 或 fastcgi_cache）设计的精准失效机制，它不是清空整个缓存目录，而是按 URI 主动删除指定缓存条目，响应快、影响小、可审计。要安全使用 PURGE，关键在于权限控制、路径匹配和缓存键一致性。
确保 Nginx 已支持 cache_purge 模块
PURGE 方法本身不是 Nginx 原生支持的，必须通过第三方模块 ngx_cache_purge 启用：
- 检查是否已编译该模块：运行
nginx -V 2>&1 | grep -o 'cache_purge'，有输出才表示可用 - 若无输出，需重新编译 Nginx 并添加
--add-module=/path/to/ngx_cache_purge；Nginx 1.9.11+ 也支持动态加载 - 仅配置
location ~ /purge而未启用模块，会导致 405 Method Not Allowed 错误
配置受控的 PURGE 路由与访问限制
不能开放任意 IP 发起 PURGE 请求，否则存在被恶意清空全站缓存的风险：
- 在
server块中定义专用 location，例如：location ~ ^/purge(/.*)$ {allow 127.0.0.1;allow 192.168.10.5;deny all;proxy_cache_purge mycache $1;} -
$1必须与proxy_cache_key中使用的变量严格一致（如proxy_cache_key $scheme$host$request_uri，则 PURGE 路径需完整匹配$request_uri） - 若缓存键含查询参数（
$args），PURGE 请求也必须带相同参数，例如：curl -X PURGE "https://example.com/api/data?user=123"
执行 PURGE 并验证结果
发送请求后，通过响应状态码判断操作是否成功：
- 200 OK 或 204 No Content：缓存项已成功移除（即使原缓存不存在，也可能返回 200）
- 404 Not Found：该 URI 当前无对应缓存条目（属正常情况）
-
405 Method Not Allowed：location 未匹配到，或 HTTP 方法未在
limit_except中显式允许（需确认配置中未禁用 PURGE） - 验证是否生效：用
curl -I https://example.com/target-page查看响应头中是否仍含X-Cache: HIT；若变为MISS或缺失，说明已失效
不推荐的“伪安全”做法
以下方式看似方便，实则存在隐患，应避免：
- 将
allow all或开放公网 IP 段用于 PURGE 接口 - 用定时脚本无差别调用
/purge/清空全部缓存（等同于暴力删盘，失去精准性） - 未校验
proxy_cache_key与 PURGE 路径逻辑是否对齐，导致“以为清了，其实没清” - 在 HTTPS 站点下用 HTTP 协议发起 PURGE（如
curl -X PURGE http://...），可能因协议不一致导致匹配失败
