最有效方式是在server块顶部用if判断$request_method并返回444状态码拦截trace/track，需置于所有location前；api路径中须单独拦截，不依赖limit_except白名单机制。
直接在 server 或 location 块中拦截 TRACE 和 TRACK 方法是最有效的方式，核心是用 if 判断 $request_method 并立即关闭连接——推荐返回 Nginx 特有的 444 状态码，它不发任何响应体，比 405 更彻底，能防止攻击者利用响应内容做进一步分析。
优先在顶层 server 块中拦截（防绕过）
把规则放在 server 块最上方，确保所有请求都先经过这一关，避免被后续 location 配置绕过：
- 使用正则精确匹配，避免误伤：
if ($request_method ~ ^(TRACE|TRACK)$) { return 444; } - 该语句对
$request_method是 Nginx 官方明确允许的 if 用法，安全可靠 - 必须放在所有
location块之前，才能覆盖全部路径
在 API 路径中额外加固（兼顾 CORS）
/api/ 类路径虽需放行 OPTIONS，但绝不能放松对高危方法的控制：
- 单独为 TRACE/TRACK 写拦截规则，不依赖白名单逻辑，防止漏放：
if ($request_method = TRACE) { return 444; } - OPTIONS 请求要正常响应并带 CORS 头，但不能因此让 TRACE 也“搭便车”通过
- PUT、DELETE 等方法若业务不用，也建议一并拦截，例如：
if ($request_method ~ ^(PUT|DELETE|CONNECT)$) { return 444; }
不推荐仅靠 limit_except 拦截高危方法
limit_except 是白名单机制，适合主站入口统一限制 GET/HEAD/POST，但它对 TRACE/TRACK 的拦截是间接的（靠“不在白名单里”触发 405）。而实际攻击往往利用这些方法的特殊行为（如 XST），需要更主动、更干净的阻断：
- 444 状态码直接断连，不留响应痕迹，防御更扎实
- TRACE/TRACK 不应出现在任何业务流程中，没必要等它走到 limit_except 才拒绝
- 把它们和普通非法方法区分开，单独强拦，体现风险分级意识
不复杂但容易忽略：只要加一行 if + return 444，就能消除一大类跨站追踪风险。关键是位置要对、写法要准、别让它被其他配置覆盖。
