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: the L402 aware reverse proxy

安装并运行 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 被软中断打满 —— 这些才是吞吐上不去的真实瓶颈。