HAProxy双网卡负载均衡实战：策略路由与健康检查配置全解析-代码聚汇网

HAProxy双网卡负载均衡实战：策略路由与健康检查配置全解析

HAProxy双网卡负载均衡

|难度：普通|阅读约 45 分钟

接手这套业务时，摆在面前的就三样东西：一台双网卡的CentOS服务器、两个需要承担高峰请求的后端节点，和一个越来越明显的瓶颈——单网卡在入口流量尖峰时几乎被打满。用HAProxy做负载均衡很简单，但要让HAProxy真正把流量按规划从双网卡走，需要搞清楚的不只是配置文件，还有路由表、策略路由和健康检查之间的配合。这篇文章把我部署HAProxy双网卡负载均衡的过程完整整理出来，既讲原理也讲配置，适合正准备给老架构扩容的运维，也适合第一次接触负载均衡的读者。

我会按“为什么这么做、网络怎么划、路由怎么配、HAProxy怎么装怎么配、怎么验证”这条线往下讲，最后会把我在生产环境踩过的几个坑单独拉出来说，这些都是文档里看不到的。

1. 为什么负载均衡服务器需要双网卡

1.1 单网卡架构的瓶颈在哪里

很多人第一次搭HAProxy，习惯性就是一台服务器配一块网卡，IP地址填好，后端填上，跑起来就完事。业务量小的时候，确实看不出问题。但当入口流量涨上来，你会发现CPU占用没到一半，网卡软中断已经吃满单核了，带宽也接近网卡上限。这时候不是HAProxy不行，而是数据通路入口太窄。

单网卡还有一个隐患：客户端流量和后端服务器流量在同一物理链路上混跑。假如后端服务有异常突发流量，可能把面向客户端的入口也拖垮。更麻烦的是，一旦需要抓包排查问题，打开tcpdump全是混在一起的流量，区分成本很高。

用双网卡最常见的动机就是这么简单：把入口流量和后端流量从物理上分开，让两股数据流各走各的链路。入口网卡承受客户端连接，后端网卡承担与真实服务器的通信。互不干扰，排查问题也清晰。

1.2 双网卡不只是“多一块卡”，而是多一个网络平面

我见过的双网卡部署，至少有三类：

南北方向入口分离：eth0接客户端/公网，eth1接后端业务网。HAProxy在这中间扮演网关角色，转发客户端请求到内网后端。
东西方向隔离：两个网卡分别对接两个不同业务网段，HAProxy作为网段间的调度节点。比如一个网段放Web服务，另一个网段放API服务。
双出口/双链路冗余：两块网卡分别接两个上行交换机/两个运营商出口，通过路由策略实现等开销负载均衡，避免单链路挂掉导致整体不可用。

很多情况下，大家说的“双网卡负载均衡”其实同时包含第一类和第三类。也就是说，HAProxy既要承担应用层负载均衡，又希望两块网卡都能发挥作用，不要一块网卡累死、另一块闲着。

这里有一个容易混淆的概念，必须先讲清楚：应用层负载均衡和路由层负载均衡是两个层面的东西。HAProxy做的是应用层调度，它决定“这个请求交给哪台后端服务器”；而内核路由表决定“发往后端服务器的数据包从哪块网卡出去”。流量真正怎么走，取决于路由，不是取决于HAProxy配置文件。所以后面我会花很大篇幅讲双网卡的路由和策略路由配置，这是整个部署最容易出问题、也最容易被忽略的地方。

1.3 “等开销负载均衡”到底是什么意思

网上搜“双网卡负载均衡”经常看到“等开销”这个词。它对应的其实是网络层的ECMP，即等价多路径路由。什么意思？就是当路由表里有两条优先级相同、开销相同的路径都能到达同一个目标网段时，内核会把不同的连接分散到两条链路上，实现链路层的负载分担。

举个例子，假如HAProxy需要访问的运维管理网段同时能通过eth0的网关和eth1的网关到达，而且两条链路开销相等，那你可以在路由表里配置两条默认路由或两条到目标网段的路由。内核会基于连接哈希让一部分连接走一块网卡，另一部分走另一块网卡。关键地方在于，做网络层ECMP时不能盲目追求“包级均分”，因为如果同一个TCP连接的上行包走A网卡、下行包走B网卡，在有状态防火墙或者严格回源策略的环境下，连接会被切断。所以实际生产环境更多用的是“连接级”或“会话级”拆分。

