Nginx 默认不缓存 POST 是主动设计，需先判断是否真该缓存；若必须缓存，则须同时满足四条件：放行方法、忽略禁用头、构造唯一 cache key、显式设有效期；更推荐改用 GET 等幂等方法替代。
Nginx 默认不缓存 POST 请求，这不是配置遗漏，而是主动设计——它从方法层面直接跳过整个缓存流程。要“绕过”这个特性，本质不是强行让 POST 进缓存，而是明确判断：该 POST 是否真该被缓存？若不该，就保持默认；若该，则必须系统性补全四点。
✅ 明确哪些 POST 绝对不该缓存
这类请求一旦进缓存，轻则数据错乱，重则重复扣款、越权访问：
- 含
Authorization或Cookie头的登录、下单、修改密码接口 - 响应头带
Set-Cookie、Cache-Control: no-store或Vary: Cookie的动态响应 - URL 路径匹配
/admin/、/api/v1/order、/submit等语义明确的非幂等路径
此时，无需额外配置，Nginx 默认行为就是最安全的选择。
✅ 真需要缓存的 POST，必须同步满足四个条件
仅改 proxy_cache_methods GET HEAD POST 或 fastcgi_cache_methods GET HEAD POST 完全无效，必须四者齐备：
放行方法：在启用缓存的
location块中写入proxy_cache_methods GET HEAD POST;
或（FastCGI 场景）fastcgi_cache_methods GET HEAD POST;忽略后端禁用头：否则
Cache-Control: no-cache或Set-Cookie会直接拒收proxy_ignore_headers Cache-Control Expires Set-Cookie;
或fastcgi_ignore_headers Cache-Control Expires Set-Cookie;构造唯一 cache key：不能依赖
$request_body（Nginx 不保证其可用且含敏感内容）
推荐方案：后端在响应中写入签名头X-Req-Sign: a1b2c3，Nginx 中用proxy_cache_key "$scheme$proxy_host$request_uri$args$http_x_req_sign";显式定义有效时间：POST 响应默认无缓存有效期，必须指定
proxy_cache_valid 200 201 5m;
或fastcgi_cache_valid 200 201 5m;
✅ 更推荐的替代方案：避免 POST 缓存本身
多数所谓“需缓存的 POST”，其实是语义错位：
- 搜索接口 → 改用
GET /api/search?q=xxx&filter=yyy，Nginx 原生支持、key 清晰、调试直观 - GraphQL 查询 → 后端支持
GET /graphql?query=...（需转义），或前端统一走签名化 query string - 内部服务调用 → 用固定参数 + 时间戳签名生成确定性 URL，彻底规避 body 解析问题
这样既避开 $request_body 不稳定风险，也无需妥协安全头逻辑。
不复杂但容易忽略
