location /api 写了普通前缀 正则把请求全截走

location /api 配到旧服务，访问 /api/users 却进了 frontend，后端日志一条没有。乍看像缓存或者权限的锅，追下去往往不是。

location ^~ /api/ {
  proxy_pass http://api_backend;
}
location ~ \.(js|css)$ {
  root /var/www/static;
}

追下去是这么回事：Nginx 先找最长前缀，再按顺序匹配正则，正则一旦命中就用它。location 里的静态资源规则写在前面，会把 /api 的请求先截走。

「location 匹配优先级」这类改动最怕改一半，回滚脚本先准备好，再动生产。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。

线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。

权限不要一口气开到最大，先加到够用再往上试，范围小才好收。

具体做法是，用 nginx -T 看完整配置里 location 的先后顺序；精确匹配用等号 前缀匹配用 ^~ 阻止后面的正则再抢；正则 location 按具体到宽泛排列 不要用根路径兜底在前面；用 curl 打三个路径确认各落到哪个 upstream。

验收就看一点，curl /api/users 的响应来自 api_backend access.log 里对应 upstream 正确。