我推荐的做法是：HAProxy负责后端连接调度，内核策略路由负责链路出口选择，两者配合。HAProxy对每个后端新建立的连接，通过策略路由规则确定从哪块网卡出去。这样既实现了后端负载均衡，又实现了一定程度上的链路负载分担。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 双网卡拓扑与IP规划，动手前先弄清数据走向

2.1 一套可复现的拓扑结构

我这次部署用的是比较典型的三层结构，读者可以直接套用：

客户端访问地址：10.1.1.5，这是HAProxy eth0上的IP，对外提供服务。
eth0网段：10.1.1.0/24，网关10.1.1.1，面向客户端网络。
eth1网段：192.168.10.0/24，网关192.168.10.1，面向后端业务网络。
后端Web节点1：192.168.10.11，监听80端口。
后端Web节点2：192.168.10.12，监听80端口。

这套结构里，客户端请求先进eth0，HAProxy把请求重新封装后，从eth1转发给后端服务器。后端服务器响应也先到eth1，HAProxy再通过eth0已有的客户端连接把响应返回。数据面一进一出，泾渭分明。

你可能注意到eth0和eth1各有一个网关。这两个网关如果同时配置成默认路由，就会引发“双网关冲突”。后面我会专门讲解决方案。对于很多部署来说，如果后端业务网和后端服务器在同一二层网段，其实eth1根本不需要默认网关，只配IP和子网掩码就够了。但为了让方案更通用，我会把双网关加上，这样在需要访问更下层网段时也不会有问题。

2.2 VIP与后端服务规划

负载均衡节点上的IP地址分两类：

服务地址（VIP）：一般绑定在面向客户端的网卡上，比如10.1.1.5:80。对外发布时只发布这个地址。
管理地址：可以单独规划一个管理网段，或者用eth1的地址做管理。建议不要把管理面暴露在客户端网卡上，安全策略限制更清晰。

后端节点的健康检查端口也要提前规划。我的经验是，不要直接拿业务端口做健康检查，因为许多业务端口即使进程正常但数据库连接池满了，或者依赖的下游超时，进程也不会退出，端口照样能通，但实际已经不能正常提供服务。所以我更建议在后端节点单独做一个轻量的健康检查URL，比如/health，返回200就认为健康，由应用自己决定这个探活接口的判定逻辑。

2.3 端口规划表

入口网卡eth0（10.1.1.5）	后端网卡eth1（192.168.10.5）	用途
10.1.1.5:80	后端节点192.168.10.11:80	HTTP负载均衡
10.1.1.5:443	后端节点192.168.10.12:80	HTTPS终结与转发
10.1.1.5:8404	仅管理员网段	HAProxy统计页面
不使用	192.168.10.5:22	SSH管理入口

这张表在做防火墙策略和监控采集时非常重要，每一行都必须有明确归属。我最怕看到运维把服务绑成0.0.0.0:80，因为这意味着不管哪块网卡都能访问到你的服务。后面配置HAProxy时，我会刻意用具体IP完成绑定。

2.4 系统基础准备

HAProxy本身不挑配置，双核2GB内存的系统跑几千并发连接完全没问题。但如果要支撑几万并发，建议至少4核8GB，并重点关注CPU的中断处理能力和网卡队列数。多队列网卡在lspci里可以看到是否支持RSS，如果支持，记得开启多队列，否则网卡中断还是会压在单个CPU核上。

系统层面建议关闭不用的防火墙管理组件，使用最小化安装。如果开启了firewalld，要记得把80、443、8404这些端口加白名单。SELinux如果没有特殊硬性要求，可以先设置为permissive，等整个部署验证通过后再决定是否拉回enforcing。特别是HAProxy绑定非标准端口或使用自定义chroot目录时，SELinux经常会出来拦一下，后面故障部分我会再提。

3. CentOS双网卡、多网关配置与策略路由落地

3.1 两块网卡的静态IP配置

在CentOS 7/8/Rocky系列中，网卡配置文件位于/etc/sysconfig/network-scripts/ifcfg-eth0和ifcfg-eth1。CentOS 8开始NetworkManager成为主流网络管理方式，但ifcfg文件仍然兼容。我给一个最常用的配置示例。

eth0配置：

code复制TYPE=Ethernet
BOOTPROTO=none
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPADDR=10.1.1.5
PREFIX=24
GATEWAY=10.1.1.1
DEFROUTE=yes
DNS1=10.1.1.1

eth1配置：

