proxy_cache_purge不支持动态清理，仅响应明确PURGE请求并按完全匹配的缓存key精准删除元数据；需静态编译ngx_cache_purge模块，清理动作依赖严格一致的key构造，删除的是共享内存中的元数据而非磁盘文件，生产环境必须配置IP白名单、鉴权和路径混淆等访问控制。
proxy_cache_purge 不支持动态清理——它本身没有“动态”能力，只响应明确的 PURGE 请求，按完全匹配的缓存 key 精准删除元数据。所谓“动态”，实际是指在业务变化时（如内容更新、发布上线、灰度切换）由外部系统（CI/CD、CMS、API）自动触发 PURGE 请求，而非 Nginx 自动扫描或识别状态变化。
必须静态编译，无法动态加载
ngx_cache_purge 是第三方模块，Nginx 官方主线版本不包含该功能。它不支持 .so 动态模块方式加载，只能在编译阶段通过 --add-module 参数集成：
- 下载稳定分支（如 release/v2.5+）：
git clone --depth 1 https://github.com/FRiCKLE/ngx_cache_purge.git - 编译时加入：
./configure --add-module=/path/to/ngx_cache_purge [其他参数] - 验证是否生效：
nginx -V 2>&1 | grep cache_purge，有输出即成功
清理动作靠“精准 key 匹配”，不是模糊或条件扫描
PURGE 能否生效，90% 取决于你构造的 purge key 是否与原始 proxy_cache_key 字符串完全一致。Nginx 不做 URL 解析、不忽略大小写、不自动补参、不智能归一化路径。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 若缓存配置为：
proxy_cache_key "$scheme$request_method$host$request_uri"; - 则 purge location 中必须严格复用：
proxy_cache_purge my_cache "$scheme$request_method$host$1";（其中$1需覆盖完整$request_uri，含参数） - 常见失配点：
$urivs$request_uri（前者无参数）、$hostvs$proxy_host、遗漏$is_args$args、大小写不一致、重写后路径未同步
清理的是内存索引，不是实时删文件
proxy_cache_purge 删除的是共享内存中该 key 对应的缓存元数据，磁盘上的缓存文件仍保留，由 Nginx 的 cache manager 进程按 inactive 或 max_size 规则异步回收。
- 效果立竿见影：下次请求立即回源，
X-Cache-Status变为MISS或BYPASS - 不阻塞 IO：操作在毫秒级完成，无文件系统读写开销
- 不等于“清空磁盘”：若需释放空间，依赖
proxy_cache_path的inactive=12h等设置
生产环境必须加访问控制和可验证机制
/purge 接口是高危入口，暴露即风险。不能仅靠路径隐藏，需多层防护：
- IP 白名单：
allow 10.10.5.0/24;（CI/CD 节点）、allow 127.0.0.1;（本地运维脚本） - 鉴权增强：配合
auth_basic或auth_request接入内部 Token 服务 - 路径混淆：使用带随机后缀的路径，如
/purge-8a3f1e，降低自动化探测成功率 - 限速防刷：
limit_req zone=purge_burst burst=3 nodelay;
每次 purge 后，不能只看 200 就认为成功。务必验证：X-Cache-Status 响应头是否变更，或用相同请求实测是否回源。
