Nginx负载均衡最核心做法是proxy_pass指向upstream名称，upstream必须定义在http块内、不能嵌套于server或location中，proxy_pass后必须为http://+已定义名称，斜杠影响路径重写，且需透传Host、X-Real-IP等关键请求头。
直接用 proxy_pass 指向 upstream 名称，是 Nginx 实现负载均衡最核心、最标准的做法。关键不在于 proxy_pass 本身多复杂，而在于它必须和 upstream 块配合使用，且写法不能出错。
upstream 必须定义在 http 块内
所有 upstream 定义都要放在 http{...} 大括号里，不能嵌套在 server 或 location 中。例如：
upstream my_app { server 192.168.1.10:8080; server 192.168.1.11:8080; }- 每台后端服务器可加
weight=2、max_fails=3、fail_timeout=30s等参数控制调度行为 - 支持多种调度策略：默认轮询、
least_conn（最少连接）、ip_hash（会话保持）等，需写在 upstream 开头
proxy_pass 必须用 http:// + upstream 名
在 server 的 location 块中，proxy_pass 后面只能是 http://xxx 形式，且 xxx 必须是前面定义的 upstream 名，不能是 IP 或域名：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- ✅ 正确：
proxy_pass http://my_app; - ❌ 错误：
proxy_pass http://192.168.1.10:8080;—— 这样就绕过了 upstream，权重、健康检查全失效 - ❌ 错误：
proxy_pass https://my_app;—— upstream 默认只支持 HTTP 后端，https 需额外配置或由后端处理
路径拼接规则影响实际转发地址
proxy_pass 后是否带斜杠 /，会决定请求路径如何重写：
-
location /api/ { proxy_pass http://my_app/; }→ 去掉/api/，把剩余路径（如user/list）拼到http://my_app/后，变成http://my_app/user/list -
location /api/ { proxy_pass http://my_app; }→ 把完整匹配路径（/api/user/list）原样拼过去，变成http://my_app/api/user/list - 务必保持前后斜杠一致，否则后端可能收不到预期路径
别忘了透传关键请求头
后端要拿到真实客户端信息，必须显式设置 header：
-
proxy_set_header Host $host;—— 保证后端知道原始访问域名 -
proxy_set_header X-Real-IP $remote_addr;—— 传递真实客户端 IP -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 支持多层代理时追加 IP 链 - 漏掉这些，后端日志和权限判断很可能出错
