【VPS 网络极客与负载均衡 03】多台 VPS 做负载均衡：HAProxy / Nginx 实战与架构思路

很多站长都是从一台 VPS 起步的：装个 LNMP，把网站丢上去，日子过得挺好。直到某天流量上来，CPU 常年飙到 80% 以上；或者更糟，机房抽风、母鸡宕机，整站直接打不开。这时候再想去扩容，已经不是加内存加核就能解决的事——你真正需要的是把流量摊到多台 VPS 上，也就是负载均衡。本文不谈云厂商那套托管负载均衡器，只聊怎么用两台、三台便宜 VPS 自己搭一套高可用架构。

延伸阅读

更多相关攻略推荐：【API 中转 02】ChatGPT/Claude API 中转 V、量化/EA 交易要低延迟：跑外汇机器人该选哪台 VPS？就近机房实测、2026 多语言/多区域 SEO 技术栈：hreflang+CDN 、Tailscale 连上了却卡成狗？自建 DERP/ZeroTier、2026 VPS 选购决策树与白皮书：一张图看懂怎么买。

为什么单机不够用，需要负载均衡

单台 VPS 有三个绕不开的硬伤。第一是性能天花板：共享 vCPU 超售严重，老款 Xeon E5 单核弱，建站类应用（WordPress、PHP、MySQL、TLS 握手）偏偏最吃单核性能，流量一涨就顶不住。第二是单点故障：这台机器挂了，业务全停。第三是无法滚动更新：你想升级程序、换证书，只能停机维护。负载均衡把多台 VPS 编成一组后端，前端用一台机器做流量入口，三件事同时解决——性能横向扩展、坏一台自动摘流、更新可以一台台来不中断服务。

L4 与 L7：先想清楚在哪一层分流

负载均衡按工作层级分两种，选型前必须先想明白：

• 四层（L4，TCP/UDP）：在传输层转发，看不见 HTTP 内容，只认 IP 和端口。速度快、开销小，适合数据库、游戏、任意非 HTTP 协议，HAProxy 的 L4 能力业界公认最强。
• 七层（L7，HTTP/HTTPS）：能解析请求，按 URL、域名、Cookie、Header 路由。可以做内容切换，比如把 /api 分给一组机器、把图片分给另一组。Web 站基本都走 L7。

经验法则：纯 Web 站用 L7；要转发非 HTTP 流量或追求极致吞吐，用 L4。HAProxy 两边都能做，Nginx 通过 stream 模块也能做 L4，但日常大家还是拿它做 L7。

方案选型：HAProxy 还是 Nginx upstream

这是被问得最多的问题。一句话结论：HAProxy 是专为负载均衡而生的纯 LB，Nginx 是顺带能负载均衡的 Web 服务器。下面这张表把关键差异摆清楚。

简单做法：如果你已经是 Nginx 用户、后端不多、要顺手带缓存，直接上 Nginx upstream 最省事。如果你要精确流量控制、做 TCP 转发、要实时看每台机器状态，或者后端有十台以上，上 HAProxy。进阶玩法是两个都用——Nginx 放边缘做 SSL 终结和缓存，HAProxy 在后排做后端分发。

HAProxy 实战配置

先在独立的入口 VPS 上装 HAProxy（一台 1 核的小机器就够）：

sudo apt install haproxy -y
sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
sudo haproxy -f /etc/haproxy/haproxy.cfg -c  # 改完先校验语法
sudo systemctl restart haproxy

下面是一个可直接用的 L7 配置，含轮询、主动健康检查、Cookie 会话保持和一台备用机：

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    option httplog

frontend web_frontend
    bind *:80
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    cookie SRVID insert indirect nocache
    server web1 10.0.0.2:80 check cookie s1 inter 5s fall 3 rise 2
    server web2 10.0.0.3:80 check cookie s2 inter 5s fall 3 rise 2
    server web3 10.0.0.4:80 check cookie s3 backup

这里有几个值得记住的点：check 开启健康检查；inter 5s fall 3 rise 2 表示每 5 秒探一次，连错 3 次摘流，连对 2 次重新入池；backup 那台只在前面全挂时才顶上。想看实时状态，加一段 stats 面板：

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s

打开 8404 端口，每台后端是绿（UP）还是红（DOWN）一目了然。生产环境建议再用 keepalived 给入口做双机热备，避免 LB 自己成为单点。

Nginx upstream 配置

如果你更习惯 Nginx，配置写在 http 块里。下面是带加权、最少连接和健康检查参数的版本：

