在 nginx 中过滤并丢弃非法的 http 请求方法，最直接且高效的做法是在 location 块中使用 if 指令配合 $request_method 变量进行判断。当检测到请求方法不在允许的白名单（如 get、post）内时，通过 return 405 直接终止处理并返回 405 method not allowed 状态码。这种方法无需加载额外的模块或执行复杂的正则匹配，能够以极低的开销拦截不符合预期的请求。
$request_method 变量如何获取当前请求的方法
$request_method 是 Nginx 内置的全局变量，它直接映射客户端发送的 HTTP 请求行中的方法字段。该变量的值始终为大写字符串，例如 GET、POST、PUT 或 DELETE。开发者可以通过简单的相等性判断来识别具体的方法类型，这是构建访问控制逻辑的基础。
server {
listen 80;
server_name example.com;
location /api/ {
# 检查请求方法是否为 GET 或 POST
if ($request_method !~ ^(GET|POST)$) {
return 405;
}
# 正常的业务逻辑配置
proxy_pass http://backend;
}
}
上述配置展示了如何在 /api/ 路径下实施方法过滤。当客户端发送 OPTIONS 或 PATCH 请求时，$request_method 的值将不匹配正则表达式 ^(GET|POST)$，从而触发 if 块内的 return 405。Nginx 会立即停止处理该请求，并向客户端返回 405 状态码，而不会将请求转发给后端服务器。这种机制确保了只有合法的方法才能进入后续的处理流程。
为什么使用 return 405 而不是 deny all
在处理非法请求方法时，选择正确的响应状态码至关重要。return 405 明确告知客户端服务器理解该方法，但当前资源不支持该操作，符合 HTTP/1.1 规范（RFC 7231）。相比之下，deny all 通常用于 IP 访问控制，返回的是 403 Forbidden，这暗示权限不足而非方法不被支持。此外，return 指令的执行优先级高于其他处理阶段，能够确保在请求被解析为完整的 URI 之前就被拦截，从而节省资源。
# 对比测试：使用 curl 模拟不同请求方法 curl -X GET http://example.com/api/test # 正常处理 curl -X POST http://example.com/api/test # 正常处理 curl -X DELETE http://example.com/api/test # 返回 405 Method Not Allowed curl -X OPTIONS http://example.com/api/test # 返回 405 Method Not Allowed
通过 curl 命令可以直观地验证上述配置的效果。对于 GET 和 POST 请求，Nginx 会将其代理到后端；而对于 DELETE 和 OPTIONS 请求，Nginx 会在本地直接返回 405 状态码。这种区分不仅有助于前端调试，也能防止后端服务接收到无法处理的请求，从而提升系统的整体稳定性和安全性。
CORS 预检请求 OPTIONS 的特殊处理
在实际应用中，跨域资源共享（CORS）经常需要客户端发送 OPTIONS 预检请求。如果严格限制只允许 GET 和 POST，会导致跨域请求失败。因此，需要在白名单中显式包含 OPTIONS，并针对该请求返回特定的 CORS 响应头，而不是简单地返回 405。这要求对 if 判断逻辑进行微调，以区分普通非法方法和 CORS 预检方法。
location /api/ {
# 允许 GET, POST, 以及 CORS 预检的 OPTIONS
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
if ($request_method !~ ^(GET|POST|OPTIONS)$) {
return 405;
}
# 正常的业务逻辑配置
proxy_pass http://backend;
}
这段配置首先处理 OPTIONS 请求，添加必要的 CORS 头并返回 204 No Content，表示预检成功。然后，更新正则表达式以包含 OPTIONS，确保后续的 if 判断不会误杀合法的预检请求。这种处理方式既保证了安全性，又兼容了现代 Web 应用的跨域需求。
