Nginx正则location冲突源于匹配优先级误判，实际按=、^~、~/~*、/四层严格选唯一匹配；宽泛正则如\.js$易劫持代理路径致404，需用debug日志定位生效块、加路径前缀收敛作用域，并借助nginxconfig.io等工具预检。
正则 location 冲突是 Nginx 配置中最隐蔽也最常导致 404、静态资源丢失或代理失效的问题。根源不在于写错了语法，而在于没意识到某条看似“只管后缀”的正则，实际劫持了本该走代理或本地文件的请求。
看清匹配优先级顺序，别被“写在前面”骗了
Nginx 不按配置顺序执行，而是严格按四层优先级选唯一匹配块：
-
精确匹配（=）：如
location = /health，完全一致才生效，最高优先 -
前缀匹配（^~）：如
location ^~ /api/，匹配最长前缀后直接终止，跳过所有正则 -
正则匹配（~ 或 ~*）：按配置文件中出现顺序逐条试，首个命中即停，优先级高于普通前缀（如
location /prod-api/） -
普通前缀（无修饰符）：如
location /，仅当以上全不匹配时兜底
关键点：哪怕你把 location /prod-api/ { proxy_pass ... } 写在最上面，只要下面有 location ~ \.js$，且请求路径含 .js（比如 /prod-api/static/app.js），就会进正则块——而它若没配 proxy_pass 或 root，就直接 404。
快速定位哪条正则实际生效了
别猜，用 debug 日志看真实路由决策：
- 确认 Nginx 编译含
--with-debug（运行nginx -V 2>&1 | grep debug） - 在
http块里加：error_log /var/log/nginx/debug.log debug; - 重载配置：
nginx -t && nginx -s reload - 发一次出问题的请求，再执行：
tail -n 50 /var/log/nginx/debug.log | grep "using configuration"
日志里会明确写出类似 using configuration "/static/" 或 using configuration "~ \.css$"，一眼锁定真实命中的 location 块。
收敛正则作用域，避免“一把抓”
像 location ~ \.js$ 这类宽泛正则极易误伤，应限制其适用范围：
- 加路径前缀限定：用
location ~ ^/static/.*\.js$替代location ~ \.js$ - 改用
^~优先处理已知静态目录：location ^~ /static/ { root /var/www; }，这样即使后面有正则，也不会再检查 - 对必须用正则的场景，把更具体的规则写在前面：
先写location ~ ^/api/v2/.*\.php$，再写通用的location ~ \.php$
用工具做静态预检，防患于未然
人工审配置易漏，推荐两个轻量手段：
- nginxconfig.io：粘贴配置，它自动标出潜在冲突（比如正则覆盖了代理路径）
-
curl + 响应头验证：对关键路径发起请求，观察
Server、X-Accel-Redirect或自定义 header 是否符合预期，例如：curl -I http://localhost/prod-api/login看是否返回后端服务的Server: nginx还是Server: Apache
