Nginx中禁用非必要HTTP方法应优先使用limit_except指令严格限定GET、HEAD、POST；全局策略可用if+$request_method匹配白名单；API路径需单独放行OPTIONS并拦截TRACE/PUT等高危方法；超高并发时可结合map提升性能。
在 Nginx 的 server 块中禁用不需要的 HTTP 方法（如 DELETE、TRACE、PUT、TRACK），核心是只放行业务必需的方法，其余一律拦截。最稳妥、语义清晰且官方推荐的方式是使用 limit_except 指令；若需全局统一策略或适配 API 场景，则配合 if + return 或分路径处理。
用 limit_except 严格限定方法（推荐主入口使用）
这是最直接高效的做法，适合放在根 location / 中，覆盖所有未特殊定义的路径，防止绕过：
- 只允许
GET、HEAD、POST，其余方法（含OPTIONS、DELETE、TRACE等）自动返回405 Not Allowed - 无需额外模块，原生支持，性能好，符合 HTTP 规范
- 示例配置：
location / {
limit_except GET HEAD POST {
deny all;
}
proxy_pass http://backend;
}
全局 if 判断拦截非法方法（适合简单统一策略）
若希望在整个 server 块顶层统一控制，可用 if 结合 $request_method 判断：
- 匹配不在白名单中的方法后立即返回
405（或静默关闭连接的444） - Nginx 官方明确说明该用法对
$request_method是安全的 - 建议用正则精确匹配，避免误拦，例如：
^(GET|HEAD|POST)$ - 示例：
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 405;
}
为 API 接口单独放行 OPTIONS（兼顾 CORS 需求）
RESTful API 必须响应浏览器预检请求（OPTIONS），不能全局禁用。应按路径区分策略：
- 普通页面路径（如
/）仍用limit_except严格限制 -
/api/类路径显式处理OPTIONS：返回必要 CORS 头并return 204 - 同时对高危方法（如
TRACE、TRACK）做额外拦截，不依赖白名单逻辑 - 示例片段：
location /api/ {
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 "Authorization, Content-Type";
return 204;
}
if ($request_method ~ ^(TRACE|TRACK|PUT|DELETE)$) {
return 405;
}
proxy_pass http://backend;
}
高并发场景可选：用 map + if 提升性能
当站点流量极大、需减少重复正则匹配开销时，可在 http{} 块顶部定义映射：
- 先用
map将请求方法映射为布尔值或状态码，避免每个请求都执行正则 - 再在
server或location中用if判断映射结果 - 适用于日均百万级以上请求的 API 网关类场景
