在多台服务器部署相同Web应用后，如何让外部请求合理分散到各个节点，是运维中常见的现实问题。宝塔面板集成了Nginx管理界面，配合 upstream 模块可以较低门槛实现这一能力。下面先说明基础结构，再给出具体配置过程。
一、理解 Nginx upstream 的工作方式
Nginx 的 upstream 模块属于上游服务器组定义，它把多个后端地址归为一个逻辑集群。当某个站点或反向代理规则引用这个集群时，Nginx 就会按照设定算法，把客户端请求依次或按权重分配给不同后端。这种方式属于七层（HTTP）负载均衡，能够感知域名、路径等请求特征。
在默认编译的 Nginx 中，upstream 模块通常已内置，不需要额外安装。宝塔面板使用的 Nginx 也包含该模块，我们可以直接在配置文件中声明 upstream 块。需要注意的是，upstream 块必须写在 http 上下文内，而不能放在 server 或 location 中。它的存在让后端扩容变得简单，新增节点只需在列表中加一行 server 配置。
1.1 常见分发算法
最基础的算法是轮询（round robin），每个请求按时间顺序逐一分配到不同后端。若某台机器性能更强，可使用权重（weight）模式，给高配机器分配更大比例流量。此外还有 ip_hash，根据客户端IP做哈希绑定，适合有会话保持需求的场景，但节点变动会导致部分用户重新分布。
下面的表格列出几种方式的差异：
| 算法 | 配置关键词 | 适用情况 |
|---|---|---|
| 轮询 | 默认不写 | 后端完全同构，无状态服务 |
| 权重 | weight=数字 | 机器配置不均，需按比例分流 |
| IP哈希 | ip_hash | 需要会话粘性，如未外接Redis |
二、在宝塔面板中添加 upstream 配置
宝塔并没有给 upstream 单独的可视化表单，但我们可以通过修改 Nginx 主配置或站点配置来实现。最稳妥的做法是在宝塔的“软件商店-Nginx-配置修改”中，于 http 段落末尾加入 upstream 定义，这样所有站点都能引用。
假设我们有两台后端，内网地址分别是 192.168.0.10:8080 和 192.168.0.11:8080，希望权重分别为 2 和 1，可以这样写：
http {
# 其他默认配置省略
upstream my_backend {
server 192.168.0.10:8080 weight=2;
server 192.168.0.11:8080 weight=1;
}
}
保存后点击“重载配置”，若语法无误即生效。此后在任何站点的反向代理或 location 中，使用 proxy_pass 指向 http://my_backend 即可。注意 upstream 名称不要带下划线以外的特殊符号，避免解析异常。
2.1 在站点中引用集群
进入宝塔对应站点的“设置-反向代理”，添加一条代理，目标URL填写 http://my_backend。若手动编辑站点 conf 文件，则写成如下形式：
server {
listen 80;
server_name example.ipipp.com;
location / {
proxy_pass http://my_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
其中 X-Real-IP 与 X-Forwarded-For 头部用于让后端拿到真实客户端地址，否则后端日志只会记录 Nginx 机器的IP。对于使用 PHP 的应用，还需要在后端代码或 Web 服务中信任这些头部，否则获取到的仍是代理层地址。
三、健康检查与容错处理
原生 Nginx 免费版的 upstream 不具备主动健康检查，它依赖被动失败计数：当某后端连续出错，会被暂时剔除。我们可以用 max_fails 与 fail_timeout 控制这一行为。
例如下面配置表示在 30 秒内若某节点失败 3 次，则暂停转发该节点 30 秒：
upstream my_backend {
server 192.168.0.10:8080 weight=2 max_fails=3 fail_timeout=30s;
server 192.168.0.11:8080 weight=1 max_fails=3 fail_timeout=30s;
}
如果业务对可用性要求极高，可考虑安装宝塔应用商店中的 Nginx 付费版或编译带 health_check 的模块。但在多数内部系统里，被动剔除加上后端进程守护已经足够。另外建议配合监控脚本，在节点完全离线时报警，避免所有流量压到剩余机器。
3.1 获取真实IP的补充设置
当请求经过 Nginx 负载均衡再到后端 Apache 或 Tomcat 时，后端若直接用 <remote_addr> 概念读取，会得到 Nginx 的内网IP。除了上面设置的头部，后端服务也要做对应解析。以 Tomcat 为例，可在 server.xml 的 Valve 中开启 RemoteIpValve，将 X-Forwarded-For 作为真实来源。
这一步常被忽略，导致限流、审计功能失效。因此在负载均衡搭好后，务必抽测后端接收到的客户端地址是否符合预期，而不是仅看页面能否打开。
四、完整示例与验证方法
把前述内容组合，一个最小可用的负载均衡配置如下。我们在宝塔 Nginx 主配置 http 块加入 upstream，在站点配置使用 proxy_pass，并带齐头部。
# 主配置 http 内
upstream app_cluster {
server 192.168.0.10:8080 weight=2;
server 192.168.0.11:8080 weight=1;
}
# 站点配置
server {
listen 80;
server_name demo.ipipp.com;
location / {
proxy_pass http://app_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_connect_timeout 5s;
proxy_read_timeout 30s;
}
}
验证时，可分别在两台后端放置显示自身IP或主机名的测试页，然后多次访问域名，观察返回内容是否交替出现。也可使用 curl 批量请求统计分布比例，确认权重生效。若发现始终只打到一台，检查 upstream 名称拼写与 proxy_pass 是否遗漏了 http:// 前缀。
通过宝塔面板配合 Nginx upstream，普通运维人员也能在十分钟内完成基础负载均衡。后续若节点扩容，只要改 upstream 列表并重载，无需中断整体服务。
宝塔面板Nginx_upstream负载均衡修改时间：2026-08-09 00:09:32