HAProxy单节点压满千兆/万兆带宽的关键在于绕过内核瓶颈、协同优化网卡与CPU，并精准控制连接生命周期；盲目调高maxconn易触发conntrack耗尽或TIME_WAIT拥塞，需同步调大ulimit-n、net.core.somaxconn、ip_local_port_range等系统参数，合理配置timeout闭环、mode选择及健康检查策略。
HAProxy 单节点跑满千兆甚至万兆带宽，关键不在“开多少线程”或“堆多大 maxconn”，而在于绕过内核瓶颈、压榨网卡与 CPU 协同效率，并让连接生命周期可控。盲目调高 maxconn 到 10 万却忽略 timeout client 和 timeout server 的协同，反而会快速耗尽连接跟踪表（conntrack）或触发 TIME_WAIT 拥塞。
怎么设 global 区的资源上限才不翻车
默认 maxconn 是 4000，远低于硬件能力；但直接写 maxconn 100000 很可能失败——系统级限制没同步放开。
-
ulimit -n必须 ≥maxconn+ 10%（留 buffer），建议设为200000并写入/etc/security/limits.conf -
net.core.somaxconn和net.ipv4.ip_local_port_range需调大：前者至少65535，后者建议1024 65535 -
nbproc 1是安全起点；多进程只在 NUMA 架构且后端跨 socket 时才有收益，否则用nbthread auto更稳（HAProxy 2.2+） - 禁用
debug和quiet—— 日志刷屏会吃光 CPU，生产环境用log 127.0.0.1 local3 notice即可
defaults 里 timeout 怎么配才不堆积连接
超时参数不是孤立值，它们构成一个闭环：客户端断连、建连失败、后端响应慢、队列等待太久，全靠这组 timeout 控制回收节奏。设错一个，连接就卡在某环节不动。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
timeout connect：必须 ≤ 后端服务的accept()延迟，通常设5s；设成300s会导致 SYN 队列积压 -
timeout client和timeout server要对齐：比如都设60s，避免一端已关闭另一端还在发包 -
timeout http-request建议10s，防慢速 HTTP 攻击（如 Slowloris） -
timeout queue设太小（如1s）会让健康后端被误踢；设太大（如30s）则故障转移延迟高；推荐5s～10s
mode tcp 还是 mode http？选错直接丢一半吞吐
四层（mode tcp）吞吐比七层高 30%～50%，因为跳过了 HTTP 解析和重写逻辑。但如果你需要按 Host 或 path 路由，就必须用 mode http，且要启用 option http-server-close 来复用后端连接。
- 纯 API 网关、Redis 代理、gRPC TLS 终止 → 无条件选
mode tcp - Web 前端 + 静态资源分离 → 必须
mode http，并加acl规则，但别滥用req.hdr多层匹配，每多一层解析就多几微秒延迟 - HTTPS 终止场景：前端用
mode tcp接 TLS 流量，后端用mode http处理解密后请求，这是最常见也最稳的拆分法 - 注意：
option httpchk只在mode http下生效；mode tcp只能用option tcp-check发送原始字节探活
后端算法和健康检查怎么避免雪崩
高并发下，一个后端节点响应变慢，若健康检查不敏感或负载算法不自适应，流量仍会持续打过去，最终拖垮整组。
- 别用
roundrobin处理长连接服务（如 WebSocket）；改用leastconn，它看的是当前活跃连接数，不是请求数 -
check inter 2000 rise 2 fall 3是平衡灵敏度与误杀的常用组合：2 秒探测一次，连续 2 次成功才上线，3 次失败才下线 - 给后端加
maxconn 2000限流，防止 HAProxy 把所有连接都塞给单台机器 - 如果后端是 Kubernetes Service，务必关掉
http-check send-state，避免 HAProxy 主动发送状态头干扰 service mesh 流量
真正压到万兆的关键点，往往藏在 sysctl 调优和网卡 RSS 队列绑定上，HAProxy 配置只是最后一环。别只盯着配置文件改数字，先确认 ethtool -l eth0 显示的接收队列数是否 ≥ CPU 核数，再看 cat /proc/interrupts 是否有某个 CPU 被软中断打满 —— 这些才是吞吐上不去的真实瓶颈。
