proxy_cache_methods仅控制哪些HTTP方法可被缓存，默认GET/HEAD，不开启缓存也不提供加速；必须配合proxy_cache、proxy_cache_valid等指令才能启用边缘缓存。
proxy_cache_methods 本身并不开启缓存，也不直接提供“高性能边缘加速”，它只是控制哪些 HTTP 请求方法允许被缓存。真正启用缓存并实现边缘加速，必须配合 proxy_cache、proxy_cache_valid 等核心指令共同生效。
要构建针对特定请求方式（如仅缓存 GET 和 HEAD）的稳定、可控的边缘缓存方案，关键在于精准配置缓存策略 + 明确排除不适用方法（如 POST、PUT、DELETE 默认不缓存），避免语义错误或数据污染。
✅ 正确理解 proxy_cache_methods 的作用
该指令定义 Nginx 在执行缓存时，接受哪些请求方法作为缓存候选。
- 默认值是
GET HEAD—— 这已覆盖绝大多数只读、安全、幂等的缓存场景。 - 它不会让
POST变得可缓存；即使你写proxy_cache_methods GET HEAD POST，Nginx 仍会拒绝缓存POST响应，除非你额外用proxy_cache_key和proxy_ignore_headers等强行绕过语义限制（强烈不建议）。 - 缓存行为最终由
proxy_cache_valid+proxy_cache+ 响应头（如Cache-Control）共同决定，proxy_cache_methods只是第一道过滤门。
✅ 配置仅对 GET/HEAD 启用缓存（推荐生产用法）
在 http 或 server 块中启用缓存区，并显式限定方法：
proxy_cache_path /var/cache/nginx/edge levels=1:2 keys_zone=edge:20m max_size=2g inactive=60m use_temp_path=off;
server {
location /api/ {
proxy_pass https://backend;
proxy_cache edge;
proxy_cache_valid 200 302 5m; # 成功响应缓存5分钟
proxy_cache_valid 404 1m; # 404也缓存1分钟，减轻后端压力
proxy_cache_methods GET HEAD; # 显式声明：只考虑GET/HEAD请求缓存
proxy_cache_use_stale error timeout updating;
add_header X-Cache-Status $upstream_cache_status;
}
}
⚠️ 注意：
proxy_cache_methods必须与proxy_cache同级启用；单独写它不生效。
✅ 为什么通常不缓存 POST、PUT、DELETE？
这些方法具有副作用，语义上代表“修改资源”，缓存其响应会导致：
- 用户提交表单后看到旧的成功页（实际已失败）
- 多次点击按钮触发重复操作（如重复下单）
- 缓存了含敏感上下文的响应（如登录态跳转）
若业务确有特殊需求（例如幂等性保障下的查询型 POST），应：
- 使用固定
proxy_cache_key强制统一键（如proxy_cache_key "$scheme$request_method$host$request_uri";） - 清除响应中的
Set-Cookie、Vary等干扰头（proxy_hide_header Set-Cookie;） - 显式覆盖响应头
Cache-Control: public, max-age=60 - 务必在测试环境验证一致性，并监控
$upstream_cache_status日志
✅ 配合缓存控制更可靠的方式（比改 methods 更常用）
比起扩展 proxy_cache_methods，更推荐用以下方式精细化管理：
- 用
proxy_no_cache $arg_nocache $http_x_no_cache跳过特定请求 - 用
proxy_cache_bypass $arg_refresh $http_x_refresh实现手动刷新 - 用
proxy_cache_lock on防止缓存穿透击穿（首次未命中时只放行一个请求打后端） - 用
proxy_cache_revalidate on支持stale-while-revalidate机制
这些机制比放宽 proxy_cache_methods 更安全、更符合 HTTP 语义。
