haproxy默认配置无法跑满万兆网卡带宽，主因是单进程、未禁用nagle算法及内核socket队列过小；需配置nbproc、cpu-map、tcp-nodelay及调大somaxconn等参数。
HAProxy 是目前最成熟、最可控的七层负载均衡方案，但“高性能”不等于开箱即用——它高度依赖配置粒度、内核参数和后端健康检查逻辑。
为什么默认配置跑不满网卡带宽
常见现象是压测时 haproxy 进程 CPU 不高，但吞吐卡在 1–2 Gbps，远低于万兆网卡能力。根本原因不是 HAProxy 本身慢，而是默认启用 nbproc 1（单进程）、未关闭 tcp-nodelay 冗余等待、且内核 socket 队列过小。
- 必须显式设置
nbproc为 CPU 核心数（如nbproc 4），并搭配cpu-map绑定核心，避免线程争抢 - 在
defaults或frontend中加option tcp-nodelay，禁用 Nagle 算法，降低小包延迟 - 调大内核参数：
net.core.somaxconn=65535、net.ipv4.ip_local_port_range="1024 65535"，否则连接建立阶段就丢包
如何写真正可靠的七层健康检查
用 option httpchk 做 HTTP 检查时，90% 的故障源于路径、状态码或超时配置失当。比如后端服务返回 HTTP/1.1 200 OK 但 body 是 JSON {"status":"ok"}，默认检查会通过；可一旦后端中间件（如 Nginx）返回 302 跳转，httpchk 就判定失败——这不是后端挂了，是检查太“死板”。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
http-check send hdr Host myapp.example.com携带真实 Host 头，避免虚拟主机路由错乱 - 明确指定期望状态码：
http-check expect status 200，或更宽松地匹配正则：http-check expect rstring ^{"status":"ok"} - 把超时拆开：在
backend中设timeout check 3s，比全局timeout http-keep-alive更精准
SSL 卸载后如何透传真实客户端 IP
直接在 frontend 里用 bind *:443 ssl crt /etc/haproxy/certs.pem 后，后端拿到的 REMOTE_ADDR 全是 HAProxy 本机 IP。这不是 HAProxy 的 bug，而是 HTTPS 流量解密后走的是纯 HTTP 转发，原始 TCP 连接信息已丢失。
- 必须在
frontend加option forwardfor，让 HAProxy 自动插入X-Forwarded-For头 - 如果后端是 Nginx，需配
set_real_ip_from 10.0.0.0/8;+real_ip_header X-Forwarded-For;才能信任该头 - 更安全的做法是用 PROXY protocol：在
frontend加send-proxy-v2，后端服务（如 Nginx 1.13+）开启proxy_protocol on;，直接传递原始 IP 和端口，不依赖 HTTP 头
为什么 reload 后连接中断、session 丢失
执行 systemctl reload haproxy 或 haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) 时，旧进程会等当前连接自然结束才退出。但若配置中没启用会话保持或连接复用，用户刷新页面就可能落到不同后端，导致登录态失效。
- 在
backend中启用balance source或balance cookie SERVERID insert indirect nocache，前者按客户端 IP 哈希，后者靠 Cookie 绑定 - 关键业务务必加
timeout client 30s和timeout server 30s，避免 reload 时旧连接僵死拖慢进程退出 - reload 前先用
haproxy -c -f /etc/haproxy/haproxy.cfg验证语法，配置错误会导致新进程启动失败，旧进程被强制 kill，瞬间全量断连
真正难的从来不是写对那几行 bind 和 server，而是理解每个 timeout 参数作用域、搞清 http-check 和 tcp-check 的触发时机差异、以及 reload 时父子进程信号传递的细节——这些地方一错，流量就静默受损，监控还未必报警。
