必须先在http块中定义upstream服务器组，再在location中通过proxy_pass http://upstream_name调用；需注意uri处理（带/则剥离路径前缀）、设置必要请求头及超时参数，并用nginx -t验证语法。
配置 proxy_pass 指向后端服务组，核心在于先定义 upstream 块，再在 location 中调用。它不是简单写个地址，而是涉及路由匹配、健康检查、负载策略等实际运维关键点。
定义 upstream 服务组
后端服务器不能直接写在 proxy_pass 里，必须提前在 http 块中声明 upstream：
- 名称要简洁唯一，比如
my_backend，后续proxy_pass就引用这个名称 - 支持多种负载策略：默认轮询（
round-robin）、加权轮询（weight=3）、IP哈希（ip_hash）保证会话粘性 - 可添加健康检查参数：
max_fails=3表示连续失败3次就标记为不可用，fail_timeout=30s表示30秒内不发新请求 - 示例：
upstream my_backend {
server 192.168.1.10:8080 weight=2;
server 192.168.1.11:8080 max_fails=2 fail_timeout=10s;
server 192.168.1.12:8080 backup;
}
location 中正确使用 proxy_pass
proxy_pass 的值必须与 upstream 名称一致，且注意 URI 处理细节：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 如果
location是精确匹配（如location /api/），proxy_pass后面的 URI 末尾带斜杠，Nginx 会自动剥离前缀再转发；例如proxy_pass http://my_backend/;，请求/api/user会转为/user - 如果末尾不带斜杠（如
proxy_pass http://my_backend），则整个原始 URI（包括/api/）原样转发过去 - 避免混用路径重写和
proxy_pass：若需改写路径，优先用rewrite+break，而不是靠proxy_pass的斜杠逻辑“凑巧”实现
补充必要代理头与超时设置
只配 proxy_pass 往往不够，后端服务常依赖真实客户端信息：
- 必须设置
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;，否则后端可能拿不到原始域名或IP - 动态接口通常响应较慢，建议调大超时：
proxy_connect_timeout 10s;、proxy_send_timeout 60s;、proxy_read_timeout 60s; - 若后端是 HTTPS，Nginx 需启用 SSL 透传或终止，此时还需配置
proxy_ssl_*系列指令
验证与常见问题排查
配置生效后，别跳过基础验证步骤：
- 用
nginx -t检查语法，避免 reload 失败 - 访问对应路径，用
curl -I查看响应头中的Server或X-Upstream（如有自定义）确认是否真走到了后端 - 查看
error.log，502 错误大概率是后端不可达或超时，而非 Nginx 配置本身错误 - 注意 SELinux 或防火墙是否拦截了 Nginx 到后端端口的连接（尤其 CentOS/RHEL 环境）