upstream app_servers {
    least_conn;
    server 10.0.0.2:80 weight=3 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:80 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:80 backup;
}

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

least_conn 把新请求发给当前连接数最少的机器，比盲轮询更公平；weight 让配置高的机器吃更多流量；proxy_next_upstream 定义哪些情况 Nginx 会换一台重试而不是直接报错给客户端。注意 Nginx 开源版只有被动健康检查（靠 max_fails/fail_timeout 判断），想要主动定时探活得用 Nginx Plus 或第三方模块。

健康检查怎么做才靠谱

健康检查是负载均衡的灵魂。光做 TCP 端口探测不够——端口开着、进程却卡死的情况太常见。正确做法是让后端暴露一个 /health 接口，HAProxy 用 option httpchk 发 GET，期望返回 200。后端可以这样写：

# 在每台后端 Nginx 上
location = /health {
    access_log off;
    add_header Content-Type text/plain;
    return 200 "ok";
}

探测间隔别太激进，5 到 10 秒一次足够，太密会浪费用量。fall/rise 的阈值要有容错，避免偶发抖动误摘流。数据库之类非 HTTP 服务则用 TCP 检查对应端口即可。

还有个容易被忽略的细节：摘流和入池之间存在时间差，滚动更新时要在摘流后等健康检查确认、再停进程，重启完等 rise 通过再放开流量，否则会出现短暂的服务空白。配合 HAProxy 运行时 API 可以做到不停服务地摘下某台机器做维护，比直接改配置文件再 reload 更平滑。

会话保持：cookie / ip_hash / 共享存储

如果你的应用把登录态存在本地文件或内存里，用户被轮到另一台机器就会掉登录。三种解法：

• Cookie 插入（HAProxy）：LB 给浏览器种一个 SERVERID，之后同一用户固定回那台。配置见上文 cookie SRVID insert。
• ip_hash（Nginx）：按客户端 IP 哈希选机器。缺点是在 NAT 或移动网络下，大量用户共用一个出口 IP，会全挤到一台。
• 共享会话存储（推荐）：用 Redis 或 Memcached 存 session，后端无状态，随便哪台都能处理。这是最干净的架构，也最利于水平扩展。

能上共享存储就别依赖粘性会话，后者会让流量分布不均，扩缩容时还会丢会话。

多台 VPS 的取舍与成本

负载均衡不是免费午餐，它至少多吃一台入口机，还要考虑后端互联。几个现实考量：

1. 内网互通：同机房的后端尽量走内网 IP 互访，流量不计费、延迟低。RackNerd、Vultr、DMIT 这类商家不同机房之间可能没有免费内网，跨区只能用公网 IP，记得算流量成本。
2. IPv4 附加费：2026 年 IPv4 枯竭，单 IP 租用约 0.30 到 0.55 美元/月，不少商家每台机器额外收 2 到 3 美元 IP 费。规划后端数量时把这钱算进去。
3. 入口机要稳：LB 是咽喉，建议选网络稳、线路好的机器。面向大陆用户可考虑 DMIT 的 CN2 GIA（AS4809）线路，延迟 130 到 160ms 最稳；预算紧可以用 RackNerd 年付十几美元的套餐做入口，再把算力分散到多台便宜后端。
4. 别被首年价骗：很多特价续费翻倍，规划长期架构要看续费价，别按首年价估成本。

一个务实的组合：一台 Vultr 或 DMIT 做入口 LB（要稳），后面挂两到三台 RackNerd 年付机做应用后端，用内网或同机房公网串联。总成本可能也就每月几美元到十几美元，却换来了单机没有的可用性和扩展弹性。

最后别忘了监控与告警：LB 把故障藏在了背后，你反而更难第一时间发现某台后端悄悄挂了。把 HAProxy 的 stats socket 接上 Prometheus，或者用 Nginx 的 stub_status 配合外部探测，后端掉一台就要有提醒，别等用户投诉才后知后觉。备份策略也要覆盖到 LB 本身——它的配置文件虽小，但丢了就得手忙脚乱重新写。

什么时候其实不需要负载均衡

月访问量几千、单机 CPU 常年低于 30%、业务停几分钟没人care，那真没必要上 LB，先把单机优化好、做好定时备份更划算。负载均衡解决的是"扩展性"和"可用性"，不是"性能不好"——慢是因为程序烂或配置差，加机器只是分摊，不治本。

💡 延伸阅读：关于架构与基础设施的更多深潜指南，请前往 VPS 主题导读中心 (Hub) 获取全盘策略。