upstream是nginx实现负载均衡的核心模块，必须定义在http块内，配合proxy_pass使用；支持轮询、weight、ip_hash等5种调度算法，并需合理配置max_fails与fail_timeout实现健康检查。
upstream 是 Nginx 实现负载均衡的核心，不是靠 proxy_pass 单独完成的——它只负责转发，真正决定“发给谁、怎么发”的是 upstream 块。配置错位置、漏写关键指令、或忽略健康检查逻辑，都会导致流量不均、故障不剔除、甚至 502 直接暴露给用户。
upstream 必须定义在 http 块内，且不能嵌套在 server 或 location 里
常见错误是把 upstream 写进 server 块里，Nginx 启动时会报错：nginx: [emerg] "upstream" directive is not allowed here。这是因为 upstream 是全局作用域的模块，只允许出现在 http 块一级。
- 正确位置示例：
http {<br> upstream backend {<br> server 192.168.1.101:8080;<br> server 192.168.1.102:8080;<br> }<br> server {<br> location / {<br> proxy_pass http://backend;<br> }<br> }<br>} -
upstream名称（如backend）必须和proxy_pass中的地址完全一致，大小写敏感 - 如果用了非标准端口（如 8080、9000），
server行必须显式写出端口，不能省略
weight、max_fails、fail_timeout 这三个参数要一起看
单独设 weight=5 不代表服务器真能扛住 5 倍流量——若后端响应慢或频繁超时，没配 max_fails 和 fail_timeout，Nginx 仍会持续发请求过去，最终堆积失败。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合在Linux系统上进行 Python 项目开发、运行、调试和测试。
-
max_fails=3：连续失败 3 次后，标记该节点为不可用 -
fail_timeout=30s：进入不可用状态后，30 秒内不再尝试；30 秒后自动恢复探测 - 两者必须共存才生效，只写一个等于没写
- 示例：
server 192.168.1.101:8080 weight=3 max_fails=3 fail_timeout=30s;
ip_hash 不能和 weight 混用，least_conn 不支持 backup 服务器
看似合理的组合，实际会被 Nginx 忽略或报错。比如 ip_hash 开启后，所有 weight 值失效——哈希只管分发一致性，不考虑权重；而 least_conn 算法本身不识别 backup 标记，写了也白写。
- 需要会话保持 + 权重？改用
hash $remote_addr consistent;（需 nginx ≥ 1.7.2），它支持权重且更稳定 - 要用
backup，只能搭配轮询或加权轮询，不能加ip_hash或least_conn -
keepalive 32;要放在upstream块末尾，它控制的是 Nginx 到后端的长连接池大小，不是客户端连接
proxy_next_upstream 不是“自动重试”，而是失败条件开关
很多人以为加了 proxy_next_upstream error timeout 就万事大吉，其实它只定义“什么情况下才换下一台”，不保证一定能成功。比如后端返回 502，但没在列表里声明 http_502，Nginx 就直接返回 502 给用户，不会重试。
- 常用组合：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 它必须配合
max_fails/fail_timeout才有长期效果；否则只是单次请求重试，下次还可能打到同一台坏机器 - 注意：
proxy_next_upstream默认值是error timeout，不包含任何 HTTP 状态码，这点极易被忽略
upstream 的行为往往取决于最弱的一环：后端响应时间抖动、防火墙临时拦截、甚至 DNS 解析延迟，都可能让 max_fails 在几秒内被刷满。别只盯着配置语法对不对，得拿 curl -v 和 nginx -t 配合 tail -f /var/log/nginx/error.log 看实际调度日志。
