proxy_pass路径映射核心是location尾部斜杠决定匹配范围、proxy_pass末尾斜杠决定路径传递方式：/api/精确目录匹配，proxy_pass http://backend/实现前缀替换，正则匹配时proxy_pass必须显式带路径，路径改写需配合rewrite与break。
proxy_pass 路径映射的核心逻辑，其实就两条：看 location 怎么写、看 proxy_pass 末尾有没有斜杠。这两者一组合，就决定了后端收到的路径长什么样。搞错一个斜杠，接口全 404，不是玄学，是规则。
location 尾部斜杠决定匹配范围
location 的写法先框定请求能进哪个块，这是第一步：
- /api（无尾斜杠）：前缀匹配，会命中 /api、/api/、/api/users、甚至 /apixxx —— 容易误伤
- /api/（有尾斜杠）：目录匹配，只认以 /api/ 开头的路径，比如 /api/users、/api/v2/health，但不匹配 /api 或 /apixxx
生产环境强烈建议用 /api/ 这种写法，避免意外匹配。
proxy_pass 末尾斜杠决定路径怎么传
这才是最关键的物理动作，它管的是“发给后端的 URL 是什么”：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_pass http://backend;（无斜杠）→ 原样追加：请求 /api/users → 后端收到 /api/users
- proxy_pass http://backend/;（有斜杠）→ 前缀替换：请求 /api/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，单靠 proxy_pass 不行：
- 用 rewrite 先重写 URI，再交给 proxy_pass：
location /v2/api/ { rewrite ^/v2/api/(.*)$ /api/v2/$1 break; proxy_pass http://backend; }- 注意加 break，防止 rewrite 后再次匹配其他 location
