proxy_cache_methods的作用是显式声明允许进入缓存流程的HTTP方法,采用白名单机制,默认仅GET和HEAD,其他方法如POST需显式放行且满足四个条件才能缓存。
proxy_cache_methods 的作用不是“限制”缓存方法,而是显式声明哪些 HTTP 方法允许进入缓存流程。Nginx 默认只让 GET 和 HEAD 请求走缓存,其他方法(如 POST、PUT)即使配置了 proxy_cache,也会被自动跳过——除非你用 proxy_cache_methods 明确放行。
要达成“限制效果”,关键是不写不该缓存的方法,而不是靠它做拦截。它的逻辑是白名单:只处理列表里的方法,其余一律绕过缓存。
location /api/ { proxy_pass http://backend; proxy_cache my_cache; proxy_cache_methods GET HEAD;}
这和不写该指令效果一致,但显式写出更清晰,也避免被后续误加 POST。
仅加 proxy_cache_methods GET HEAD POST; 不够,缺一不可:
已定义缓存区(http 块中):
proxy_cache_path /var/cache/nginx/post_cache levels=1:2 keys_zone=post_cache:10m;
在 location 中启用对应缓存区:
proxy_cache post_cache;
显式声明方法:
proxy_cache_methods GET HEAD POST;
构造能区分不同请求体的 proxy_cache_key:
proxy_cache_key "$scheme$request_method$host$request_uri$args$request_body";
(需确保 proxy_buffering on; 且 client_max_body_size 足够,否则 $request_body 可能为空)
写在 http 块顶层,未绑定 proxy_cache:
# 错误:无 cache 区绑定,该指令不生效proxy_cache_methods POST;
单独写 POST,不带 GET/HEAD:
# 错误:GET/HEAD 请求将不再缓存,可能破坏静态资源加速proxy_cache_methods POST;
尝试缓存 OPTIONS、TRACE、CONNECT:
proxy_cache_methods GET POST OPTIONS; # OPTIONS 始终不缓存,Nginx 直接忽略
proxy_no_cache 做二次过滤proxy_cache_methods 是第一道门,proxy_no_cache 是第二道门,推荐组合使用:
# 跳过含敏感头的请求,哪怕它是 GETproxy_no_cache $http_cookie $http_authorization $arg_token;# 或按方法跳过副作用操作proxy_no_cache $request_method ~ ^(POST|PUT|DELETE)$;
这样即使某处误开了 POST 缓存,也能靠此规则兜底拦截。
加一行响应头便于观察:
add_header X-Cache-Status $upstream_cache_status;
然后用相同请求反复测试:
MISS
HIT → 表示缓存已生效MISS,检查 proxy_cache 是否启用、proxy_cache_key 是否重复、响应头是否含 Set-Cookie 等默认禁用项不复杂但容易忽略。