nginx中location不支持直接按http方法白名单过滤，需用if+$request_method配合return实现；推荐用map统一管理多路径方法策略，或结合auth_request交由后端动态鉴权。
在 Nginx 中，location 本身不直接支持按 HTTP 请求方法（如 GET、POST、PUT、DELETE）做白名单过滤，但可以通过 if 指令配合 $request_method 变量 + return 或 deny 实现精准拦截。关键在于：不能在 location 块外写方法判断，且需避免在 if 中使用可能引发重写冲突的指令（如 rewrite）。
用 if + $request_method 限定允许的方法
在目标 location 块内，用 if 判断当前请求方法是否在白名单中；不在则直接拒绝：
location ^~ /api/users/ {
# 白名单：只放行 GET 和 POST
if ($request_method !~ ^(GET|POST)$) {
return 405 "Method Not Allowed";
}
proxy_pass https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e;
}
说明：
• $request_method 是内置只读变量，值为大写（如 GET、PUT）；
• 正则 ^(GET|POST)$ 确保完全匹配，防止 GETX 类绕过；
• return 405 符合 HTTP 语义，比 403 更准确；
• 推荐用 ^~ 前缀提升匹配效率，尤其当路径固定时。
对多个 location 统一管理方法白名单
若多个路径需相同方法策略，可提取为 map 变量，避免重复 if：
# 在 http 块顶部定义
map $request_method $allowed_method {
default 0;
GET 1;
POST 1;
HEAD 1;
}
<p>server {
location ^~ /api/ {
if ($allowed_method = 0) {
return 405;
}
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
}
}</p>
优点：
• 逻辑集中，增删方法只需改 map；
• map 在请求处理早期执行，性能优于多次 if；
• 不受 if 嵌套限制，适合复杂策略。
注意 rewrite 和 if 的陷阱
Nginx 官方明确警告：if 在 location 中行为受限，尤其避免以下写法：
- 不要在
if内写proxy_pass、rewrite或set（除非必要）； - 不要用
if ($request_method = POST) { ... }这种等值判断——它只匹配字面量，不支持正则，且易因空格失败； - 禁止在
if外层再套if，Nginx 不支持嵌套条件； - 如果需记录被拦截的请求，用
access_log配合log_not_found off或自定义日志条件。
结合 auth_request 做更灵活的鉴权（进阶）
若白名单逻辑复杂（如依赖用户角色、时间窗口），可将方法校验下沉到后端服务，用 auth_request 统一拦截：
location ^~ /api/admin/ {
auth_request /auth-method-check;
proxy_pass http://admin_backend;
}
<p>location = /auth-method-check {
internal;
proxy_pass <a href="https://www.php.cn/link/1dde7ecf2976f46eb872ff4f1159d1df">https://www.php.cn/link/1dde7ecf2976f46eb872ff4f1159d1df</a>;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-Method $request_method;
}</p>
此时后端 /method-check 接口接收 X-Original-Method，返回 200（放行）或 403（拒绝），Nginx 自动处理后续流程。这种方式解耦清晰，适合动态策略。
