Python Web应用负载均衡方案_结合Nginx权重设置实现高可用

Nginx upstream 权重未生效，主因是未启用加权轮询策略、存在 ip_hash 等冲突指令、weight 参数缺失或 Nginx 版本过低（需 ≥1.9.1）；务必验证配置语法、检查健康检查设置及后端响应。nginx upstream 配置权重时，后端服务没按预期分流？权重没生效，大概率是 upstream 模块没用对策略。Nginx 默认是轮询（round-robin），不是加权轮询——必须显式启用 least_conn 或确认没被其他指令覆盖。确保 upstream 块里每个 server 行都带 weight= 参数，比如 server 127.0.0.1:8001 weight=3;删掉配置中可能存在的 ip_hash 或 hash $request_uri，它们会强制绑定会话，让权重失效检查 Nginx 版本：1.9.1+ 才对 weight 在非 ip_hash 场景下稳定支持；老版本即使写了 weight 也可能降级为均等轮询reload 后用 nginx -t 验证语法，再 curl -I http://your-domain/health 多次，观察响应头里的 X-Backend（可自定义）或日志中的上游 IP 分布Python Web 应用（Flask/FastAPI）如何识别真实客户端 IP？Nginx 作为反向代理时，默认把请求发给后端的 Remote-Addr 是它自己的 IP，Python 框架拿不到真实用户 IP——这不是框架问题，是代理链没透传。在 Nginx 的 location 块里加这三行：proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;、proxy_set_header X-Forwarded-Proto $scheme;FastAPI 用 request.client.host 仍可能不准，得读 request.headers.get("x-real-ip")；Flask 同理，别依赖 request.remote_addr如果用了云 WAF 或 CDN，X-Forwarded-For 可能含多个 IP，取最左边第一个（但要校验可信跳数），不建议直接信任整个字段多个 Gunicorn 进程 + Nginx 负载均衡，为什么 CPU 利用率不均衡？看起来分了流量，但某个 Python 实例 CPU 突高，其他闲着——常见于长连接、同步阻塞 I/O 或 Gunicorn worker 类型没配对。确认 Gunicorn 启动参数：Websocket 或高并发场景必须用 --worker-class eventlet 或 --worker-class gevent，默认的 sync 类型会让一个 worker 卡住就拖慢整条 upstreamNginx 的 keepalive 连接池大小（keepalive 32;）要和 Gunicorn 的 --workers 数量匹配，否则连接复用集中在少数 backend 上检查 Python 应用里有没有全局锁（如 threading.Lock()）、文件读写、或未异步化的数据库查询——这些不会被负载均衡“摊薄”，只会在单个进程内堆积健康检查失败导致 upstream 服务被踢出，但应用明明还活着502 Bad Gateway 频发，看 Nginx error.log 发现 “no live upstreams”，但 curl http://127.0.0.1:8001/health 明明返回 200——问题常出在健康检查路径或超时设置上。 arXiv Xplorer ArXiv 语义搜索引擎，帮您快速轻松的查找，保存和下载arXiv文章。