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 链
• 漏掉这些，后端日志和权限判断很可能出错