code复制TYPE=Ethernet
BOOTPROTO=none
NAME=eth1
DEVICE=eth1
ONBOOT=yes
IPADDR=192.168.10.5
PREFIX=24
DEFROUTE=no

这里特别说明一下：eth1先不配置GATEWAY，不参与默认路由的竞争。如果后端所有服务器都和HAProxy在同一个192.168.10.0/24网段内，这么做就够了。如果后端还有更下层网段需要访问，我会在后面用策略路由单独处理，而不是简单在eth1上写一个GATEWAY，否则默认路由表里会出现两个默认网关，非常容易出问题。

3.2 双网卡双网关的坑：默认路由打架

很多人给双网卡配置完IP，顺手在两块网卡上都写了GATEWAY，结果重启网络后发现只有一块网卡能上网，或者访问后端的包走了错误的出口。

原因是Linux的路由表里默认路由是唯一的。如果eth0写了GATEWAY=10.1.1.1，eth1也写了GATEWAY=192.168.10.1，内核会选取其中一条作为默认路由，另一条可能被忽略。具体选哪条取决于路由度量值、网卡启动顺序等，结果往往不可控。于是表现出来就是：你去ping 10.1.1.1能通，但ping 192.168.10.1可能超时，因为包带着eth0的源地址从eth0出去了，但目标网段其实在eth1后面，二层根本不可达。

这就是必须做策略路由的原因。策略路由的核心思路是：不把所有流量都交给一张默认路由表，而是按源地址、目标地址、端口等条件，把流量分类到不同的路由表里，每张路由表可以有自己的默认路由。

3.3 配置两张独立路由表

先在/etc/iproute2/rt_tables文件末尾加上两张表：

code复制100 client_out
200 server_out

这里client_out表用于从eth0出去的流量，server_out表用于从eth1出去的流量。然后分别填充两张表的路由：

code复制ip route add default via 10.1.1.1 dev eth0 table client_out
ip route add 10.1.1.0/24 dev eth0 src 10.1.1.5 table client_out

ip route add default via 192.168.10.1 dev eth1 table server_out
ip route add 192.168.10.0/24 dev eth1 src 192.168.10.5 table server_out

注意，我并没有把“到任何目标都从某块网卡走”写死。实际上，client_out表主要用于客户端入口网卡发起的流量，server_out表用于后端网卡发起的流量。接下来通过ip rule把源IP和路由表绑定：

code复制ip rule add from 10.1.1.5 lookup client_out
ip rule add from 192.168.10.5 lookup server_out

这表示：如果本地发出的数据包源IP是10.1.1.5，就优先查client_out表；如果源IP是192.168.10.5，就查server_out表。这样就保证了回包时从哪个网卡出去，就走哪张路由表，不会出现“从eth0进来、却想从eth1的网关出去”的对称路由问题。

如果你需要做双网关的等开销负载均衡，也就是让发往某个目标网段的数据包分散到两个网卡出去，可以再加一条多路径路由：

code复制ip route add 172.16.0.0/24 \
    nexthop via 10.1.1.1 dev eth0 weight 1 \
    nexthop via 192.168.10.1 dev eth1 weight 1

这样到172.16.0.0/24的连接就会按权重哈希分散到两个网关。但注意，这要求两个网关都能到达目标网段，并且链路的开销/质量基本对等，否则就会出现部分连接跨运营商或跨地域绕路的情况。

3.4 让策略路由开机生效

ip rule和ip route命令敲完之后立即生效，但重启网卡或重启机器就没了。最稳妥的方式是写一个systemd服务，在网络服务启动后执行这些规则。我习惯在/usr/local/sbin/dual-nic-routes.sh里放脚本：

code复制#!/bin/bash
ip route add default via 10.1.1.1 dev eth0 table client_out 2>/dev/null
ip route add 10.1.1.0/24 dev eth0 src 10.1.1.5 table client_out 2>/dev/null
ip route add default via 192.168.10.1 dev eth1 table server_out 2>/dev/null
ip route add 192.168.10.0/24 dev eth1 src 192.168.10.5 table server_out 2>/dev/null
ip rule add from 10.1.1.5 lookup client_out 2>/dev/null
ip rule add from 192.168.10.5 lookup server_out 2>/dev/null

然后创建systemd服务：

code复制[Unit]
Description=Dual NIC policy routing rules
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash /usr/local/sbin/dual-nic-routes.sh

[Install]
WantedBy=multi-user.target

执行：

code复制chmod +x /usr/local/sbin/dual-nic-routes.sh
systemctl daemon-reload
systemctl enable --now dual-nic-routes
systemctl status dual-nic-routes

