宝塔不支持多节点负载均衡，必须手动在nginx.conf的http块内定义upstream，站点配置中proxy_pass需指向该名称并配合proxy_next_upstream等参数实现故障转移与会话保持。
upstream 必须手动写，宝塔界面不支持多节点负载均衡配置——所有「反向代理」功能仅支持单目标，想分发到多台服务器，绕不开手写 upstream 块。
upstream 块必须放在 http 块内，不能塞进 server 或 location 里
很多用户把 upstream 直接写在站点配置文件（如 /www/server/panel/vhost/nginx/your-site.conf）的 server { } 里面，重启后消失或报错。这是因为 Nginx 语法强制要求 upstream 只能在 http 块作用域下定义。
正确位置是主配置文件 /www/server/nginx/conf/nginx.conf 中 http { 开头后的第一处空白行（推荐加在所有 include 语句之前），例如：
http {
include mime.types;
default_type application/octet-stream;
upstream backend_cluster {
server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 weight=1 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8081 backup;
}
include /www/server/panel/vhost/nginx/*.conf;
}
- 别写在
server或location内部，否则 Nginx 启动直接失败 - 如果用
include /www/server/nginx/upstream.d/*.conf方式管理，确保该include行确实在http块中，且路径存在、权限可读 - 改完必须执行「重载配置」，不是「重启 Nginx」——后者可能中断连接
proxy_pass 必须指向 upstream 名称，不能写死 IP
写完 upstream backend_cluster，却在站点配置里继续用 proxy_pass http://192.168.1.10:8080;，等于白配。流量根本不会走负载逻辑。
要在站点配置的 location / { 块中，用 proxy_pass 显式引用名称：
location / {
proxy_pass http://backend_cluster;
proxy_set_header Host $host;
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;
}
-
proxy_pass后的地址必须是http://<upstream_name>，名称大小写和拼写要完全一致 -
proxy_set_header Host $host是关键：用$http_host可能带端口或为空，导致后端路由错乱或 HTTPS 跳转失败 - 宝塔自动生成的反向代理规则里可能已有部分
proxy_set_header，务必检查去重，重复设置会触发 Nginx 报错
原生 Nginx 没有主动健康检查，max_fails 只对连接层有效
设了 max_fails=3 fail_timeout=30s，但后端进程崩溃、只监听端口不响应请求，Nginx 仍会持续转发并返回 502 Bad Gateway——因为 max_fails 仅对 connection refused 和超时生效，对 HTTP 层返回 502/503 或卡死无感知。
兜底方案只能靠 proxy_next_upstream 主动跳过异常响应：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
- 这行必须加在
location块里，且在proxy_pass之后 - 它让 Nginx 在遇到指定错误时自动尝试下一个 upstream 节点，但不改变节点状态；故障节点仍会在轮询队列里，只是当前请求被跳过
- 真要实现心跳探测（比如每 3 秒发一次 HEAD 请求校验），得编译
nginx_upstream_check_module，而宝塔默认 Nginx 不含此模块，check interval=3这类写法直接报错
session 一致性要用 ip_hash，别依赖后端自己存 session
如果后端应用没做共享 session（比如 Redis 存储），又没开启会话保持，用户刷新页面就可能跳到另一台机器，导致登录态丢失、购物车清空等。
最简单可靠的方案是在 upstream 块里加 ip_hash;：
upstream backend_cluster {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
-
ip_hash按客户端 IP 哈希，天然绑定单台后端，无需改动应用代码 - 注意：如果用户走的是统一出口 NAT（比如公司宽带、运营商级 NAT），多个真实用户 IP 会被映射成同一个公网 IP，可能导致负载倾斜
- 若需更精细控制（如按 cookie 或 URL 路径），就得上第三方模块或改用应用层网关（如 Spring Cloud Gateway）
upstream 定义和 proxy_pass 引用必须跨文件协同生效，且中间任何一处语法错误（比如少个分号、缩进错位）都会导致整站 502，但宝塔不会高亮提示具体哪一行**。建议每次修改后先运行 nginx -t 手动验证，再点「重载配置」。 
