proxy_cache_methods的作用是显式声明允许进入缓存流程的HTTP方法，采用白名单机制，默认仅GET和HEAD，其他方法如POST需显式放行且满足四个条件才能缓存。

proxy_cache_methods 的作用不是“限制”缓存方法，而是显式声明哪些 HTTP 方法允许进入缓存流程。Nginx 默认只让 GET 和 HEAD 请求走缓存，其他方法（如 POST、PUT）即使配置了 proxy_cache，也会被自动跳过——除非你用 proxy_cache_methods 明确放行。

要达成“限制效果”，关键是不写不该缓存的方法，而不是靠它做拦截。它的逻辑是白名单：只处理列表里的方法，其余一律绕过缓存。

---

✅ 正确写法：只允许 GET 和 HEAD（即保持默认行为）

location /api/ {
    proxy_pass http://backend;
    proxy_cache my_cache;
    proxy_cache_methods GET HEAD;
}

这和不写该指令效果一致，但显式写出更清晰，也避免被后续误加 POST。

---

⚠️ 想支持 POST？必须同时满足四个条件

仅加 proxy_cache_methods GET HEAD POST; 不够，缺一不可：

• 已定义缓存区（http 块中）：

  proxy_cache_path /var/cache/nginx/post_cache levels=1:2 keys_zone=post_cache:10m;

• 在 location 中启用对应缓存区：

  proxy_cache post_cache;

• 显式声明方法：

  proxy_cache_methods GET HEAD POST;

• 构造能区分不同请求体的 proxy_cache_key：

  proxy_cache_key "$scheme$request_method$host$request_uri$args$request_body";

  （需确保 proxy_buffering on; 且 client_max_body_size 足够，否则 $request_body 可能为空）

  

  FastAPI Flask Proxy

  FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

  下载

---

❌ 这些写法无效或危险

• 写在 http 块顶层，未绑定 proxy_cache：

  # 错误：无 cache 区绑定，该指令不生效
  proxy_cache_methods POST;

• 单独写 POST，不带 GET/HEAD：

  # 错误：GET/HEAD 请求将不再缓存，可能破坏静态资源加速
  proxy_cache_methods POST;

• 尝试缓存 OPTIONS、TRACE、CONNECT：

  proxy_cache_methods GET POST OPTIONS;  # OPTIONS 始终不缓存，Nginx 直接忽略

---

? 安全建议：用 proxy_no_cache 做二次过滤

proxy_cache_methods 是第一道门，proxy_no_cache 是第二道门，推荐组合使用：

# 跳过含敏感头的请求，哪怕它是 GET
proxy_no_cache $http_cookie $http_authorization $arg_token;

# 或按方法跳过副作用操作
proxy_no_cache $request_method ~ ^(POST|PUT|DELETE)$;

这样即使某处误开了 POST 缓存，也能靠此规则兜底拦截。

---

? 验证是否生效

加一行响应头便于观察：

add_header X-Cache-Status $upstream_cache_status;

然后用相同请求反复测试：

• 第一次返回 MISS
• 后续返回 HIT → 表示缓存已生效
• 若始终 MISS，检查 proxy_cache 是否启用、proxy_cache_key 是否重复、响应头是否含 Set-Cookie 等默认禁用项

不复杂但容易忽略。