最稳妥的方式是白名单放行+显式拦截补充，即用limit_except限定get、head、post，其余方法返回405并带allow头；api路径需单独允许options以支持cors，同时拦截trace/put/delete等高危方法。
直接在 server 块里禁用 TRACE（以及 PUT、DELETE、TRACK 等非标准或高危方法），最稳妥的方式不是“逐个堵”，而是白名单放行 + 显式拦截补充。核心目标是：只让业务真正需要的方法通过，其余一律拒绝，并返回符合 HTTP 语义的响应。
用 limit_except 统一限制根路径（推荐主策略）
这是 Nginx 官方推荐、性能好、语义清晰的做法，适合放在 location / 中作为默认兜底：
- 它自动对未明确允许的方法返回
405 Method Not Allowed - 不依赖正则匹配，无性能损耗
- 覆盖所有未被其他
location拦截的请求，防绕过
location / {
limit_except GET HEAD POST {
deny all;
}
proxy_pass http://backend;
}
这样，TRACE、PUT、DELETE、OPTIONS、CONNECT 等全部被拒，连带返回标准 Allow: GET, HEAD, POST 头（需配合 add_header Allow ... always;）。
对 API 路径单独放行 OPTIONS（兼顾 CORS）
/api/ 类路径必须响应浏览器预检请求，不能一刀切禁用 OPTIONS。需分路径处理：
- 显式允许 OPTIONS 并返回 CORS 头
- 同时对 TRACE、TRACK 等高危方法做独立拦截（哪怕在 API 下也不许）
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";
add_header Access-Control-Max-Age 1728000;
return 204;
}
if ($request_method ~ ^(TRACE|TRACK|PUT|DELETE)$) {
return 405;
}
proxy_pass http://api_backend;
}
注意：if 在 location 内是安全的，尤其对 $request_method —— Nginx 官方明确支持该用法。
全局统一拦截（简单站点可选）
如果整个服务结构扁平、无复杂子路径逻辑，可在 server 块顶层用 if 快速控制：
if ($request_method !~ ^(GET|HEAD|POST)$) {
add_header Allow "GET, HEAD, POST" always;
return 405;
}
⚠️ 不建议在 server 块中对 OPTIONS 或 TRACE 单独写 if 放行/拦截，容易和后续 location 冲突；应优先下沉到具体 location 中精细化管理。
补充：确保响应头正确体现允许方法
无论用哪种方式，都建议显式声明 Allow 头，帮助客户端理解接口契约：
add_header Allow "GET, HEAD, POST" always;
加在 server 或 location 块内均可，always 参数确保即使返回 405 也会带上该头。
不复杂但容易忽略。
