proxy_pass路径处理逻辑取决于其后是否带uri：不带则原样转发完整路径，带则替换location匹配部分；正则location必须显式指定uri，建议通过proxy_set_header验证实际转发路径。
proxy_pass 的路径处理逻辑，本质就一条：看它后面有没有 URI（即路径部分）。有，就做替换；没有，就原样转发。这个规则看似简单，但 location 配置稍有变化，结果就可能完全不对。
proxy_pass 不带 URI：原样转发
当 proxy_pass 后面只写到域名或 IP+端口，末尾不带 / 或任何路径时，Nginx 会把客户端发起的完整请求路径（包括 location 匹配到的部分）直接拼在后端地址后面。
- 配置示例：
location /api/ {<br> proxy_pass http://127.0.0.1:3000;<br>} - 客户端请求
/api/users?sort=name→ 后端收到http://127.0.0.1:3000/api/users?sort=name - 这种写法适合后端服务本身已支持
/api上下文，不需要 Nginx 剥离前缀
proxy_pass 带 URI：执行路径替换
只要 proxy_pass 后面包含路径（哪怕只是一个 /），Nginx 就会用这个路径去“替换”掉请求 URI 中与 location 匹配的部分。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 配置示例：
location /api/ {<br> proxy_pass http://127.0.0.1:3000/;<br>} - 客户端请求
/api/users?sort=name→ 匹配部分/api/被删掉，剩余users?sort=name拼到/后 → 后端收到http://127.0.0.1:3000/users?sort=name - 若写成
proxy_pass http://127.0.0.1:3000/v1/;，则结果是/v1/users?sort=name - 注意：location 和 proxy_pass 末尾斜杠要对齐，否则容易出现双斜杠或路径粘连（如
/testuser）
正则 location 中必须显式指定 URI
使用 ~ 或 ~* 定义的正则匹配 location，proxy_pass 后不能省略 URI —— 即使只想转发根路径，也得写成 /。
- 错误写法：
location ~ ^/admin/ { proxy_pass http://backend; }→ Nginx 启动失败 - 正确写法：
location ~ ^/admin/ { proxy_pass http://backend/; }或配合 rewrite：rewrite ^/admin/(.*)$ /$1 break;<br>proxy_pass http://backend;
- 正则场景下推荐用 rewrite + break 组合，逻辑更清晰、可控性更强
调试与验证建议
路径转发是否符合预期，光看配置容易误判。上线前建议加一行 header 透传原始请求路径：
- 在 location 块中加入：
proxy_set_header X-Real-URI $request_uri; - 后端服务打印该 header，就能直观看到 Nginx 实际发了什么
- 同时检查日志中 upstream 地址是否含多余斜杠、query 参数是否丢失、路径是否被意外截断
