proxy_pass路径适配关键在于浏览器请求路径、Nginx转发路径、后端监听路径三者对齐；location尾斜杠决定匹配类型（/api/更安全），proxy_pass尾斜杠决定路径是否被截断（带斜杠才可映射到后端根路径），正则匹配需显式指定URI，rewrite配合break用于路径改写。
proxy_pass 适配前后端路径不一致，关键不是“加减前缀”，而是让三者对齐：浏览器请求路径、Nginx 转发路径、后端实际监听路径。错一个斜杠或少一个 break，接口就 404。
看 location 尾部斜杠：决定谁能进这个块
location 写法先框定匹配范围，这是第一道门槛：
- /api（无尾斜杠）→ 前缀匹配：/api、/api/users、/apixxx 都会进来，容易误伤
- /api/（有尾斜杠）→ 目录匹配：只认 /api/ 开头的路径，如 /api/users、/api/v2/，不匹配 /api 或 /apixxx
生产环境强烈建议用 /api/ 这种写法，避免歧义。
看 proxy_pass 末尾斜杠：决定后端收到什么路径
这才是真正影响后端能否找到路由的动作：
- proxy_pass http://backend;（无斜杠）→ 原样转发：请求 /api/users → 后端收到 /api/users
- proxy_pass http://backend/;（有斜杠）→ 前缀替换：请求 /api/users → 后端收到 /users
绝大多数前后端分离项目，后端监听根路径（比如 /users），所以必须用带斜杠的写法，否则后端根本没这条路由。
正则或精确匹配时，proxy_pass 必须显式带路径
location 用了 =、~ 或 ~*，Nginx 就无法自动推导要截哪一段，必须手动指定目标 URI：
- ❌ 错误：
location ~ ^/static/(.+)$ { proxy_pass http://cdn; }（启动失败） - ✅ 正确：
location ~ ^/static/(.+)$ { proxy_pass http://cdn/$1; } - ✅ 精确跳转：
location = /health { proxy_pass http://backend/health; }
需要改写路径时，rewrite 是 proxy_pass 的搭档
默认替换逻辑不够用？比如要把 /v2/api/users 映射成 /api/v2/users，就得靠 rewrite：
- 先重写 URI：
rewrite ^/v2/api/(.*)$ /api/v2/$1 break; - 再交给 proxy_pass：
proxy_pass http://backend; - 一定要加 break，防止 rewrite 后再次匹配其他 location
微前端场景更典型：子应用 context-path 是 /app-order，但浏览器请求的是 /app-order/api/user，Nginx 应该剥离前缀再透传：
location /app-order/ { rewrite ^/app-order/(.*)$ /$1 break; proxy_pass http://sub-app:8080/; }
