HAProxy高并发关键在于转发策略合理、底层资源协同及健康检查与超时协同设计；四层适合非HTTP低延迟场景，七层支持精细路由但开销略高；超时参数须协同配置，负载算法按场景选择，健康检查需精准有效。
HAProxy 处理高并发请求，关键不在于堆参数，而在于转发策略的合理性 + 底层资源协同 + 健康检查与超时协同设计。配置得当，单节点轻松支撑 4 万+ 并发连接；配错一个 timeout 或调度算法，可能刚到几千并发就出现连接堆积、503 或后端雪崩。
明确转发层级：四层还是七层？
选错层级是高并发下性能瓶颈的常见源头：
- 四层（TCP）转发：适合数据库、Redis、SSH、游戏服务等非 HTTP 协议，或对首字节延迟极度敏感的场景。开销最小，吞吐最高，但无法解析 URL、Header、Cookie。
- 七层（HTTP/HTTPS）转发：适合 Web 应用、API 网关、动静分离、ACL 路由等。支持基于路径、域名、请求头、参数的精细调度，但需解包 HTTP，CPU 开销略高。
高并发 Web 场景若只需简单轮询且无业务路由需求，优先用 mode tcp；若需按 /api/ 和 /static/ 分流，必须用 mode http 并启用 option httpchk 健康检查。
核心超时参数必须协同设置
超时值过短会导致连接频繁中断；过长则积压失效连接，耗尽 maxconn。所有 timeout 单位默认为毫秒，但推荐显式写 s（秒）避免歧义：
-
timeout connect 5s：HAProxy 连接后端服务器的建立上限（含 TCP 握手、TLS 握手），建议 ≤ 后端服务的 listen backlog 接受能力。 -
timeout client 60s：客户端空闲等待时间（如浏览器未发完请求），不宜超过前端 CDN 或 Nginx 的 keep-alive timeout。 -
timeout server 60s：后端处理请求并返回响应的总时限，应 ≥ 后端最长业务逻辑耗时（如报表导出）+ 网络 RTT。 -
timeout http-request 10s：HTTP 请求头接收超时，防慢速攻击（Slowloris）。 -
timeout queue 30s：请求在队列中等待可用后端连接的时间，过高会掩盖后端容量不足问题。
注意：timeout client 和 timeout server 必须大于等于 timeout http-keep-alive（默认 60s），否则长连接会被提前断开。
选择合适的负载均衡算法
算法直接影响连接分布效率和后端压力均衡度：
-
balance roundrobin：简单轮询，适合后端性能均一、无状态服务（如标准 API）。高并发下最稳定。 -
balance leastconn：按当前活跃连接数分发，更适合长连接、响应时间波动大的服务（如 WebSocket、文件上传接口）。 -
balance source：源 IP 哈希，保证同一客户端始终打到同一后端（会话保持基础），但 NAT 环境下易倾斜，慎用于公网入口。 -
balance uri或balance url_param：适用于 CDN 回源、缓存一致性要求高的场景，确保相同资源路径总落在同一节点。
避免使用 static-rr（权重静态轮询）在动态扩容缩容场景——它不感知后端实时负载，容易造成“越忙越分流量”。
启用有效健康检查，防止雪崩
高并发下，一个后端宕机若未及时摘除，流量会持续打过去，触发级联失败：
- 四层检查：
option tcp-check+tcp-check connect，轻量快速，适合 DB/Redis。 - 七层检查：
option httpchk GET /health，配合http-check expect status 200，更精准判断业务可用性。 - 检查频率：
inter 2s（间隔）、fall 3（连续失败 3 次下线）、rise 2（恢复 2 次上线），平衡灵敏度与误判。 - 务必开启
check参数（如server app1 10.0.3.122:8080 check inter 2000 rise 2 fall 3），否则健康检查不生效。
别依赖 “心跳包” 或 “端口通” 就认为服务健康——HTTP 返回 500 或 404 也该被识别为异常。
不复杂但容易忽略。
