应优先使用limit_except指令白名单放行GET、HEAD、POST，其余方法自动返回405；API路径需单独放行OPTIONS支持CORS，同时显式拦截TRACE、TRACK等高危方法。
禁用不安全的 HTTP 方法（如 TRACE、DELETE、PUT、TRACK）是 Nginx 安全加固中最基础也最关键的一步。核心原则就一条：只放行业务真正需要的方法，其余一律拦截。最推荐的做法不是靠“黑名单”逐个堵，而是用白名单方式明确允许 GET、HEAD、POST —— 这样既简洁，又防绕过，还符合 HTTP 规范。
用 limit_except 严格限定方法（主入口首选）
这是官方推荐、语义清晰、性能稳定的方式，适合放在 location / 中作为默认策略：
- 写在根路径 location 块内，能覆盖所有未被其他 location 显式接管的请求，避免路径绕过
- 只允许 GET、HEAD、POST，其余方法（包括 OPTIONS、TRACE、DELETE、PUT、PATCH、CONNECT 等）自动返回 405 Not Allowed
- 如果确定不需要 HEAD（例如纯 JSON API），可精简为
limit_except GET POST { deny all; } - 示例配置：
limit_except GET HEAD POST {
deny all;
}
proxy_pass http://backend;
}
API 场景下单独处理 OPTIONS（兼顾 CORS）
浏览器发起跨域请求前会先发 OPTIONS 预检，若全局禁用 OPTIONS，前端将直接失败。这时不能一刀切，需分路径精细化控制：
- 主站或静态资源路径（如
/、/assets/）仍用limit_except严格限制 - API 路径（如
/api/、/v1/）应显式放行 OPTIONS，并返回必要 CORS 头 - 同时对 TRACE、TRACK 等高危方法做额外拦截，哪怕在 API 路径里也不许通过
- 示例片段：
if ($request_method = TRACE) { return 405; }
if ($request_method = TRACK) { return 405; }
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-Length 0;
return 204;
}
proxy_pass http://api_backend;
}
全局统一拦截（简单场景可用）
若服务结构简单、无特殊子路径逻辑，可在 server 块顶层使用 if + return 快速统一控制：
- 匹配不在白名单中的请求方法，直接返回 405 或更彻底的 444（静默关闭连接）
-
$request_method在 server 级使用是安全且常见的，Nginx 官方对此无限制 - 正则务必加锚点
^和$，避免误匹配（例如防止 POSTXXX 被当成 POST） - 示例：
return 405;
}
验证是否生效（上线前必做）
配置 reload 后必须实测，不能只看语法检查通过：
- 用 curl 检查被禁方法是否返回预期状态码：
curl -X TRACE https://yoursite.com/ -I应得 405；curl -X DELETE https://yoursite.com/ -I同理 - 确认业务功能不受影响：特别是表单提交（POST）、页面加载（GET）、健康检查（HEAD）是否正常
- 若用了 CORS，确保预检请求（OPTIONS）能成功返回 204 或 200，并带齐 Access-Control-* 头
