Nginx请求处理分三步：先由listen套接字筛选server块，再按=、^~、~、/优先级匹配location，最后执行server和location中rewrite指令；server层rewrite会改变URI影响location匹配，需用add_header或return快速验证路径是否正确命中。
排查 Nginx 中 server 块与 location 块的重写冲突，核心不是看配置写了多少行，而是搞清请求实际走哪条路径——server 先选对，location 再匹配准，rewrite 才能按预期执行。很多 404、跳转失效、代理被吞的问题，根源都在这两层路由没对上。
先确认 server 块是否被正确选中
请求连 server 都没进对，后面所有 location 和 rewrite 都白搭。Nginx 不是“找第一个匹配的 server_name”，而是按三步筛选：
- 内核根据 TCP 目的 IP 和端口，把连接分发到对应 listen 套接字上；只有该 listen 下定义的 server 块才参与后续筛选
- 若多个 server 块监听同一端口（如 443），有 SNI 的请求按 server_name 精确或通配符匹配；无 SNI 的请求则落到 default_server，没设就用第一个定义的 server 块
- 检查是否漏了 listen ssl 或 default_server 标识，尤其在多域名 HTTPS 场景下，证书错配、跳转失败常源于此
再验证 location 是否命中预期块
即使 server 对了，location 匹配错也会导致 rewrite 不执行或执行错地方。Nginx 不按书写顺序选 location，而是严格按优先级：
- = 最高：完全相等才生效，比如 location = /health，写在哪都优先
- ^~ 次高：前缀最长即胜出，且匹配后直接终止，不再检查正则（如 location ^~ /static/）
- ~ 和 ~*：按配置文件中出现顺序逐条试，首个命中即停，但前提是前面 = 和 ^~ 都没匹配上
- / 最低：兜底，仅当以上全不满足时才用
典型陷阱：location ~ \.js$ 放在 location ^~ /api/ 后面，看似“靠后”，但 /api/static/app.js 实际仍进 ^~ 块——因为 ^~ 一旦匹配成功就不看正则；而 /admin/index.js 却可能被正则劫持，若里面没配 root 或 proxy_pass 就 404。
定位 rewrite 执行位置是否合理
rewrite 指令可出现在 server 或 location 块中，执行顺序固定：
- 先执行 server 块里的 rewrite（如果存在）
- 再做 location 匹配
- 最后执行选中的 location 块内的 rewrite
这意味着：server 层 rewrite 改变 URI 后，会影响后续 location 匹配结果；而 location 内 rewrite 一般用于内部重定向或 URL 标准化。常见问题包括：
- 在 server 块里写了 rewrite ^/(.*)$ /new/$1 break;，结果所有请求都被改写，导致 location /api/ 根本没机会匹配
- location /old/ { rewrite ^/old/(.*)$ /new/$1 permanent; } 正确；但若写成 location / { rewrite ^/old/(.*)$ /new/$1 permanent; }，就可能误伤其他路径
- 用了 last、break、redirect、permanent 四种 flag，需注意 last 会重新匹配 location，break 则终止 rewrite 并继续当前 location 流程
用最小成本快速验证修改效果
别每次 reload 全局配置，先局部验证逻辑是否通：
- 在待测 location 块里临时加 add_header X-Debug "in-api-block";，curl -I 看响应头是否出现
- 用 return 200 "matched"; 替代 rewrite，确认请求确实进了这个块
- 启用 debug 日志：http 块加 error_log /var/log/nginx/debug.log debug;，查日志中 matched location: 和 rewrite: 行，看清每一步真实行为
不复杂但容易忽略
