如何设置 proxy_cache_methods 以启用特定请求方法的静态边缘缓存加速?
- 内容介绍
- 文章标签
- 相关推荐
本文共计839个文字,预计阅读时间需要4分钟。
plaintextproxy_cache_methods 不用于开启静态边缘加速,它仅控制哪些 HTTP 请求方法可以被缓存——即实现静态边缘加速的是 proxy_cache 和 proxy_cache_valid。这些命令组合定义了缓存头(如 Cache-Control)。
proxy_cache_methods 的作用是 收集缓存范围,确保只有安全、幂等的请求方法(如 GET、HEAD)被缓存,避免将 POST、PUT 等写操作误缓存。
如果你的目标是「对静态资源做边缘缓存加速」,重点不是开启 proxy_cache_methods,而是正确配置它来配合整体缓存策略,防止缓存污染或行为异常。
以下是实用配置要点:
明确支持的请求方法
Nginx 默认只缓存 GET 和 HEAD 请求(这是最安全的),无需额外设置。但若你明确需要扩展(极少见),可显式声明:
proxy_cache_methods GET HEAD; # 不建议加入 POST / PUT / DELETE —— 它们本就不该被缓存
-
GET:获取资源,天然适合缓存 -
HEAD:仅校验元信息,响应体为空,复用 GET 缓存即可 - ✅ 保持默认即可,不建议修改
静态资源缓存必须配套的关键项
仅设 proxy_cache_methods 没有意义。要真正生效,需在 location 块中完整配置:
- 启用缓存区(必须与
proxy_cache_path中定义的keys_zone名称一致) - 设置缓存有效期(按状态码区分)
- 保证后端响应带合理缓存头(或由 Nginx 强制注入)
- 确保
proxy_cache_key不包含易变字段(如 Cookie、随机参数)
示例(针对 /static/ 下的图片、JS、CSS):
location ~* \.(js|css|png|jpg|gif|woff2|svg)$ { proxy_cache my_edge_cache; proxy_cache_valid 200 304 1y; proxy_cache_valid 404 1m; add_header Cache-Control "public, immutable"; expires 1y; proxy_pass https://origin; }
特别注意:避免缓存非幂等请求
如果业务中存在某些“伪静态”接口(比如带查询参数的 JSON 接口),又想缓存,不要靠改 proxy_cache_methods 来实现,而应:
- 使用
proxy_cache_key精确构造(如含$arg_id但不含$cookie_session) - 配合
proxy_cache_bypass控制绕过条件(如带X-Refresh头时跳过) - 对
POST请求,即使加了proxy_cache_methods POST,也极易引发数据一致性问题,生产环境严禁启用
小结:你应该怎么做
- 保留默认
proxy_cache_methods GET HEAD,不改动 - 把精力放在:
- 正确定义
proxy_cache_path(磁盘路径、共享内存区) - 在
location中启用proxy_cache并配proxy_cache_valid - 用
add_header Cache-Control或expires主动下发强缓存指令 - 前端 URL 指向 CDN 域名,让边缘节点真正参与分发
- 正确定义
这样,静态资源才能稳定命中边缘缓存,实现加载加速与源站减负。
本文共计839个文字,预计阅读时间需要4分钟。
plaintextproxy_cache_methods 不用于开启静态边缘加速,它仅控制哪些 HTTP 请求方法可以被缓存——即实现静态边缘加速的是 proxy_cache 和 proxy_cache_valid。这些命令组合定义了缓存头(如 Cache-Control)。
proxy_cache_methods 的作用是 收集缓存范围,确保只有安全、幂等的请求方法(如 GET、HEAD)被缓存,避免将 POST、PUT 等写操作误缓存。
如果你的目标是「对静态资源做边缘缓存加速」,重点不是开启 proxy_cache_methods,而是正确配置它来配合整体缓存策略,防止缓存污染或行为异常。
以下是实用配置要点:
明确支持的请求方法
Nginx 默认只缓存 GET 和 HEAD 请求(这是最安全的),无需额外设置。但若你明确需要扩展(极少见),可显式声明:
proxy_cache_methods GET HEAD; # 不建议加入 POST / PUT / DELETE —— 它们本就不该被缓存
-
GET:获取资源,天然适合缓存 -
HEAD:仅校验元信息,响应体为空,复用 GET 缓存即可 - ✅ 保持默认即可,不建议修改
静态资源缓存必须配套的关键项
仅设 proxy_cache_methods 没有意义。要真正生效,需在 location 块中完整配置:
- 启用缓存区(必须与
proxy_cache_path中定义的keys_zone名称一致) - 设置缓存有效期(按状态码区分)
- 保证后端响应带合理缓存头(或由 Nginx 强制注入)
- 确保
proxy_cache_key不包含易变字段(如 Cookie、随机参数)
示例(针对 /static/ 下的图片、JS、CSS):
location ~* \.(js|css|png|jpg|gif|woff2|svg)$ { proxy_cache my_edge_cache; proxy_cache_valid 200 304 1y; proxy_cache_valid 404 1m; add_header Cache-Control "public, immutable"; expires 1y; proxy_pass https://origin; }
特别注意:避免缓存非幂等请求
如果业务中存在某些“伪静态”接口(比如带查询参数的 JSON 接口),又想缓存,不要靠改 proxy_cache_methods 来实现,而应:
- 使用
proxy_cache_key精确构造(如含$arg_id但不含$cookie_session) - 配合
proxy_cache_bypass控制绕过条件(如带X-Refresh头时跳过) - 对
POST请求,即使加了proxy_cache_methods POST,也极易引发数据一致性问题,生产环境严禁启用
小结:你应该怎么做
- 保留默认
proxy_cache_methods GET HEAD,不改动 - 把精力放在:
- 正确定义
proxy_cache_path(磁盘路径、共享内存区) - 在
location中启用proxy_cache并配proxy_cache_valid - 用
add_header Cache-Control或expires主动下发强缓存指令 - 前端 URL 指向 CDN 域名,让边缘节点真正参与分发
- 正确定义
这样,静态资源才能稳定命中边缘缓存,实现加载加速与源站减负。

