proxy_cache_purge需模块加载、缓存键一致、location精准配置及访问控制，集群下还需加入节点标识确保清理准确。
要让 proxy_cache_purge 真正发挥作用，不能只装模块、加 location 就完事。它本质是一个“触发式手动清理入口”，必须和缓存键设计、缓存区域定义、访问控制三者严丝合缝，否则 purge 请求发出去，什么也没删掉。
确认 purge 模块已加载且可用
官方 Nginx 不自带 proxy_cache_purge，必须通过第三方模块（如 FRiCKLE 的 ngx_cache_purge）编译启用。验证方式很简单：
- 运行
nginx -V 2>&1 | grep -o cache_purge，有输出说明模块已加载 - 若无输出，需重新编译 Nginx 并带上
--add-module=/path/to/ngx_cache_purge - 注意：模块版本需与 Nginx 主版本兼容（例如 Nginx 1.24+ 推荐用 ngx_cache_purge 2.5+）
缓存键（cache key）必须完全一致
purge 能否命中，取决于你发 purge 请求时构造的 key，和实际缓存时生成的 key 是否一字不差。常见失效原因就是 key 不匹配：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存时用的是
proxy_cache_key "$scheme$request_method$host$uri$is_args$args" - purge 时就必须用完全相同的字符串，比如
proxy_cache_purge my_cache "$scheme$request_method$host$uri$is_args$args" - 特别注意：
$request_uri包含原始 query string（含编码），而$uri$is_args$args更规范；$host和$http_host也可能因 header 差异导致不一致 - 推荐统一使用：
"$scheme$request_method$host$uri$is_args$args"—— 它覆盖协议、方法、域名、路径、参数，可复现、无歧义
purge location 需严格限制并精准捕获路径
不是所有请求都能触发 purge，必须定义专用 location，并确保其 key 构造逻辑与缓存 location 对齐：
- 用正则捕获路径，例如
location ~ ^/purge(/.*)$，然后在 purge 指令中引用$1 - key 中要拼接完整请求要素，例如：
proxy_cache_purge my_cache "$scheme$request_method$host$1$is_args$args" - 务必设置访问控制：
allow 127.0.0.1;+allow 192.168.10.0/24;+deny all;，避免被恶意调用 - 不要把 purge 路径暴露在公网或未鉴权接口中
多节点负载均衡下要带后端标识
在集群环境中，多个 Nginx 实例共用同一套缓存策略但各自独立存储，如果 purge 请求发到 A 节点，却想删 B 节点的缓存，那肯定失败。解决方案是让缓存 key 具备“节点上下文”：
- 在
proxy_cache_key中加入$upstream_addr或$server_addr，例如："$scheme$request_method$host$uri$is_args$args|$upstream_addr" - 这样每个节点缓存的 key 都不同，purge 也只会作用于本机缓存，避免误删或漏删
- 若需全局清理，应由运维系统逐台调用各节点的 purge 接口，或借助配置中心同步触发
