最有效方式是http方法白名单：仅放行get、head、post、options，其余返回405；trace/track单独用444强制断连，并配合host头校验与请求头大小限制。
直接禁止所有非标准 HTTP 方法，是最有效、最彻底的拦截方式。Nginx 本身不解析业务自定义方法，但攻击者常利用未被显式拒绝的非常规方法（如 DEBUG、PROPFIND、MERGE、PATCH 或任意拼写如 X-ADMIN）绕过应用层校验，触发后端未预期的行为或逻辑漏洞。关键不是“识别未知方法”，而是“只放行已知安全方法”。
只允许业务必需的标准方法
在 server 或关键 location 块中，用正则严格限定可通行的方法，其余一律拒绝：
-
推荐写法（明确白名单）：
if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }
——仅放行 GET、HEAD、POST、OPTIONS（若需 CORS 预检），其他全部返回405 Method Not Allowed，语义准确且利于审计。 - 避免使用
deny列举黑名单（如deny PUT; deny DELETE;），因为无法覆盖任意自定义方法（如FOO、BAR）。 - 若业务确需
PATCH或PUT，必须显式加入白名单，不可默认开放。
同步关闭 TRACE 和 TRACK 方法（防 XSS 与信息泄露）
这两个方法极易被用于跨站追踪或响应窃取，即使未在白名单中，也建议单独强化拦截：
-
if ($request_method ~ ^(TRACE|TRACK)$) { return 444; }444是 Nginx 特有状态码，表示“关闭连接不发响应”，比405更彻底，不留任何响应体供分析。 - 该规则应放在白名单判断之前，确保优先生效。
配合 Host 头校验与请求头规范化
自定义方法常伴随伪造 Host 或异常请求头发起，单靠方法限制不够：
- 确保已配置
default_server拦截非法 Host（如 IP 直连、下划线域名、空 Host），防止攻击者绕过域名路由直达后端。 - 限制请求头大小，防止超长自定义方法藏在畸形头部中：
client_header_buffer_size 1k;large_client_header_buffers 2 2k; - 可选：检查
User-Agent或Referer是否含明显扫描器标识（如sqlmap、gobuster），命中即return 403。
验证与注意事项
配置后务必测试，避免误伤合法流量：
- 用
curl -X FOO https://yoursite.com/验证是否返回405或断连（444）； - 确认 OPTIONS 请求仍能正常响应 CORS 预检（若前端依赖）；
- 避免在
http块顶层大量使用if；推荐将方法校验放在server或具体location内，减少运行开销； - 注意：Nginx 的
if在 location 外行为受限，所有方法限制规则请置于server或location块内部。
