nginx 推荐用 limit_except 限制 http 方法，如 location /api/ { limit_except get head post { deny all; } }；全局禁用 trace/track 等高危方法可用 if + return，但需置于 server 块顶部；allow/deny 不支持按方法过滤。
Nginx 本身不支持在 location 块内直接用 if 判断 $request_method 并返回响应（尤其在某些旧版本中可能被忽略或行为异常），但拦截特定恶意 HTTP 方法是完全可行且推荐的防护手段，关键在于把规则放在正确位置、用合适方式实现。
直接限制高危请求方法（推荐用 limit_except）
这是最安全、最符合 Nginx 设计逻辑的方式，专为控制方法访问而设：
location /api/ {
limit_except GET HEAD POST {
deny all;
}
}
这段配置表示：只允许 GET、HEAD、POST 访问 /api/ 路径，其他如 PUT、DELETE、TRACE、OPTIONS、CONNECT 等一律拒绝（返回 405 Method Not Allowed）。
- ✅ 不依赖
if，无运行时隐患 - ✅ 作用于 location 内部，精准控制接口路径
- ✅ 对扫描器常用
DELETE /admin、PUT /shell.php类请求天然有效
全局拦截已知恶意方法（用 if + return，需谨慎 placement）
若需统一拦截某些明显滥用的方法（如 TRACE、TRACK），可在 server 块顶层使用：
if ($request_method ~ ^(TRACE|TRACK|DEBUG|OPTIONS)$) {
return 405;
}
注意：
- 必须放在所有
location块之前，否则可能被跳过 -
OPTIONS虽常用于 CORS 预检，但大量非法OPTIONS扫描也常见，可根据业务决定是否放行 -
TRACE和TRACK是经典 HTTP 协议漏洞载体（如跨站追踪），生产环境应默认禁用
结合方法 + 请求头/路径做增强判断
单纯限制方法不够，攻击者常伪装成 POST 或 GET。可叠加校验：
if ($request_method = POST) {
if ($http_content_type !~ "application/json|application/x-www-form-urlencoded|multipart/form-data") {
return 403;
}
}
这条规则拦截非标准 Content-Type 的 POST 请求——很多自动化工具发包时不设或乱设类型，而合法前端通常明确声明。
补充：为什么不用 deny 或 allow 控制方法？
Nginx 的 allow/deny 只针对 IP，不支持按 HTTP 方法过滤。试图写 deny method DELETE 会报错或无效。必须用 limit_except 或 if + return 组合。
基本上就这些。方法拦截不是越严越好，关键是匹配真实攻击特征：TRACE/TRACK 几乎无正当用途；PUT/DELETE 在无 API 权限体系时极易被滥用；非常规 OPTIONS 扫描则暴露探测行为。