服务状态显示active (exited)就说明规则已经加载。

3.5 验证双网卡连通性

配置完先重启网络或重启机器，然后用下面几组命令验证：

code复制ip addr show eth0
ip addr show eth1
ip rule show
ip route show table client_out
ip route show table server_out

再分别从两块网卡发起请求：

code复制ping -I eth0 -c 3 10.1.1.1
ping -I eth1 -c 3 192.168.10.1

如果ping -I eth1不通，但直接ping 192.168.10.1能通，那往往就是策略路由或防火墙问题。可以先用tcpdump -i eth1 icmp抓包看一下请求有没有发出去。记住，网络不通的时候先抓包，不要瞎猜。

4. 安装HAProxy：版本选择、日志与内核调优

4.1 版本选择：别用太老的包

CentOS自带的仓库里通常只有比较老版本的HAProxy。老版本不是不能用，但缺少不少特性，比如对HTTP/2的支持、更细粒度的健康检查、更好的线程模型等。我建议安装相对较新的稳定版本，2.6以上的版本在性能和特性上都更舒服。

最快的安装方式是用系统包管理器直接装：

code复制yum install -y haproxy

这个装出来的版本可能偏老，但胜在稳定，系统源维护的rpm包依赖也处理得干净。如果你需要较新版本，可以加HAProxy官方仓库，或者直接源码编译。我这边因为是生产环境，用的是源码编译方式，可控性最强。

编译安装大致步骤如下：

code复制wget https://www.haproxy.org/download/2.8/src/haproxy-2.8.1.tar.gz
tar -xzf haproxy-2.8.1.tar.gz
cd haproxy-2.8.1
make -j$(nproc) \
    TARGET=linux-glibc \
    USE_PCRE2=1 \
    USE_OPENSSL=1 \
    USE_ZLIB=1 \
    USE_SYSTEMD=1
make install

TARGET=linux-glibc适用于大多数Linux发行版。USE_OPENSSL=1是必须的，后面做HTTPS终结或者TLS健康检查都靠它。编译前确保系统里有gcc、make、openssl-devel、pcre2-devel、zlib-devel这些依赖。

编译安装的二进制默认放在/usr/local/sbin/haproxy，不会污染系统目录，后续卸载也方便。

4.2 服务管理

编译安装时需要手动创建用户和目录：

code复制useradd -r -d /var/lib/haproxy -s /sbin/nologin haproxy
mkdir -p /var/lib/haproxy
chown haproxy:haproxy /var/lib/haproxy

然后创建一个systemd服务文件/etc/systemd/system/haproxy.service：

code复制[Unit]
Description=HAProxy Load Balancer
After=network.target

[Service]
ExecStart=/usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
ExecReload=/bin/kill -USR2 $MAINPID
User=haproxy
Group=haproxy
PIDFile=/run/haproxy.pid
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

ExecReload用kill -USR2是HAProxy官方推荐的热加载方式，新老进程无缝切换，不会丢连接。每次改配置后执行systemctl reload haproxy即可。

4.3 日志配置

HAProxy默认把日志交给rsyslog处理。标准做法是在/etc/haproxy/haproxy.cfg的global段里写：

code复制log /dev/log local2

然后新建/etc/rsyslog.d/haproxy.conf：

code复制local2.* /var/log/haproxy.log

重启rsyslog后，HAProxy日志就会写到独立文件。生产环境建议给日志文件配置logrotate，避免日志无限膨胀。我在实际项目里见过有人忘了这一步，半年后发现日志文件占了几十GB，直接把磁盘塞满，这是很低级的坑，但发生频率很高。

HAProxy的日志格式非常有用，它会记录每个连接的耗时、后端节点、队列等待时间、状态码等信息。后面排查“某个接口为什么慢”时，第一步就是看HAProxy日志里的Tw等待时间、Tc连接时间、Tq请求解析时间，基本能定位是客户端问题、后端问题还是网络问题。

4.4 内核参数和文件句柄调整

HAProxy是事件驱动模型，单进程能撑起的连接数非常高，但它对系统文件句柄和端口范围的要求也很高。生产环境一定要调到下面这组值。

在/etc/sysctl.conf里追加：

code复制net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_nonlocal_bind = 1
fs.file-max = 1000000

net.ipv4.ip_nonlocal_bind=1这个很多人会忽略。如果你后面要达到VIP漂移或者临时把一个不属于本机的IP绑定到服务上，这个参数必须打开，否则启动会报“Cannot assign requested address”。

