最有效的方式是用HTTP方法白名单，只放行GET、HEAD、POST、OPTIONS，其余一律返回405；需在server块顶部用正则限定，优先拦截TRACE/TRACK返回444，并配合Host头校验与请求头大小限制。
最有效的方式是用 HTTP 方法白名单，只放行业务真正需要的标准方法，其余一律拒绝。
只允许已知安全的 HTTP 方法
在 server 或关键 location 块顶部，用正则明确限定可通行的方法：
if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }- 这会放行 GET、HEAD、POST 和 OPTIONS（CORS 预检必需），其他如 PUT、DELETE、PATCH、DEBUG、PROPFIND、MERGE、X-ADMIN 等全部返回 405
- 若业务确实要用 PATCH 或 PUT，必须显式加进括号里，不能默认开放
- 避免用
deny PUT;这类黑名单写法——它无法覆盖任意拼写的自定义方法（比如 FOO、BAR）
单独强制关闭 TRACE 和 TRACK
这两个方法有严重安全隐患，即使不在白名单里，也建议优先拦截：
if ($request_method ~ ^(TRACE|TRACK)$) { return 444; }- 放在白名单规则之前，确保优先生效
- 444 是 Nginx 特有状态码，直接断开 TCP 连接，不返回任何响应体，比 405 更彻底
配合 Host 头与请求头规范校验
仅拦方法不够，攻击常搭配伪造 Host 或畸形头部发起：
- 配置
default_server拦截空 Host、IP 直连、下划线域名等非法 Host 请求 - 限制请求头大小：
client_header_buffer_size 1k;和large_client_header_buffers 2 2k;，防止超长自定义方法藏在异常头部中 - 可选补充 UA 指纹识别，如匹配
sqlmap、gobuster等扫描器标识，命中即return 403
注意执行位置和变量可靠性
这些规则必须写在 server 块顶层，不能嵌套在 location 内：
-
$request_method是 Nginx 解析请求行后生成的变量，稳定可靠 - 不要在 location 中写 if 匹配方法——Nginx 官方不推荐，逻辑易被覆盖或跳过
- 确保没有
error_page 405覆盖默认行为，让状态码真实返回便于审计
