必须在 location 块中用 allow/deny 严格限制 purge 请求的 ip，仅放行运维跳板机等可信内网地址并以 deny all; 兜底；高安全场景需叠加 auth_request 鉴权校验 jwt；同时禁用非必要 http 方法、精确匹配 /purge/xxx 路径，并通过测试验证 403/405 响应是否生效。
要让 Nginx 的 PURGE 请求只被可信来源调用，必须在 location 块中显式限制访问 IP，不能依赖域名、Referer 或模糊规则——这是防止缓存被恶意清空的第一道防线。
严格配置 allow/deny 规则
在处理 purge 的 location 中，只放行运维跳板机、CI/CD 发布节点等内网固定 IP 或网段，结尾必须加 deny all;：
-
allow 10.10.5.10;（单台跳板机） -
allow 192.168.100.0/24;（发布子网） -
deny all;（强制兜底，避免隐式放行）
注意：顺序不可颠倒，deny all 必须放在最后且不可省略；若漏写或位置错误，Nginx 默认允许所有请求。
配合 auth_request 实现双因子校验
仅靠 IP 不足以应对高安全要求场景。建议叠加内部鉴权服务，例如用 auth_request 对接 OAuth 网关：
- 在 purge location 中加入：
auth_request /auth/purge; - 单独配置
/auth/purgelocation，用proxy_pass转发到内部鉴权服务 - 鉴权服务校验 JWT token 权限（如
scope:cache.purge），返回 200 才放行
这样即使 IP 在白名单内，也需携带有效 token，降低凭证泄露带来的风险。
禁用非必要 HTTP 方法并锁定 PURGE 路径
避免攻击者通过非常规方式触发 purge：
- 确保 location 仅匹配
/purge/xxx形式，不接受/purge根路径或无前缀的 PURGE 请求 - 在 server 块顶层或 http 块中添加：
limit_except GET HEAD PURGE { deny all; }，禁止 PUT/POST/DELETE 等方法访问该 server - 不要在 purge location 中启用
proxy_method PURGE以外的代理逻辑，防止被绕过
验证是否生效
配置完成后务必测试：
- 从白名单 IP 执行：
curl -X PURGE http://example.com/purge/api/user/123→ 应返回 200 或 204 - 从非白名单 IP 执行同样命令 → 必须返回 403 Forbidden
- 从白名单 IP 发送
GET /purge/xxx→ 应返回 405 Method Not Allowed
任何一项不满足，都说明限制未真正生效，需回查 allow/deny 顺序、location 匹配逻辑或 limit_except 范围。
