haproxy最适合高并发http/tcp场景，支持细粒度路由、cookie持久及http状态码健康检查；nginx lb功能为反向代理副产品，健康检查被动且权重调整需重载；lvs+keepalived适用于四层高并发，但无七层处理能力。
免费且生产可用的负载均衡开源工具，主力就三个：HAProxy、Nginx、LVS —— 其中 HAProxy 和 Nginx 最适合大多数 Web/HTTP 场景，LVS 更偏底层网络层（需内核支持）。
HAProxy 适合什么场景？为什么它常被选作核心 LB
当你需要稳定支撑高并发 HTTP/TCP 流量，同时要求细粒度控制（比如按 URL 路由、Cookie 持久、后端健康检查带 HTTP 状态码判断），HAProxy 是首选。它不像 Nginx 那样能当 Web 服务器或缓存，但作为纯负载均衡器，性能更轻量、协议处理更专注。
-
haproxy -v输出版本号，确认是否 ≥ 2.4（2026 年主流发行版默认已含） - 配置里用
option httpchk GET /health可真正探测后端服务是否“活着”，不只是端口通 - 若用
source调度算法做会话保持，注意客户端 IP 经过 NAT 后可能全变成网关 IP，此时要配forwardfor或改用cookie方式 - 不支持直接压缩响应体（如 gzip），得靠后端服务或前置 CDN 完成
Nginx 做负载均衡要注意哪些实际限制
Nginx 上手快，但它的 LB 功能是“反向代理的副产品”，不是专为 LB 设计，所以有些能力天然受限 —— 尤其在复杂七层调度和状态感知上。
- 健康检查只支持
max_fails/fail_timeout这类被动检测，没有 HAProxy 那种主动发HEAD请求探活的能力（除非用商业版或 OpenResty + Lua） -
ip_hash在 IPv6 或多层代理下容易失效，真实用户 IP 可能被覆盖，建议配合set_real_ip_from+real_ip_header使用 - 如果后端是 gRPC 服务，必须用
grpc_pass（1.13.10+），且需开启http2，普通proxy_pass会直接失败 - 权重调整不能热生效：改了
weight=5得nginx -s reload，期间有极短连接中断窗口
LVS + Keepalived 组合：什么时候该考虑它
当你的瓶颈真正在四层（TCP 连接数、SYN 包吞吐、单机扛不住 10 万+ 并发连接），且后端服务本身能处理会话一致性（比如无状态 API 或数据库读库），LVS 是更底层、更高性能的选择。
- LVS 本身不解析应用层内容，所以无法做 URL 路由、Header 改写、gzip 等 —— 它只管把包转给谁
- 必须搭配
keepalived实现 VIP 高可用，否则单点故障风险极高 - DR（Direct Routing）模式要求所有节点和 LVS 在同一二层网络，且后端需抑制 ARP 响应，配置稍复杂
- 如果你用的是云厂商 VPC，多数不支持自定义 ARP 或 RAW socket，LVS 的 DR/TUN 模式基本不可用，只能退回到 NAT 模式（性能打折扣）
真正上线前最容易被忽略的一点：所有这些工具的健康检查默认超时时间都偏长（HAProxy 默认 5s，Nginx 默认 10s），在微服务快速扩缩容场景下，会导致故障节点剔除延迟。务必根据你后端服务的平均响应时间，把 timeout check 或 fail_timeout 改到 1~3 秒，并配合理想的重试次数（比如 rise 2 fall 3）。
