尧图网站建设 
先说一句这两年线上出过好几次事故最后查下来都不是业务代码的问题而是流量入口的负载均衡层没扛住。后来我把入口从 Nginx 主备切换改成 HAProxy 主备双活再往后跑了快三年除了例行维护基本没再为入口层操过心。这篇文章就围绕 HAProxy 展开讲清楚它到底是什么、核心配置怎么写、关键参数怎么调、高可用方案怎么落地以及我在真实业务里踩过的坑和排查思路。如果你正在搭建负载均衡层或者想把手里的 Nginx 单点方案升级成更稳的入口架构这篇文章可以给你一份能直接照做的参考。1. HAProxy 的定位与选型思路1.1 HAProxy 到底解决了什么问题HAProxy 是一款开源的高性能 TCP/HTTP 负载均衡器核心作用就是把进入的请求按照某种策略分发给后端的多台服务器。它和 Nginx 最大的区别在于Nginx 本质是 Web 服务器负载均衡只是它的功能之一而 HAProxy 从诞生起就只专注于代理和分发没有静态文件处理、没有缓存模块把所有性能都用在请求转发上。我在实际使用中感受最深的一点是它对连接的处理非常精细。每个连接进来HAProxy 会维护独立的会话状态支持四层TCP和七层HTTP两种模式。四层模式只看源 IP 和端口直接转发原始数据包七层模式会解析 HTTP 头部、URL、Cookie 等信息然后基于这些内容做路由。这种分层设计让它的适用面很广——既能代理 MySQL、Redis 这类 TCP 服务也能做 Web 服务的七层分发。它解决的核心问题有三个流量分发把请求均匀打到多台后端、故障转移后端挂了自动摘除恢复后自动加回、会话保持同一个用户的请求始终落到同一台后端。这三个能力结合起来就能把一组普通服务器变成一个高可用的服务集群。1.2 选型对比HAProxy 与 Nginx、LVS 怎么选很多朋友一上来就问“HAProxy 和 Nginx 哪个好”其实这俩不完全是竞争关系。我见过不少团队用 Nginx 做入口再用 HAProxy 做 Nginx 后端的负载均衡也见过直接用 HAProxy 做入口后面挂 Nginx 处理静态文件。选型要看你的核心诉求对比维度HAProxyNginxLVS核心定位专职负载均衡/代理Web服务器反向代理内核态四层负载均衡七层处理能力强ACL 规则灵活强配合 Lua 更灵活弱主要工作在四层四层转发性能很高较高最高工作在内核态配置复杂度中等专业术语多简单直观较复杂依赖 ipvsadm会话保持多种算法健康检查依赖 upstream 配置依赖调度算法动态调整后端支持可通过 socket 在线操作需 reload支持但管理较繁琐这里要特别说下 LVS。LVS 工作在 Linux 内核态转发性能确实比 HAProxy 高但部署和运维成本也高而且对后端服务器的网络配置有要求比如 DR 模式需要配置 VIP 和 ARP 抑制。绝大多数业务场景HAProxy 的软件性能已经足够支撑每秒几万级别的请求没必要为了追求极限性能引入 LVS 的复杂度。我的建议是如果只是 Web 入口分发Nginx 足够如果在 Nginx 前面需要一层独立的流量入口或者在同一个入口同时代理 HTTP 和 TCP 服务选 HAProxy 更顺手。我目前的架构就是 HAProxy 做流量入口后面挂 Nginx 集群处理静态资源和反向代理各管一段互不干扰。2. 核心配置结构拆解2.1 三段式配置global、defaults、frontend/backendHAProxy 的配置文件结构非常清晰核心就三段global、defaults、以及成对的frontend和backend。global段配置进程级别的参数比如运行用户、日志、最大连接数、线程数、SSL 相关设置。这一段的参数一旦写错HAProxy 可能直接启动失败所以改完一定要记得做配置检查。defaults段是全局默认值给后面所有的 frontend/backend 提供默认参数。这里写得好的话后面每个服务只需要写自己独有的配置能省一大截重复代码。我习惯把mode、timeout、option这些通用项都放在 defaults 里。frontend段定义流量的入口监听某个 IP 和端口接收请求后用 ACL 规则判断“这个请求应该交给哪个 backend”。backend段定义一组后端服务器以及负载均衡算法、健康检查方式、会话保持策略等。你可以把 frontend 理解成公司前台backend 是各个业务部门。前台接到访客请求根据访客来意URL、域名、请求头引导到对应的部门backend部门里有多名员工后端服务器前台按照一定的规则负载均衡算法决定把活儿派给哪个员工。2.2 核心参数逐个解读mode、bind、balance、timeout在写配置之前有几个参数必须先吃透它们决定了整个代理的行为模式。mode只有两个可选值tcp和http。tcp是四层转发HAProxy 不解析报文内容适合数据库、消息队列等协议http是七层转发HAProxy 会解析 HTTP 请求行、头部、正文可以做 URL 路由、Cookie 会话保持、HTTP 重定向等高级操作。bind指定 HAProxy 监听哪个 IP 和端口。如果是 IPv4 就是bind *:80监听所有网卡的 80 端口还可以加ssl关键字启用 HTTPS。balance指定负载均衡算法。最常用的是roundrobin轮询请求依次分给每台后端适合处理能力对等的服务器leastconn是“谁当前连接数最少就把请求发给谁”适合长连接场景比如 WebSocket、数据库连接池source是对同一个源 IP 哈希取模保证同一个 IP 始终打到同一台后端实现简单的会话保持。timeout系列参数是排障时最容易被忽视的。timeout connect是 HAProxy 向后端发起连接的超时时间默认几秒就够timeout client是客户端空闲超时超过这个时间客户端还没发数据就断开timeout server是后端空闲超时。这三个值如果设置不合理会出现大量 504 或者连接被莫名断开的问题。我后面会专门讲一套合理的取值思路。2.3 一个可直接上手的完整基础配置说了这么多理论直接给一份我常用的基础配置模板你可以根据自己的业务修改后直接用global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /var/lib/haproxy/stats mode 600 level admin stats timeout 30s user haproxy group haproxy daemon maxconn 4096 nbthread 4 spread-checks 5 defaults log global mode http option httplog option dontlognull option forwardfor option http-server-close timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 10s frontend web_front bind *:80 default_backend web_servers backend web_servers balance roundrobin option httpchk GET /health.html server web1 192.168.1.11:8080 check inter 3s fall 3 rise 2 server web2 192.168.1.12:8080 check inter 3s fall 3 rise 2这份配置里埋了一个我踩过坑留下的细节option httpchk后面配置了健康检查路径/health.html。很多教程直接写option httpchk不写路径默认是OPTIONS /请求部分后端框架对 OPTIONS 方法的处理会比较慢甚至直接拒绝导致健康检查误判。我那次全站 502 就是这个问题改完路径立竿见影。3. 关键功能实操与参数调优3.1 健康检查主动探测与被动熔断的配合健康检查是负载均衡的命脉。后端服务器又不是永远不会出问题内存飙升、磁盘写满、代码死锁各种情况都可能导致服务假死。健康检查的作用就是持续探测后端是否真的能处理请求不能就自动摘掉。HAProxy 的健康检查分主动和被动两种。主动检查就是 HAProxy 定期向后端发起探测请求根据响应判断后端状态对应配置里的check关键字和inter、fall、rise三个参数。inter是探测间隔单位毫秒注意这里不写单位默认就是毫秒fall是连续失败多少次后标记为 DOWNrise是连续成功多少次后标记为 UP。这三个参数的取值很有讲究。inter太短会导致后端压力大因为健康检查本身也是请求太长又会导致故障发现不及时。我一般设置inter 3s也就是每 3 秒探测一次。fall 3意味着连续 3 次失败才摘除配合 3 秒间隔检测一个故障最长需要约 9 秒这个延迟在大多数场景下可以接受。rise 2意味着后端恢复后连续 2 次探测成功就重新加入避免偶发一次成功就上线导致抖动。被动检查也叫熔断机制对应两个参数maxconn和maxqueue。当某个后端的连接数达到maxconn上限HAProxy 不会再向它分发新请求如果还有排队队列maxqueue超过队列长度的请求会直接返回 503。被动检查是对主动检查的重要补充——主动检查只能发现“服务完全不可用”而被动检查能发现“服务还能响应但已经快扛不住了”的状态。3.2 会话保持的三种实现方式HTTP 服务经常需要把同一个用户的请求固定在同一个后端上典型场景就是登录态。如果用户登录时请求打到后端 A刷新页面时负载均衡又把请求分给了后端 B而后端没有做 session 共享那就直接掉登录了。实现会话保持有三种主流方式。第一种最简单用balance source。它是基于源 IP 哈希的调度算法同一个源 IP 会被哈希到同一个后端。缺点是如果用户通过手机网络切换基站导致出口 IP 变化会话就断了如果大量用户从同一个 NAT 出口访问流量会集中到少数几台后端上负载不均衡。第二种是 Cookie 插入对应配置backend web_servers balance roundrobin cookie SERVERID insert indirect nocache server web1 192.168.1.11:8080 cookie web1 check server web2 192.168.1.12:8080 cookie web2 checkHAProxy 给每个后端服务器指定一个 cookie 值这里是 web1 和 web2当用户第一次访问时HAProxy 在响应里插入一个名为SERVERID的 cookie值就是处理后端的标识。之后用户再带着这个 cookie 来HAProxy 直接根据 cookie 值路由不再走轮询。indirect表示如果请求本身已经带了SERVERID头就不覆盖nocache是告诉中间缓存不要缓存这个 cookie。第三种是 Cookie 前缀适合后端应用自己已经在种 session cookie 的场景。HAProxy 不改写后端的 cookie而是把自身的标识追加到已有 cookie 值前面类似SRVweb1; JSESSIONIDabc123。这种方式侵入性最小但要求后端 cookie 名必须是已知的。我的经验是能在应用层做 session 共享比如 Redis就尽量做会话保持只是兜底手段。会话保持会牺牲一定程度的负载均衡效果流量倾斜不可避免。但如果在迁移成本高、短期内必须平滑过渡的情况下Cookie 插入是性价比最高的方案。3.3 ACL 规则用请求内容做精细路由ACLAccess Control List是 HAProxy 七层能力最精华的部分。它允许你根据请求的任何特征——URL、域名、请求头、Cookie、HTTP 方法、源 IP——判断请求应该去哪个后端。这就让一个 HAProxy 实例能同时代理多个业务充当网关角色。一个典型的场景是 API 网关和静态资源分离frontend web_front bind *:80 # 请求 /api/ 开头的路径交给 api_backend acl is_api path_beg /api/ use_backend api_backend if is_api # 请求 img.example.com 域名交给 image_backend acl is_img hdr_dom(host) img.example.com use_backend image_backend if is_img default_backend web_servers backend api_backend balance leastconn server api1 192.168.1.21:8080 check server api2 192.168.1.22:8080 check backend image_backend balance roundrobin server img1 192.168.1.31:8080 check server img2 192.168.1.32:8080 check这段配置里有几个语法细节值得记住。path_beg是“路径以什么开头”的匹配器hdr_dom(host)是取Host请求头的域名部分做匹配use_backend ... if ...是条件路由语句多个条件可以or连接。ACL 还支持正则-i忽略大小写等修饰符非常灵活。除了路径和域名ACL 还可以做灰度发布。比如让某个特定源 IP 段或者某个特定 Cookie 值的用户访问新版本后端其他用户走旧版本。这个场景我后面会专门展开讲。3.4 TLS 终止与强制 HTTPS 跳转现在基本没有裸 HTTP 的服务了TLS 终止是负载均衡的标准操作。HAProxy 支持三种 SSL 模式TLS 终止后端用 HTTP、TLS 透传四层模式直接把加密流量转发、TLS 桥接先解密再按内容路由再重新加密转发给后端。最常见的配置是 TLS 终止证书放在 HAProxy 上后端服务器不处理加解密压力集中在入口层。配置方法是bind上直接加ssl关键字和证书路径frontend web_front bind *:80 bind *:443 ssl crt /etc/haproxy/certs/example.com.pem http-request redirect scheme https unless { ssl_fc } default_backend web_serversbind *:443 ssl crt后面的.pem文件里需要同时包含证书和私钥按“证书在前私钥在后”的顺序拼接这个格式容易被忽略。http-request redirect scheme https unless { ssl_fc }是强制跳转只要请求不是 SSL 连接ssl_fc是 SSL 连接标志就重定向到 HTTPS。如果你有多个域名证书文件可以放到一个目录下HAProxy 会自动按域名匹配bind *:443 ssl crt /etc/haproxy/certs/目录下的每个.pem文件名如果和域名匹配比如a.com.pemHAProxy 会在 SNI 握手时自动选择对应证书。这个特性让我免去了 reload 配置文件的操作新域名加证书只需要放文件到目录即可。4. 性能优化与高承载压测调优4.1 吞吐模型估算maxconn 到底设多大很多人设置maxconn全靠猜其实这个值是可以通过一个简单模型推算出来的。先想清楚你的后端处理能力假设每台后端服务器能同时处理 100 个并发请求你有 4 台后端那么理论支撑的总并发量是 400。如果你希望 HAProxy 不成为瓶颈它的maxconn至少要是这个数的 1.5 倍到 2 倍留出缓冲应对突发流量。也就是 600 到 800。但maxconn不只是配置文件里的一个数。每个连接都会消耗文件描述符fdLinux 单进程默认的 fd 上限是 1024撑不起大并发。我一般会同步修改系统参数ulimit -n 65535 echo fs.file-max 100000 /etc/sysctl.conf sysctl -p还要注意 HAProxy 有一种“过度订阅”机制。它允许在maxconn之外再接受一小部分连接tune.maxaccept用于应对瞬时流量尖峰。默认值是 100如果压测时发现连接数报表突然涨得很厉害可以适当调低这个值让 HAProxy 更平滑地处理连接突发。4.2 内核参数与网络栈调优清单HAProxy 性能发挥到极致光调它自己的参数是不够的Linux 内核网络栈往往才是瓶颈。我的/etc/sysctl.conf里长期保存着这样一组调优参数net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.ip_local_port_range 1024 65535 net.ipv4.tcp_tw_reuse 1 net.core.netdev_max_backlog 65535net.core.somaxconn决定内核 socket 监听队列长度如果设置太小高并发下会出现connection reset by peer的错误。net.ipv4.ip_local_port_range决定本地可用端口的范围在 HAProxy 向后端发起大量连接时每个连接都会占用一个本地端口范围太小会直接导致Cannot assign requested address的报错。tcp_tw_reuse允许回收 TIME_WAIT 状态的连接减少端口耗尽风险。调完这些参数记得用sysctl -p生效并且压测时要观察/proc/net/sockstat里的连接数分布确认没有达到上限。4.3 多线程模式与压测实践记录HAProxy 老版本是单进程单线程模型现在新版本支持nbthread参数启用多线程。我拿一台 4 核虚拟机做过对比单线程模式下用 wrk 压测每秒能处理约 3.5 万次简单 HTTP 请求开启nbthread 4后提升到 6.2 万左右。但注意不是线程越多越好还要同时设置cpu-map把线程绑定到物理核上避免线程在不同核之间跳动引发上下文切换开销global nbthread 4 cpu-map 1 0 cpu-map 2 1 cpu-map 3 2 cpu-map 4 3除了线程tune.bufsize和tune.maxrewrite也影响性能。tune.bufsize默认 16384 字节表示每个连接的内存缓冲区大小如果你的请求头特别大比如很多 Cookie可能需要调大否则 HAProxy 会返回 400。tune.maxrewrite是缓冲区内用于 HTTP 头重写的空间默认 1024 字节如果配置了很多重写规则比如 X-Forwarded-For也要适当调大。压测方法我建议用 wrk 或者 h2load 做 HTTP 压测用haproxy -c -f /etc/haproxy/haproxy.cfg检查配置合法性再用haproxy -d前台调试模式观察运行情况。压测时重点看三个指标QPS每秒请求数、连接成功率、P99 延迟。4.4 监控与日志掌握实时状态HAProxy 自带一个监控页面通过stats socket暴露 Unix Socket配合stats admin可以实现在线启用/禁用后端服务器。在 frontend 里加一段配置就能打开 HTTP 监控页面frontend stats_front bind *:8404 stats enable stats uri /stats stats refresh 30s stats auth admin:your_password通过socat连接到 stats socket 可以做动态管理。滚动更新后端时我经常用这一招echo disable server web_servers/web1 | socat stdio /var/lib/haproxy/stats # 等待 web1 上的存量请求处理完 echo enable server web_servers/web1 | socat stdio /var/lib/haproxy/stats这比直接 kill 后端进程安全得多因为 HAProxy 会先停止向 web1 分发新请求但已经建立的连接还能继续处理完。这正是“优雅下线”的实现方式。配合 Prometheus 的 haproxy_exporter还可以把后端队列长度、健康状态、会话数这些关键指标接到 Grafana 上做告警。5. 高可用部署与容器化实践5.1 Keepalived 实现主备漂移HAProxy 本身是无状态的它可以挂掉但不能让入口地址跟着消失。业界最经典的做法是 HAProxy Keepalived 组合两台服务器各跑一个 HAProxy共享一个虚拟 IPVIPKeepalived 负责探活和 VIP 漂移。主备节点的 keepalived 配置核心如下主节点示例vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass your_password } virtual_ipaddress { 192.168.1.100 } }备节点把state改成BACKUP、priority改成 90其他参数保持一致。virtual_router_id在同一个网段内必须唯一否则两台机器会互相冲突。Keepalived 默认每 1 秒发送一次 VRRP 心跳主节点挂了最多 3 秒内 VIP 就会漂移到备节点。但这里有个细节Keepalived 只能探测自己的进程状态如果 HAProxy 卡死了但进程还在VIP 不会漂移。稳妥的做法是写一个探活脚本检测 HAProxy 的健康状态异常时直接停掉 keepalived 进程触发 VIP 漂移。我在实践中用的探活脚本大致逻辑是#!/bin/bash if ! pgrep -x haproxy /dev/null; then systemctl stop keepalived fi # 通过 stats socket 检测后端健康状态 if ! echo show stat | socat stdio /var/lib/haproxy/stats | grep -q web_servers/web1.* UP; then exit 1 fi5.2 Docker 快速部署 HAProxy容器化部署 HAProxy 非常简单官方镜像haproxy已经包含编译好的二进制挂载配置文件即可docker run -d \ --name haproxy \ --restart unless-stopped \ -p 80:80 \ -p 443:443 \ -p 8404:8404 \ -v /etc/haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro \ -v /etc/haproxy/certs/:/etc/haproxy/certs/:ro \ haproxy:2.8有一点要特别注意在容器里chroot可能因为权限问题导致启动失败所以容器化部署时我会把global段里的chroot参数注释掉。另外stats socket的路径要放在容器内的可写目录或者直接把 socket 文件的权限配置对。如果配置有改动可以用docker kill -s HUP haproxy触发优雅重载HAProxy 会用新配置启动新进程再逐步替换旧进程连接不会中断。这一点比直接docker restart友好得多。5.3 对接 KubernetesIngress Controller 选型在 Kubernetes 环境里HAProxy 有两个切入点一是作为 Nginx Ingress Controller 前面的硬入口二是直接使用 HAProxy Ingress Controller。HAProxy 官方的 Ingress Controller 和 Nginx Ingress 相比优势在于配置模型更静态CRD 支持的语义更丰富。比如 Nginx Ingress 的 annotation 五花八门改一个配置经常要等 controller 重新生成配置再 reload而 HAProxy Ingress 直接维护一份 ConfigMap改动逻辑更透明重载更可控。我团队目前的生产环境是双墙方案每个 K8s 集群外面放两个 HAProxy 实例组成 VIP流量先进 VIP再进集群的 NodePort集群内部用 Nginx Ingress 做南北向路由。这样做的原因是 NodePort 本身不带健康检查后端 Pod 挂了一两个很容易出现请求打到死节点上重试超时而 HAProxy 侧的健康检查能直接探到 NodePort 端口的状态有几百毫秒级别的故障感知能力比 K8s 内部的 Readiness 探针反应更直接。灰度发布我习惯在 HAProxy 层先做一层让绝大部分流量走 v1 版本的 Service少量流量比如公司内部测试 IP 段走 v2 版本。这个需求用 Nginx Ingress 的 annotation 也能实现但 HAProxy 的 ACL 规则写起来更直观改动的可见性也更强。6. 常见问题与排查技巧实录6.1 后端全部标记 DOWN 的排查思路这是负载均衡场景最吓人的故障所有后端突然从监控页面上看都是 DOWN业务直接瘫痪。我排查这种问题的顺序是这样的第一步确认健康检查路径是否返回了预期状态码。option httpchk GET /health.html期望收到 2xx/3xx 状态码如果后端代码更新后/health.html返回了 500 或者变成了 302健康检查就会误判。我遇到过最坑的一次是后端升级后/health.html变成了一个必须登录才能访问的页面返回 302HAProxy 认为后端异常直接摘除了。第二步检查后端防火墙是否拦截了 HAProxy 的探测源 IP。inter 3s意味着每 3 秒就有一次探测请求如果后端有 fail2ban 之类的防护软件可能会误判为恶意扫描把 HAProxy 的 IP 封掉。排查方式是登录后端服务器tail -f看访问日志里有没有来自 HAProxy 地址的请求。第三步看 haproxy 日志里有没有连接被拒的信息。健康检查报错通常会在日志中体现为ECONNREFUSED或者timeout根据具体报错再定位是网络问题还是应用问题。这里有个经验值分享给你健康检查的inter不要设置太极端。有的团队为了快速感知故障把inter设为 500ms结果后端某个接口本身就要 1 秒才能返回几乎每一次探测都超时后端被误摘。健康检查本身不应该给后端制造负担inter 3s以上是比较稳妥的起点。6.2 502 和 504 报错背后的真实原因客户端看到 502 或 504第一反应是后端应用挂了但很多时候根因在负载均衡层。我梳理了一下最常见的几种情况502 Bad Gateway 通常是 HAProxy 和后端服务器之间的 TCP 连接建立失败或者后端返回了非法响应。比如后端服务器的 backlog 队列满了内核直接拒绝新连接这时候 HAProxy 转发请求就会失败。用netstat -anp | grep :8080 | grep SYN能确认是不是半连接队列积压。也有可能是后端返回的响应头格式不合法比如缺少Content-Length头且没有Connection: closeHAProxy 会判定响应无效直接断开。504 Gateway Timeout 的本质是后端处理请求超时。这时候要区分是哪个超时被触发客户端到 HAProxy 的空闲超时timeout client、HAProxy 到后端的连接建立超时timeout connect、还是后端响应超时timeout server。在日志里开启option httplog后每条请求日志都会带一个s服务端和ti总耗时字段能直接看出耗时卡在哪个环节。我排障时有个习惯用curl -v -o /dev/null -w time_total: %{time_total}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\n http://目标URL来分段测耗时。如果time_connect很大说明 TCP 握手就慢可能是网络问题如果握手很快但time_starttransfer大说明后端应用处理慢是应用层问题。6.3 会话保持失效与流量倾斜的排查会话保持失效最直接的表现是用户反复被要求重新登录。排查顺序是先确认请求里有没有带上会话 Cookie。我遇到过配置本身没问题但前端代码用的请求库默认不带 Cookie 的情况这跟在 HAProxy 层面的配置没关系。如果确认 Cookie 已携带还是失效检查 Cookie 插入的nocache参数。很多 CDN 或浏览器会自动缓存带 Set-Cookie 的响应如果没有加nocache后续请求把缓存的旧 Cookie 带回来就可能路由到错误的后端。流量倾斜则多半是source算法踩坑。某个办公网出口 IP 如果用户特别多这些用户的请求全部哈希到同一台后端那台后端就倒霉了。解决办法是改用 Cookie 插入做会话保持让流量在轮询算法下均匀分发。另外leastconn算法在长连接场景下能有效防止流量倾斜因为它每次都会挑当前连接数最少的后端不会出现“接客不均”的问题。6.4 独家避坑清单最后分享几个一般文档里不会写、但我真的踩过坑的细节第一defaults里的mode一定要根据业务区分别图省事全写http。我代理过一个 Redis 服务因为默认 mode 是 httpHAProxy 会把 Redis 的二进制协议当成 HTTP 来解析结果连接全部异常。TCP 服务必须显式设置mode tcp。第二maxconn别贪大。连接数不是越大越好每个连接都要占内存HAProxy 默认每个连接约 600B 内存100 万连接就是 600MB再算上缓冲区内存轻松上 GB。我建议 maxconn 按实际容量的 80% 设置给系统留出余量。第三转发真实客户端 IP 一定要配option forwardfor。如果没有这个配置后端日志里看到的全是 HAProxy 的 IP排障时想查某个用户的具体请求几乎不可能。但要注意如果后端已经有一个可信的代理层需要配合option forwardfor except 内网网段避免重复追加 X-Forwarded-For。第四配置文件改动后先用haproxy -c -f /etc/haproxy/haproxy.cfg验证再 reload。这个命令是最便宜的保险它可以帮你发现绝大多数语法错误和逻辑矛盾。有一次我漏写了两个空格直接 reload 导致全体后端被摘除从那以后每次改配置我都要验证至少三遍才敢动生产。做了这么多年入口层的稳定性工作我的一个核心体会是负载均衡器本身不是难点难的是它背后的那套治理思路——健康检查周期、超时容忍度、故障转移策略、监控告警这一整套机制需要配合你的业务节奏反复打磨。HAProxy 的配置语法并不复杂但它的行为模型非常精细值得花时间把每个参数的含义吃透。你踩过的每一个坑最后都会沉淀成那几条看起来毫不起眼、但关键时刻能救命的经验。 HAProxy高可用实战：从配置调优到架构落地
先说一句这两年线上出过好几次事故最后查下来都不是业务代码的问题而是流量入口的负载均衡层没扛住。后来我把入口从 Nginx 主备切换改成 HAProxy 主备双活再往后跑了快三年除了例行维护基本没再为入口层操过心。这篇文章就围绕 HAProxy 展开讲清楚它到底是什么、核心配置怎么写、关键参数怎么调、高可用方案怎么落地以及我在真实业务里踩过的坑和排查思路。如果你正在搭建负载均衡层或者想把手里的 Nginx 单点方案升级成更稳的入口架构这篇文章可以给你一份能直接照做的参考。1. HAProxy 的定位与选型思路1.1 HAProxy 到底解决了什么问题HAProxy 是一款开源的高性能 TCP/HTTP 负载均衡器核心作用就是把进入的请求按照某种策略分发给后端的多台服务器。它和 Nginx 最大的区别在于Nginx 本质是 Web 服务器负载均衡只是它的功能之一而 HAProxy 从诞生起就只专注于代理和分发没有静态文件处理、没有缓存模块把所有性能都用在请求转发上。我在实际使用中感受最深的一点是它对连接的处理非常精细。每个连接进来HAProxy 会维护独立的会话状态支持四层TCP和七层HTTP两种模式。四层模式只看源 IP 和端口直接转发原始数据包七层模式会解析 HTTP 头部、URL、Cookie 等信息然后基于这些内容做路由。这种分层设计让它的适用面很广——既能代理 MySQL、Redis 这类 TCP 服务也能做 Web 服务的七层分发。它解决的核心问题有三个流量分发把请求均匀打到多台后端、故障转移后端挂了自动摘除恢复后自动加回、会话保持同一个用户的请求始终落到同一台后端。这三个能力结合起来就能把一组普通服务器变成一个高可用的服务集群。1.2 选型对比HAProxy 与 Nginx、LVS 怎么选很多朋友一上来就问“HAProxy 和 Nginx 哪个好”其实这俩不完全是竞争关系。我见过不少团队用 Nginx 做入口再用 HAProxy 做 Nginx 后端的负载均衡也见过直接用 HAProxy 做入口后面挂 Nginx 处理静态文件。选型要看你的核心诉求对比维度HAProxyNginxLVS核心定位专职负载均衡/代理Web服务器反向代理内核态四层负载均衡七层处理能力强ACL 规则灵活强配合 Lua 更灵活弱主要工作在四层四层转发性能很高较高最高工作在内核态配置复杂度中等专业术语多简单直观较复杂依赖 ipvsadm会话保持多种算法健康检查依赖 upstream 配置依赖调度算法动态调整后端支持可通过 socket 在线操作需 reload支持但管理较繁琐这里要特别说下 LVS。LVS 工作在 Linux 内核态转发性能确实比 HAProxy 高但部署和运维成本也高而且对后端服务器的网络配置有要求比如 DR 模式需要配置 VIP 和 ARP 抑制。绝大多数业务场景HAProxy 的软件性能已经足够支撑每秒几万级别的请求没必要为了追求极限性能引入 LVS 的复杂度。我的建议是如果只是 Web 入口分发Nginx 足够如果在 Nginx 前面需要一层独立的流量入口或者在同一个入口同时代理 HTTP 和 TCP 服务选 HAProxy 更顺手。我目前的架构就是 HAProxy 做流量入口后面挂 Nginx 集群处理静态资源和反向代理各管一段互不干扰。2. 核心配置结构拆解2.1 三段式配置global、defaults、frontend/backendHAProxy 的配置文件结构非常清晰核心就三段global、defaults、以及成对的frontend和backend。global段配置进程级别的参数比如运行用户、日志、最大连接数、线程数、SSL 相关设置。这一段的参数一旦写错HAProxy 可能直接启动失败所以改完一定要记得做配置检查。defaults段是全局默认值给后面所有的 frontend/backend 提供默认参数。这里写得好的话后面每个服务只需要写自己独有的配置能省一大截重复代码。我习惯把mode、timeout、option这些通用项都放在 defaults 里。frontend段定义流量的入口监听某个 IP 和端口接收请求后用 ACL 规则判断“这个请求应该交给哪个 backend”。backend段定义一组后端服务器以及负载均衡算法、健康检查方式、会话保持策略等。你可以把 frontend 理解成公司前台backend 是各个业务部门。前台接到访客请求根据访客来意URL、域名、请求头引导到对应的部门backend部门里有多名员工后端服务器前台按照一定的规则负载均衡算法决定把活儿派给哪个员工。2.2 核心参数逐个解读mode、bind、balance、timeout在写配置之前有几个参数必须先吃透它们决定了整个代理的行为模式。mode只有两个可选值tcp和http。tcp是四层转发HAProxy 不解析报文内容适合数据库、消息队列等协议http是七层转发HAProxy 会解析 HTTP 请求行、头部、正文可以做 URL 路由、Cookie 会话保持、HTTP 重定向等高级操作。bind指定 HAProxy 监听哪个 IP 和端口。如果是 IPv4 就是bind *:80监听所有网卡的 80 端口还可以加ssl关键字启用 HTTPS。balance指定负载均衡算法。最常用的是roundrobin轮询请求依次分给每台后端适合处理能力对等的服务器leastconn是“谁当前连接数最少就把请求发给谁”适合长连接场景比如 WebSocket、数据库连接池source是对同一个源 IP 哈希取模保证同一个 IP 始终打到同一台后端实现简单的会话保持。timeout系列参数是排障时最容易被忽视的。timeout connect是 HAProxy 向后端发起连接的超时时间默认几秒就够timeout client是客户端空闲超时超过这个时间客户端还没发数据就断开timeout server是后端空闲超时。这三个值如果设置不合理会出现大量 504 或者连接被莫名断开的问题。我后面会专门讲一套合理的取值思路。2.3 一个可直接上手的完整基础配置说了这么多理论直接给一份我常用的基础配置模板你可以根据自己的业务修改后直接用global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /var/lib/haproxy/stats mode 600 level admin stats timeout 30s user haproxy group haproxy daemon maxconn 4096 nbthread 4 spread-checks 5 defaults log global mode http option httplog option dontlognull option forwardfor option http-server-close timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 10s frontend web_front bind *:80 default_backend web_servers backend web_servers balance roundrobin option httpchk GET /health.html server web1 192.168.1.11:8080 check inter 3s fall 3 rise 2 server web2 192.168.1.12:8080 check inter 3s fall 3 rise 2这份配置里埋了一个我踩过坑留下的细节option httpchk后面配置了健康检查路径/health.html。很多教程直接写option httpchk不写路径默认是OPTIONS /请求部分后端框架对 OPTIONS 方法的处理会比较慢甚至直接拒绝导致健康检查误判。我那次全站 502 就是这个问题改完路径立竿见影。3. 关键功能实操与参数调优3.1 健康检查主动探测与被动熔断的配合健康检查是负载均衡的命脉。后端服务器又不是永远不会出问题内存飙升、磁盘写满、代码死锁各种情况都可能导致服务假死。健康检查的作用就是持续探测后端是否真的能处理请求不能就自动摘掉。HAProxy 的健康检查分主动和被动两种。主动检查就是 HAProxy 定期向后端发起探测请求根据响应判断后端状态对应配置里的check关键字和inter、fall、rise三个参数。inter是探测间隔单位毫秒注意这里不写单位默认就是毫秒fall是连续失败多少次后标记为 DOWNrise是连续成功多少次后标记为 UP。这三个参数的取值很有讲究。inter太短会导致后端压力大因为健康检查本身也是请求太长又会导致故障发现不及时。我一般设置inter 3s也就是每 3 秒探测一次。fall 3意味着连续 3 次失败才摘除配合 3 秒间隔检测一个故障最长需要约 9 秒这个延迟在大多数场景下可以接受。rise 2意味着后端恢复后连续 2 次探测成功就重新加入避免偶发一次成功就上线导致抖动。被动检查也叫熔断机制对应两个参数maxconn和maxqueue。当某个后端的连接数达到maxconn上限HAProxy 不会再向它分发新请求如果还有排队队列maxqueue超过队列长度的请求会直接返回 503。被动检查是对主动检查的重要补充——主动检查只能发现“服务完全不可用”而被动检查能发现“服务还能响应但已经快扛不住了”的状态。3.2 会话保持的三种实现方式HTTP 服务经常需要把同一个用户的请求固定在同一个后端上典型场景就是登录态。如果用户登录时请求打到后端 A刷新页面时负载均衡又把请求分给了后端 B而后端没有做 session 共享那就直接掉登录了。实现会话保持有三种主流方式。第一种最简单用balance source。它是基于源 IP 哈希的调度算法同一个源 IP 会被哈希到同一个后端。缺点是如果用户通过手机网络切换基站导致出口 IP 变化会话就断了如果大量用户从同一个 NAT 出口访问流量会集中到少数几台后端上负载不均衡。第二种是 Cookie 插入对应配置backend web_servers balance roundrobin cookie SERVERID insert indirect nocache server web1 192.168.1.11:8080 cookie web1 check server web2 192.168.1.12:8080 cookie web2 checkHAProxy 给每个后端服务器指定一个 cookie 值这里是 web1 和 web2当用户第一次访问时HAProxy 在响应里插入一个名为SERVERID的 cookie值就是处理后端的标识。之后用户再带着这个 cookie 来HAProxy 直接根据 cookie 值路由不再走轮询。indirect表示如果请求本身已经带了SERVERID头就不覆盖nocache是告诉中间缓存不要缓存这个 cookie。第三种是 Cookie 前缀适合后端应用自己已经在种 session cookie 的场景。HAProxy 不改写后端的 cookie而是把自身的标识追加到已有 cookie 值前面类似SRVweb1; JSESSIONIDabc123。这种方式侵入性最小但要求后端 cookie 名必须是已知的。我的经验是能在应用层做 session 共享比如 Redis就尽量做会话保持只是兜底手段。会话保持会牺牲一定程度的负载均衡效果流量倾斜不可避免。但如果在迁移成本高、短期内必须平滑过渡的情况下Cookie 插入是性价比最高的方案。3.3 ACL 规则用请求内容做精细路由ACLAccess Control List是 HAProxy 七层能力最精华的部分。它允许你根据请求的任何特征——URL、域名、请求头、Cookie、HTTP 方法、源 IP——判断请求应该去哪个后端。这就让一个 HAProxy 实例能同时代理多个业务充当网关角色。一个典型的场景是 API 网关和静态资源分离frontend web_front bind *:80 # 请求 /api/ 开头的路径交给 api_backend acl is_api path_beg /api/ use_backend api_backend if is_api # 请求 img.example.com 域名交给 image_backend acl is_img hdr_dom(host) img.example.com use_backend image_backend if is_img default_backend web_servers backend api_backend balance leastconn server api1 192.168.1.21:8080 check server api2 192.168.1.22:8080 check backend image_backend balance roundrobin server img1 192.168.1.31:8080 check server img2 192.168.1.32:8080 check这段配置里有几个语法细节值得记住。path_beg是“路径以什么开头”的匹配器hdr_dom(host)是取Host请求头的域名部分做匹配use_backend ... if ...是条件路由语句多个条件可以or连接。ACL 还支持正则-i忽略大小写等修饰符非常灵活。除了路径和域名ACL 还可以做灰度发布。比如让某个特定源 IP 段或者某个特定 Cookie 值的用户访问新版本后端其他用户走旧版本。这个场景我后面会专门展开讲。3.4 TLS 终止与强制 HTTPS 跳转现在基本没有裸 HTTP 的服务了TLS 终止是负载均衡的标准操作。HAProxy 支持三种 SSL 模式TLS 终止后端用 HTTP、TLS 透传四层模式直接把加密流量转发、TLS 桥接先解密再按内容路由再重新加密转发给后端。最常见的配置是 TLS 终止证书放在 HAProxy 上后端服务器不处理加解密压力集中在入口层。配置方法是bind上直接加ssl关键字和证书路径frontend web_front bind *:80 bind *:443 ssl crt /etc/haproxy/certs/example.com.pem http-request redirect scheme https unless { ssl_fc } default_backend web_serversbind *:443 ssl crt后面的.pem文件里需要同时包含证书和私钥按“证书在前私钥在后”的顺序拼接这个格式容易被忽略。http-request redirect scheme https unless { ssl_fc }是强制跳转只要请求不是 SSL 连接ssl_fc是 SSL 连接标志就重定向到 HTTPS。如果你有多个域名证书文件可以放到一个目录下HAProxy 会自动按域名匹配bind *:443 ssl crt /etc/haproxy/certs/目录下的每个.pem文件名如果和域名匹配比如a.com.pemHAProxy 会在 SNI 握手时自动选择对应证书。这个特性让我免去了 reload 配置文件的操作新域名加证书只需要放文件到目录即可。4. 性能优化与高承载压测调优4.1 吞吐模型估算maxconn 到底设多大很多人设置maxconn全靠猜其实这个值是可以通过一个简单模型推算出来的。先想清楚你的后端处理能力假设每台后端服务器能同时处理 100 个并发请求你有 4 台后端那么理论支撑的总并发量是 400。如果你希望 HAProxy 不成为瓶颈它的maxconn至少要是这个数的 1.5 倍到 2 倍留出缓冲应对突发流量。也就是 600 到 800。但maxconn不只是配置文件里的一个数。每个连接都会消耗文件描述符fdLinux 单进程默认的 fd 上限是 1024撑不起大并发。我一般会同步修改系统参数ulimit -n 65535 echo fs.file-max 100000 /etc/sysctl.conf sysctl -p还要注意 HAProxy 有一种“过度订阅”机制。它允许在maxconn之外再接受一小部分连接tune.maxaccept用于应对瞬时流量尖峰。默认值是 100如果压测时发现连接数报表突然涨得很厉害可以适当调低这个值让 HAProxy 更平滑地处理连接突发。4.2 内核参数与网络栈调优清单HAProxy 性能发挥到极致光调它自己的参数是不够的Linux 内核网络栈往往才是瓶颈。我的/etc/sysctl.conf里长期保存着这样一组调优参数net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.ip_local_port_range 1024 65535 net.ipv4.tcp_tw_reuse 1 net.core.netdev_max_backlog 65535net.core.somaxconn决定内核 socket 监听队列长度如果设置太小高并发下会出现connection reset by peer的错误。net.ipv4.ip_local_port_range决定本地可用端口的范围在 HAProxy 向后端发起大量连接时每个连接都会占用一个本地端口范围太小会直接导致Cannot assign requested address的报错。tcp_tw_reuse允许回收 TIME_WAIT 状态的连接减少端口耗尽风险。调完这些参数记得用sysctl -p生效并且压测时要观察/proc/net/sockstat里的连接数分布确认没有达到上限。4.3 多线程模式与压测实践记录HAProxy 老版本是单进程单线程模型现在新版本支持nbthread参数启用多线程。我拿一台 4 核虚拟机做过对比单线程模式下用 wrk 压测每秒能处理约 3.5 万次简单 HTTP 请求开启nbthread 4后提升到 6.2 万左右。但注意不是线程越多越好还要同时设置cpu-map把线程绑定到物理核上避免线程在不同核之间跳动引发上下文切换开销global nbthread 4 cpu-map 1 0 cpu-map 2 1 cpu-map 3 2 cpu-map 4 3除了线程tune.bufsize和tune.maxrewrite也影响性能。tune.bufsize默认 16384 字节表示每个连接的内存缓冲区大小如果你的请求头特别大比如很多 Cookie可能需要调大否则 HAProxy 会返回 400。tune.maxrewrite是缓冲区内用于 HTTP 头重写的空间默认 1024 字节如果配置了很多重写规则比如 X-Forwarded-For也要适当调大。压测方法我建议用 wrk 或者 h2load 做 HTTP 压测用haproxy -c -f /etc/haproxy/haproxy.cfg检查配置合法性再用haproxy -d前台调试模式观察运行情况。压测时重点看三个指标QPS每秒请求数、连接成功率、P99 延迟。4.4 监控与日志掌握实时状态HAProxy 自带一个监控页面通过stats socket暴露 Unix Socket配合stats admin可以实现在线启用/禁用后端服务器。在 frontend 里加一段配置就能打开 HTTP 监控页面frontend stats_front bind *:8404 stats enable stats uri /stats stats refresh 30s stats auth admin:your_password通过socat连接到 stats socket 可以做动态管理。滚动更新后端时我经常用这一招echo disable server web_servers/web1 | socat stdio /var/lib/haproxy/stats # 等待 web1 上的存量请求处理完 echo enable server web_servers/web1 | socat stdio /var/lib/haproxy/stats这比直接 kill 后端进程安全得多因为 HAProxy 会先停止向 web1 分发新请求但已经建立的连接还能继续处理完。这正是“优雅下线”的实现方式。配合 Prometheus 的 haproxy_exporter还可以把后端队列长度、健康状态、会话数这些关键指标接到 Grafana 上做告警。5. 高可用部署与容器化实践5.1 Keepalived 实现主备漂移HAProxy 本身是无状态的它可以挂掉但不能让入口地址跟着消失。业界最经典的做法是 HAProxy Keepalived 组合两台服务器各跑一个 HAProxy共享一个虚拟 IPVIPKeepalived 负责探活和 VIP 漂移。主备节点的 keepalived 配置核心如下主节点示例vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass your_password } virtual_ipaddress { 192.168.1.100 } }备节点把state改成BACKUP、priority改成 90其他参数保持一致。virtual_router_id在同一个网段内必须唯一否则两台机器会互相冲突。Keepalived 默认每 1 秒发送一次 VRRP 心跳主节点挂了最多 3 秒内 VIP 就会漂移到备节点。但这里有个细节Keepalived 只能探测自己的进程状态如果 HAProxy 卡死了但进程还在VIP 不会漂移。稳妥的做法是写一个探活脚本检测 HAProxy 的健康状态异常时直接停掉 keepalived 进程触发 VIP 漂移。我在实践中用的探活脚本大致逻辑是#!/bin/bash if ! pgrep -x haproxy /dev/null; then systemctl stop keepalived fi # 通过 stats socket 检测后端健康状态 if ! echo show stat | socat stdio /var/lib/haproxy/stats | grep -q web_servers/web1.* UP; then exit 1 fi5.2 Docker 快速部署 HAProxy容器化部署 HAProxy 非常简单官方镜像haproxy已经包含编译好的二进制挂载配置文件即可docker run -d \ --name haproxy \ --restart unless-stopped \ -p 80:80 \ -p 443:443 \ -p 8404:8404 \ -v /etc/haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro \ -v /etc/haproxy/certs/:/etc/haproxy/certs/:ro \ haproxy:2.8有一点要特别注意在容器里chroot可能因为权限问题导致启动失败所以容器化部署时我会把global段里的chroot参数注释掉。另外stats socket的路径要放在容器内的可写目录或者直接把 socket 文件的权限配置对。如果配置有改动可以用docker kill -s HUP haproxy触发优雅重载HAProxy 会用新配置启动新进程再逐步替换旧进程连接不会中断。这一点比直接docker restart友好得多。5.3 对接 KubernetesIngress Controller 选型在 Kubernetes 环境里HAProxy 有两个切入点一是作为 Nginx Ingress Controller 前面的硬入口二是直接使用 HAProxy Ingress Controller。HAProxy 官方的 Ingress Controller 和 Nginx Ingress 相比优势在于配置模型更静态CRD 支持的语义更丰富。比如 Nginx Ingress 的 annotation 五花八门改一个配置经常要等 controller 重新生成配置再 reload而 HAProxy Ingress 直接维护一份 ConfigMap改动逻辑更透明重载更可控。我团队目前的生产环境是双墙方案每个 K8s 集群外面放两个 HAProxy 实例组成 VIP流量先进 VIP再进集群的 NodePort集群内部用 Nginx Ingress 做南北向路由。这样做的原因是 NodePort 本身不带健康检查后端 Pod 挂了一两个很容易出现请求打到死节点上重试超时而 HAProxy 侧的健康检查能直接探到 NodePort 端口的状态有几百毫秒级别的故障感知能力比 K8s 内部的 Readiness 探针反应更直接。灰度发布我习惯在 HAProxy 层先做一层让绝大部分流量走 v1 版本的 Service少量流量比如公司内部测试 IP 段走 v2 版本。这个需求用 Nginx Ingress 的 annotation 也能实现但 HAProxy 的 ACL 规则写起来更直观改动的可见性也更强。6. 常见问题与排查技巧实录6.1 后端全部标记 DOWN 的排查思路这是负载均衡场景最吓人的故障所有后端突然从监控页面上看都是 DOWN业务直接瘫痪。我排查这种问题的顺序是这样的第一步确认健康检查路径是否返回了预期状态码。option httpchk GET /health.html期望收到 2xx/3xx 状态码如果后端代码更新后/health.html返回了 500 或者变成了 302健康检查就会误判。我遇到过最坑的一次是后端升级后/health.html变成了一个必须登录才能访问的页面返回 302HAProxy 认为后端异常直接摘除了。第二步检查后端防火墙是否拦截了 HAProxy 的探测源 IP。inter 3s意味着每 3 秒就有一次探测请求如果后端有 fail2ban 之类的防护软件可能会误判为恶意扫描把 HAProxy 的 IP 封掉。排查方式是登录后端服务器tail -f看访问日志里有没有来自 HAProxy 地址的请求。第三步看 haproxy 日志里有没有连接被拒的信息。健康检查报错通常会在日志中体现为ECONNREFUSED或者timeout根据具体报错再定位是网络问题还是应用问题。这里有个经验值分享给你健康检查的inter不要设置太极端。有的团队为了快速感知故障把inter设为 500ms结果后端某个接口本身就要 1 秒才能返回几乎每一次探测都超时后端被误摘。健康检查本身不应该给后端制造负担inter 3s以上是比较稳妥的起点。6.2 502 和 504 报错背后的真实原因客户端看到 502 或 504第一反应是后端应用挂了但很多时候根因在负载均衡层。我梳理了一下最常见的几种情况502 Bad Gateway 通常是 HAProxy 和后端服务器之间的 TCP 连接建立失败或者后端返回了非法响应。比如后端服务器的 backlog 队列满了内核直接拒绝新连接这时候 HAProxy 转发请求就会失败。用netstat -anp | grep :8080 | grep SYN能确认是不是半连接队列积压。也有可能是后端返回的响应头格式不合法比如缺少Content-Length头且没有Connection: closeHAProxy 会判定响应无效直接断开。504 Gateway Timeout 的本质是后端处理请求超时。这时候要区分是哪个超时被触发客户端到 HAProxy 的空闲超时timeout client、HAProxy 到后端的连接建立超时timeout connect、还是后端响应超时timeout server。在日志里开启option httplog后每条请求日志都会带一个s服务端和ti总耗时字段能直接看出耗时卡在哪个环节。我排障时有个习惯用curl -v -o /dev/null -w time_total: %{time_total}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\n http://目标URL来分段测耗时。如果time_connect很大说明 TCP 握手就慢可能是网络问题如果握手很快但time_starttransfer大说明后端应用处理慢是应用层问题。6.3 会话保持失效与流量倾斜的排查会话保持失效最直接的表现是用户反复被要求重新登录。排查顺序是先确认请求里有没有带上会话 Cookie。我遇到过配置本身没问题但前端代码用的请求库默认不带 Cookie 的情况这跟在 HAProxy 层面的配置没关系。如果确认 Cookie 已携带还是失效检查 Cookie 插入的nocache参数。很多 CDN 或浏览器会自动缓存带 Set-Cookie 的响应如果没有加nocache后续请求把缓存的旧 Cookie 带回来就可能路由到错误的后端。流量倾斜则多半是source算法踩坑。某个办公网出口 IP 如果用户特别多这些用户的请求全部哈希到同一台后端那台后端就倒霉了。解决办法是改用 Cookie 插入做会话保持让流量在轮询算法下均匀分发。另外leastconn算法在长连接场景下能有效防止流量倾斜因为它每次都会挑当前连接数最少的后端不会出现“接客不均”的问题。6.4 独家避坑清单最后分享几个一般文档里不会写、但我真的踩过坑的细节第一defaults里的mode一定要根据业务区分别图省事全写http。我代理过一个 Redis 服务因为默认 mode 是 httpHAProxy 会把 Redis 的二进制协议当成 HTTP 来解析结果连接全部异常。TCP 服务必须显式设置mode tcp。第二maxconn别贪大。连接数不是越大越好每个连接都要占内存HAProxy 默认每个连接约 600B 内存100 万连接就是 600MB再算上缓冲区内存轻松上 GB。我建议 maxconn 按实际容量的 80% 设置给系统留出余量。第三转发真实客户端 IP 一定要配option forwardfor。如果没有这个配置后端日志里看到的全是 HAProxy 的 IP排障时想查某个用户的具体请求几乎不可能。但要注意如果后端已经有一个可信的代理层需要配合option forwardfor except 内网网段避免重复追加 X-Forwarded-For。第四配置文件改动后先用haproxy -c -f /etc/haproxy/haproxy.cfg验证再 reload。这个命令是最便宜的保险它可以帮你发现绝大多数语法错误和逻辑矛盾。有一次我漏写了两个空格直接 reload 导致全体后端被摘除从那以后每次改配置我都要验证至少三遍才敢动生产。做了这么多年入口层的稳定性工作我的一个核心体会是负载均衡器本身不是难点难的是它背后的那套治理思路——健康检查周期、超时容忍度、故障转移策略、监控告警这一整套机制需要配合你的业务节奏反复打磨。HAProxy 的配置语法并不复杂但它的行为模型非常精细值得花时间把每个参数的含义吃透。你踩过的每一个坑最后都会沉淀成那几条看起来毫不起眼、但关键时刻能救命的经验。