应通过 debug 日志确认请求实际匹配的 location 块，而非依赖配置顺序；正则需加锚定或配合 ^~ 避免误匹配；修改后用 add_header 或 return 快速验证。
排查 location 正则匹配冲突，关键不是“看配置写了啥”，而是“看请求实际进了哪个块”。Nginx 不按你写的顺序执行，而按四层硬性优先级选唯一匹配——一旦配错，静态资源 404、API 被吞、JS 文件下载源码，全都是它在背后悄悄劫持。
确认目标请求命中了哪个 location
别猜，直接看日志。Nginx 默认不记录匹配路径，需临时启用 debug 级别：
- 在 http 块外、events 块上方 加一行：
error_log /var/log/nginx/debug.log debug; - 确认 nginx 编译时含
--with-debug（运行nginx -V 2>&1 | grep debug检查） - 发一次请求，查
/var/log/nginx/debug.log，搜索 “matched location:”，会明确写出生效的块，比如：matched location: ~ \.js$或matched location: ^~ /api/
检查正则是否过度宽泛，误伤代理或动态路径
典型陷阱是这类写法：location ~ \.js$ 或 location ~ .*\.(js|css)$。它不挑路径，只要 URL 以 .js 结尾就进——哪怕你是访问 /prod-api/v2/data.js，也会被这个正则拦下，而它里面若只写了 expires 却没 proxy_pass 或 root，结果就是 404。
- 把正则加边界锚定：
location ~ ^/[^?#]*\.js$（只匹配路径部分，排除 query） - 排除代理前缀：
location ~ ^/(?!prod-api/).*\.js$（用负向先行断言跳过 /prod-api 下的 JS） - 更稳妥：把代理路径改用
^~，例如location ^~ /prod-api/ { proxy_pass http://backend; }，这样一旦匹配，正则根本不会被执行
核对 location 书写顺序与修饰符层级
正则块（~ 或 ~*）本身不靠位置优先，但它的“出场机会”受前面 ^~ 和 = 严格限制：
-
^~ /static/后面如果还写了location ~ \.png$，那/static/logo.png永远进不了 PNG 块——因为^~匹配成功就终止了正则扫描 -
location = /health必须放在最前或至少早于location /，否则会被兜底块吞掉 -
location ~ \.php$应放在所有^~块之后、location /之前；若业务允许 /admin/index.php 运行 PHP，就不能对 /admin 用^~，得换成普通前缀或拆出专用正则
用最小代价验证修改是否生效
改完别急着 reload 全局，先快速验证逻辑通不通：
- 在待测 location 块里临时加：
add_header X-Location "php-handler";或return 200 "in php block"; - 用
curl -I http://your-domain/test.php看响应头或状态码 - 或者打开
error_log /var/log/nginx/error.log notice;，再请求一次，日志会写明“matched location: ~ \.php$” - 注意：
nginx -t只验语法，用nginx -T才能看到 include 合并后的真实生效配置
