Nginx仅支持GET、HEAD、POST缓存，其中POST仅限Nginx→后端单跳去重；需按路径在location级精细化配置proxy_cache_methods、proxy_cache_key（含$request_body）及proxy_cache_valid，并校验后端Cache-Control头。
Nginx 默认只缓存 `GET` 和 `HEAD` 请求，要实现针对特定 HTTP 方法的高性能反代加速，关键不是盲目扩展方法列表，而是按业务语义精准控制缓存行为——既要提升命中率，又要规避副作用。
明确哪些方法真能安全缓存
可配置进 proxy_cache_methods 的方法只有：GET、HEAD、POST（PUT、DELETE、PATCH 等不被支持，声明也无效）。
但需注意：
- OPTIONS、TRACE、CONNECT 始终不可缓存，Nginx 会静默忽略它们在该指令中的出现
- POST 缓存仅对 Nginx 本机有效：浏览器和中间代理不会识别 POST 响应的 Cache-Control，也不发起条件请求，所以它只适用于「Nginx → 后端」这一跳的重复请求去重，比如高频查询类 API
- 缓存 POST 前必须确保：后端响应带明确 Cache-Control: public, max-age=N，且内容无用户敏感信息、无强时效依赖
按路径精细化启用方法级缓存
不要在全局 http 或 server 块中粗放设置 proxy_cache_methods GET HEAD POST。推荐在 location 级别按接口语义控制：
- 对只读查询接口（如
/api/v1/search），启用 POST 缓存，并定制 key 包含请求体：proxy_cache_key "$scheme$request_method$host$request_uri$request_body"; - 对写操作路径（如
/api/v1/submit、/upload），显式关闭缓存：proxy_cache off;或直接不配proxy_cache - 对静态资源或传统页面，保持默认即可：
proxy_cache_methods GET HEAD;（无需显式声明，这是内置行为）
配套必须做的三件事
单独改 proxy_cache_methods 几乎没用，必须同步落实：
-
强制校验后端缓存头：Nginx 默认遵循
Cache-Control和Expires。若后端未返回public或max-age，即使方法允许，也不会缓存。调试时可用curl -I检查响应头 -
用
proxy_cache_valid牢牢兜底：例如proxy_cache_valid 200 302 5m;，避免因后端漏设头导致完全不缓存；对 4xx 错误也建议设短时间缓存（如404 1m），防刷 -
缓存键设计必须区分方法与负载：若启用 POST 缓存，
$request_body必须进入proxy_cache_key，否则不同请求体全打到同一个缓存项上，造成数据污染
性能与安全边界提醒
高并发下 POST 缓存可能带来隐性开销：
-
$request_body过大会拖慢 key 计算和磁盘 I/O，建议限制 body 大小（client_max_body_size）并监控缓存平均大小 - 不建议缓存含 Cookie、Authorization 等动态头的请求，除非你已在
proxy_cache_key中显式包含并确认安全 - 生产环境首次启用 POST 缓存，务必配合日志或 Prometheus 监控
nginx_http_cache_status指标，验证命中率与错误率
