Nginx不支持在location路径匹配中直接按HTTP方法（如GET/POST）区分，但可通过if指令结合$request_method变量实现方法控制，推荐多分支场景使用map指令提升效率与可维护性。
Nginx 本身不支持在 location 块中直接根据 HTTP 请求方法（如 GET、POST、DELETE 等）进行匹配。也就是说，你不能写类似 location GET /api/ { ... } 这样的语法。但可以通过 if 指令结合 $request_method 变量，在 location 内部做条件判断，实现按请求方法分流或限制。
用 if 判断 $request_method 实现方法控制
这是最常用且官方支持的方式。注意：if 只能在 server 或 location 块中使用，且应避免在 location 外滥用（Nginx 官方文档明确指出 if 在某些上下文中有风险，但在方法判断场景下是安全的）。
- 使用
$request_method获取当前请求方法，值为全大写字符串（如GET、POST、PUT、DELETE） - 配合
if做精确匹配，再执行return、deny、proxy_pass等动作 - 示例：只允许
GET和HEAD访问静态资源目录
location /static/ {
if ($request_method !~ ^(GET|HEAD)$) {
return 405;
}
# 正常处理静态文件
root /var/www;
}对特定方法做特殊处理（如拦截 POST）
常见于 API 接口保护或调试场景，比如禁止某路径接收 POST 请求，或把 PUT 请求重定向到后端特定服务。
- 可嵌套多个
if，但建议用map提升可读性（见下一点） - 注意：不要在
if中使用proxy_pass以外的复杂指令（如rewrite后再proxy_pass），可能引发变量失效 - 示例：将所有
DELETE请求返回自定义响应
location /api/users/ {
if ($request_method = DELETE) {
return 200 '{"status":"deleted"}';
}
proxy_pass http://backend;
}用 map 预定义方法路由规则（推荐用于多方法分支）
当需要根据方法做多种不同处理时，map 指令比层层 if 更清晰、高效，且在配置加载时就完成映射，无运行时开销。
- 在
http块中定义map，将$request_method映射为变量（如$method_route） - 在
location中通过该变量控制行为，例如选择不同proxy_pass地址或启用不同限流策略 - 示例：按方法分发到不同后端
http {
map $request_method $backend_url {
GET http://read-svc;
POST http://write-svc;
PUT http://write-svc;
DELETE http://write-svc;
default http://read-svc;
}
<pre class="brush:php;toolbar:false;">server {
location /api/ {
proxy_pass $backend_url;
}
}}
注意事项与替代思路
纯靠 Nginx 控制 HTTP 方法虽可行，但需注意边界和局限性：
-
if不支持else，多分支逻辑建议优先用map - 无法在
location路径匹配阶段区分方法——所有方法都会进入同一个location，必须在内部判断 - 若需更精细控制（如方法 + 请求头 + Body 内容联合判断），建议交由上游应用处理，Nginx 仅做基础路由或防护
- 对于 RESTful API，通常更推荐由后端框架统一处理方法语义，Nginx 专注反向代理、限流、HTTPS 卸载等职责
