proxy_cache_methods 用于指定可缓存的HTTP方法，默认仅GET和HEAD；安全场景下可显式添加OPTIONS，需配合$request_method纳入proxy_cache_key以区分缓存项。
proxy_cache_methods 用于明确指定哪些 HTTP 请求方法可以被 Nginx 缓存。默认只缓存 GET 和 HEAD，而像 POST、PUT、DELETE 等非幂等方法默认不缓存——这是出于安全与语义的合理限制。但若你确需对特定静态资源（如某些只读接口、预签名资源查询）启用 OPTIONS 或 GET 以外的方法缓存，就必须显式配置该指令。
哪些请求方法适合开启缓存
静态资源边缘加速场景中，真正可安全缓存的非 GET 方法极少。常见合理用例包括：
-
OPTIONS：常用于 CORS 预检，响应固定且无副作用，适合缓存（如返回固定 headers） -
HEAD：已默认支持，无需额外配置，但可显式写出以增强可读性 -
GET：必须保留，是静态资源缓存的主力
不建议为 POST、PUT、PATCH、DELETE 开启缓存，它们本质携带状态变更意图，违反 HTTP 缓存语义，易导致数据不一致或安全风险。
配置位置与语法要点
该指令只能出现在 http、server 或 location 块中，且必须与 proxy_cache 同级生效。典型配置如下：
location /api/static-meta/ {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_cache_valid 200 304 1h;
proxy_cache_methods GET HEAD OPTIONS; # 显式允许这三种方法
add_header X-Cache-Status $upstream_cache_status;
}
注意：
- 大小写不敏感，但惯例全大写
- 多个方法用空格分隔，不可用逗号
- 一旦在某 location 中设置，会覆盖上级继承值；未设置则沿用默认（GET HEAD）
- 它只控制“是否尝试缓存”，最终能否命中还取决于
proxy_cache_key、proxy_cache_valid及响应头（如 Cache-Control）
配合缓存键（proxy_cache_key）精准识别
仅放开方法不够，还需确保不同请求方法的响应被正确区分缓存。例如，GET /logo.png 和 OPTIONS /logo.png 应视为两个独立缓存项：
proxy_cache_key "$scheme$request_method$host$request_uri";
其中 $request_method 是关键——它把请求方法纳入缓存键，避免 GET 响应被 OPTIONS 请求误取，或反之。
验证与调试技巧
上线后可通过以下方式确认配置生效：
- 发起
curl -I -X OPTIONS https://yoursite.com/api/static-meta/，检查响应头是否含X-Cache-Status: HIT（首次为 MISS，二次为 HIT） - 查看 Nginx error log 是否报错：
proxy_cache_methods不支持的方法会直接拒绝缓存，但不会中断请求 - 用
nginx -t校验语法，错误写法（如含 POST）不会报错，但实际无效
不复杂但容易忽略。
