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 类型没配对。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 确认 Gunicorn 启动参数：Websocket 或高并发场景必须用
--worker-class eventlet或--worker-class gevent，默认的sync类型会让一个 worker 卡住就拖慢整条 upstream - Nginx 的
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——问题常出在健康检查路径或超时设置上。
- 在
upstream块里加主动健康检查：check interval=3 rise=2 fall=3 timeout=1 type=http;，并确保后端/health路由响应极快（ - 避免用
proxy_pass http://upstream_name;直接转发，而要在location里加proxy_next_upstream error timeout http_500;，否则单次超时就中断，不触发重试 - Python 应用启动时，Gunicorn 可能已监听但还没完成初始化（比如 SQLAlchemy 连接池没建好），这时健康检查就容易误判；可在启动脚本里加简单就绪探针等待逻辑
权重、健康检查、真实 IP、worker 模型——这四个点串起来才是可用的负载均衡，漏掉任一环，表面看着分流了，实际流量全压在一个节点上。尤其是 Gunicorn 的 --worker-class 和 Nginx 的 proxy_next_upstream，最容易被当成“高级选项”跳过，结果线上扛不住突发流量。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
