站点流量涨上来之后，单台服务器早晚会到瓶颈。加配置（垂直扩容）有上限，而且贵；更通用的办法是再加一台雨云云服务器，前面放一个 Nginx 做负载均衡（水平扩容）。这篇文章把搭建过程、限流配置和几个容易踩的坑都记下来，照着做基本能跑通。
一、为什么在雨云上做负载均衡
雨云的云服务器按量计费、开机即用，临时加一台做流量分流很方便。它的几个国内节点（浙江宁波、广东深圳、湖北、江苏宿迁、重庆）之间内网互通，做集群时内网流量不花钱，这点对成本很友好。新购用优惠码 admin01 走专属入口 https://www.jiyueip.com/link/5617 能拿到五折左右的价格，小规模集群试错成本不高。
二、准备工作
- 两台雨云云服务器（建议同节点，方便走内网），系统 Ubuntu 22.04；
- 一台作为负载均衡入口（Nginx），另两台作为应用节点；
- 域名一个，已解析到入口服务器公网 IP；
- 入口服务器开放 80/443，应用节点只开放内网端口。
三、Nginx upstream 与负载策略
在入口服务器的 /etc/nginx/conf.d/upstream.conf 里定义后端池：
upstream app_pool {
server 10.0.0.11:8080 weight=3;
server 10.0.0.12:8080 weight=2;
}weight 是权重，上面这台分 3 份流量、那台分 2 份，适合两台配置不一样的情况。其它常用策略如下：
| 策略 | 配置 | 适用场景 |
|---|---|---|
| 轮询（默认） | 不写 weight | 后端性能一致 |
| 加权轮询 | weight=N | 配置不均 |
| ip_hash | ip_hash; | 需要会话保持 |
| least_conn | least_conn; | 请求耗时差异大 |
四、会话保持
如果业务用 session 存登录态，用户第一次打到 A 节点、第二次打到 B 节点就会掉登录。两种解法：
- ip_hash：按客户端 IP 算哈希，同一 IP 固定落同一节点。配置简单，但用户换网络（4G 切 WiFi）会漂移。
- sticky 模块：在 cookie 里种一个标识，精确绑定。需要 Nginx Plus 或自行编译 sticky 模块，社区版得自己加。
更干净的做法是把 session 外置到 Redis，后端无状态，负载均衡随便怎么切都不影响。具体配置我们在雨云 WordPress 优化那篇会展开。
五、限流配置
负载均衡挡在前面，顺手把恶意刷量和突发流量也拦了。Nginx 两个模块够用：
limit_req 限制请求速率
http {
limit_req_zone $binary_remote_addr zone=reqzone:10m rate=10r/s;
server {
location / {
limit_req zone=reqzone burst=20 nodelay;
}
}
}rate=10r/s 是单 IP 每秒 10 个请求，burst=20 允许突发 20 个排队。nodelay 表示突发不延迟直接放，超了就返回 503。
limit_conn 限制并发连接
limit_conn_zone $binary_remote_addr zone=connzone:10m; limit_conn connzone 50;
单 IP 最多 50 个并发连接，防止单点把连接数打满。
六、健康检查与故障剔除
默认 Nginx 在节点连不上时才摘掉，且没有主动探活。用 max_fails 和 fail_timeout 做被动检查：
server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
30 秒内失败 3 次就踢出 30 秒。想要主动探活得用 nginx-plus 或 nginx-upsync-module，社区方案可以配合 Consul 做服务发现。
七、用雨云内网带宽省成本
入口服务器用公网接收用户请求，转发给应用节点走雨云内网 IP（10.0.0.x 段），这部分流量不计费。所以带宽钱只花在入口那台，后端横向加机器几乎不增加流量成本。节点跨可用区的话注意内网是否互通，同节点最稳。
八、几个踩过的坑
- upstream 名字别带下划线，老版本 Nginx 解析会报错；
- limit_req_zone 必须放在 http 块，放 server 里无效；
- 改完先
nginx -t校验再systemctl reload nginx，别直接 restart 打断连接； - 防火墙只放行入口公网 IP，应用节点锁内网，减少被扫描风险。
常见问题
关于雨云负载均衡的部署细节，下面整理几个常被问到的点。