执行sysctl -p生效。另外，HAProxy进程的LimitNOFILE在systemd服务文件里已经设置了，但还要确认系统级ulimit -n没限制死。haproxy用户能打开的文件句柄数，可以写进/etc/security/limits.d/haproxy.conf：

code复制haproxy    hard    nofile    1048576
haproxy    soft    nofile    1048576

5. 双网卡场景下的HAProxy核心配置

5.1 配置文件整体结构

HAProxy的配置分为global、defaults、frontend、backend、listen几个段。完整配置示例下面会拆开讲。

code复制global
    log /dev/log local2
    chroot /var/lib/haproxy
    pidfile /run/haproxy.pid
    stats socket /run/haproxy/stats.sock mode 600 level admin
    user haproxy
    group haproxy
    daemon
    maxconn 100000
    nbthread 4
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11

defaults
    mode http
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    timeout http-keep-alive 10s
    timeout queue 30s
    retries 3

nbthread 4表示用4个线程处理事件。如果你的机器是双核，改成nbthread 2就好。不要盲目开很多线程，线程多了反而会因为锁竞争降低性能，一般来说线程数和物理核心数一致最稳妥。

5.2 frontend必须绑定到具体网卡IP

这是双网卡部署中最关键的一点。入口面向用户的服务，一定要绑定在eth0的IP上，不要图省事写0.0.0.0。

code复制frontend http-in
    bind 10.1.1.5:80
    mode http
    default_backend web_servers

frontend https-in
    bind 10.1.1.5:443 ssl crt /etc/haproxy/certs/server.pem
    mode http
    option http-buffer-request
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend web_servers

绑定到具体IP有几个好处：

服务不会意外暴露在后端网卡上，避免内网其他设备以服务名义访问到你的HAProxy。
排查问题时，ss -lntp看到的监听地址非常清晰，一看就知道哪个服务绑定在哪块网卡上。
后续做iptables或安全组策略时，可以精确控制进出流量。

如果你在一个物理接口上还要承载多个VIP，可以用bind 10.1.1.5:80、bind 10.1.1.6:80这样的方式分开，路由层面做好对应规则即可。

5.3 backend调度算法怎么选

双网卡场景下，backend的关键不只是写两个IP，还要明确指定源地址和调度策略。

code复制backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    source 192.168.10.5
    server web1 192.168.10.11:80 check inter 2s fall 3 rise 2
    server web2 192.168.10.12:80 check inter 2s fall 3 rise 2

source 192.168.10.5这行非常关键。它告诉HAProxy，往后端发起连接时，源地址固定使用eth1的IP。这样报文的源IP、出口网卡、应答路径全部一致，不会出现“源地址是eth0、物理出口却是eth1”这种不对称情况。

关于balance算法的选择，我整理了一张表：

算法	特点	适用场景
roundrobin	按权重轮流分配，实现简单，抖动最小	短连接、快速响应的HTTP服务
leastconn	优先分配给当前连接数最少的后端	长连接，比如WebSocket、数据库中间件
source	对客户端IP取哈希，同一客户端固定到同一后端	会话未做应用层共享时需要保持会话的场景
uri	对请求URI取哈希，同一个接口固定到同一后端	缓存命中优先，比如读多写少接口

roundrobin在绝大多数Web场景下都是最稳的。leastconn也不是万能的，如果后端请求处理极快，连接数指标反而失真。最怕的是有人用了source哈希做会话保持，结果其中一台后端容量是另一台的两倍，同一个来源IP的流量却一直打到小容量节点上，造成倾斜。如果必须做会话保持，我建议加cookie机制或者用hash-type consistent配合权重做一致性哈希。双网卡下没有特殊限制，你按业务需求选就行。

5.4 健康检查要模拟真实可用性

健康检查是负载均衡自动摘除故障节点的关键。很多人简单写一个check就完事，但其实需要更细的参数。

code复制option httpchk GET /health
http-check expect status 200
server web1 192.168.10.11:80 check inter 2s fall 3 rise 2
server web2 192.168.10.12:80 check inter 2s fall 3 rise 2

含义解释一下：每2秒做一次HTTP GET请求/health，连续成功2次就判定该节点恢复，连续失败3次就判定该节点宕机并摘除。

