Nginx 缓存 POST 请求需精准识别查询型场景，配置 proxy_cache_methods、proxy_cache_key（须含$request_body或$args等区分字段）及响应缓存头，三者缺一不可。
要让 Nginx 对特定 POST 请求做边缘缓存，关键不是“放开所有 POST”，而是精准识别可缓存的 POST 场景，并配合 proxy_cache_methods、proxy_cache_key 和响应控制头协同生效。
明确哪些 POST 真的适合缓存
POST 通常代表状态变更操作，但有些内部接口本质是“查询型”：比如表单提交后返回固定结果页、搜索接口用 POST 提交复杂 JSON 查询、或网关层对下游服务的幂等读取封装。这类请求响应稳定、无副作用、不依赖会话，才具备缓存前提。
不建议缓存含用户身份写入、支付回调、实时数据推送等敏感或强时效性 POST。
基础配置必须同时满足三项
-
启用缓存区：在
http块中定义proxy_cache_path，例如：proxy_cache_path /var/cache/nginx/post_cache levels=1:2 keys_zone=post_cache:10m inactive=1h max_size=500m; -
显式声明方法：在
location或server块中设置：proxy_cache_methods GET HEAD POST; -
绑定缓存区并开启缓存：
proxy_cache post_cache;
核心：设计能区分不同 POST 内容的 cache_key
默认 key（如 $scheme$host$request_uri）对 POST 完全失效——所有 POST 请求 URI 相同，会共用一个缓存项。必须引入请求体或参数特征：
- 若 POST 数据为 JSON 且体积可控（≤1KB），启用
proxy_request_buffering on;（默认已开），再用：proxy_cache_key "$scheme$request_method$host$request_uri$request_body"; - 若 POST 是表单（
application/x-www-form-urlencoded），可用：proxy_cache_key "$scheme$request_method$host$request_uri$args";（前提是参数已通过rewrite或前端转为 query） - 更稳妥做法：由上游服务在响应头中输出唯一标识，例如
X-Post-Hash: abc123，然后：proxy_cache_key "$scheme$request_method$host$request_uri$upstream_http_x_post_hash";
确保响应本身允许被缓存
Nginx 默认忽略带 Set-Cookie、Cache-Control: private/no-store 的响应。需双向控制：
- 后端响应应包含明确缓存指令，例如：
Cache-Control: public, max-age=600（10 分钟） - 若后端无法修改，Nginx 可强制覆盖：
proxy_ignore_headers Cache-Control Set-Cookie;proxy_cache_valid 200 10m; - 验证是否命中：加响应头便于调试：
add_header X-Cache $upstream_cache_status;（返回HIT/MISS）