健康检查频率不要太高。inter 1s虽然能更快发现故障，但每个后端节点每秒都会被探测一次，几百个节点时探测流量会让内网压力变大。我一般用inter 3s，关键业务用inter 2s。另外，健康检查超时时间默认等同于timeout connect，如果后端处理健康检查响应很慢，记得单独设置timeout check 2s。

5.5 TCP负载均衡示例

不是所有流量都是HTTP。数据库、Redis、MQ这类TCP服务也可以用HAProxy做四层负载均衡，配置更简单。

code复制frontend mysql-in
    bind 10.1.1.5:3306
    mode tcp
    default_backend mysql_nodes

backend mysql_nodes
    mode tcp
    balance leastconn
    timeout connect 3s
    timeout server 30s
    option tcp-check
    tcp-check connect
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    source 192.168.10.5
    server db1 192.168.10.21:3306 check inter 3s fall 3 rise 2
    server db2 192.168.10.22:3306 check inter 3s fall 3 rise 2

mode tcp下没有HTTP相关的选项，所以前端的option httplog和option forwardfor在TCP模式下不生效。TCP健康检查用option tcp-check，可以自定义发送和匹配内容，对于Redis这一类推拉类协议非常有效。

注意，四层负载均衡因为没有请求内容可看，会话保持通常靠source哈希或者IP透传参数proxy-protocol实现。如果后端服务能够接受代理协议，我建议在defaults里开启option send-proxy，这样后端能看到客户端真实IP，对日志分析很有帮助。

5.6 配置校验与平滑重载

每次修改配置后，一定要先做语法校验再重载：

code复制haproxy -c -f /etc/haproxy/haproxy.cfg

-c校验通过后会显示“Configuration file is valid”。确认无误后再执行：

code复制systemctl reload haproxy

HAProxy的进程热加载机制比较优雅。老进程会继续处理存量连接，新进程接替新的连接，等老连接处理完再退出。所以你不需要担心reload会闪断。但如果配置里有非常严重的语法错误，reload会失败，服务保持旧状态运行，这也是为什么先执行-c能救你一次。

如果你需要对某台后端节点做发布维护，可以临时在配置里用disabled注释掉或用命令动态调整：

code复制echo "disable server web_servers/web1" | socat stdio /run/haproxy/stats.sock

这个命令需要stats socket已经配置好。动态摘除节点后，已建立的连接不会被打断，新连接不再分发到该节点，比直接改配置再reload更平滑。

5.7 统计页面与监控

双网卡环境下，统计页面我建议绑定到管理网段的独立端口，不要放到业务网卡上。配置如下：

code复制listen stats
    bind 192.168.10.5:8404
    mode http
    stats enable
    stats uri /stats
    stats realm HAProxy\ Statistics
    stats auth admin:ChangeThisPassword
    stats admin if LOCALHOST

这里只允许从后端管理网段访问统计页面，进一步减少了暴露面。如果你想让zabbix或prometheus采集指标，还可以用prometheus-exporter插件或通过socket命令输出状态。最常用的命令是：

code复制echo "show info" | socat stdio /run/haproxy/stats.sock
echo "show stat" | socat stdio /run/haproxy/stats.sock

socat没有的话，用nc -U /run/haproxy/stats.sock也行，只是交互上没有socat方便。通过socket做动态运维非常有用，比如临时摘除节点、调整权重、查看会话数，都不会中断服务。

6. 验证效果与故障复盘：从实测到排错

6.1 确认连接在后端节点上均匀分布

配置完成、启动HAProxy后，先不要急着宣布“搞定”。要用实际请求压一遍，观察后端节点上的连接数分布。

code复制for i in $(seq 1 1000); do curl -s -o /dev/null http://10.1.1.5/; done

然后在两台后端节点上分别执行：

code复制ss -tan | grep ':80' | grep -v LISTEN | wc -l

或者直接在HAProxy上统计当前TCP连接数：

code复制echo "show stat" | socat stdio /run/haproxy/stats.sock | awk -F, 'NR==1 || /web_servers/ {print $1, $2, $8, $9}'

$8是当前会话数，$9是当前队列数。如果两台后端节点的会话数相差很大，需要检查是不是balance算法选得不对，或者健康检查是不是把其中一台标记成了DOWN。

6.2 用tcpdump验证数据确实走了对应网卡

这是双网卡验证中最直观的一步。在HAProxy上开两个抓包窗口：

code复制tcpdump -i eth0 -nn port 80
tcpdump -i eth1 -nn port 80

然后从外部客户端发起一次HTTP请求。正常的抓包结果应该是：eth0上有客户端IP到10.1.1.5的流量，eth