13.10.3 配置误区与最佳实践

本节聚焦 HAProxy 运维中的配置误区与最佳实践，结合生产场景给出可执行配置、排错命令与练习，帮助避免隐性风险并提升稳定性与可维护性。

原理草图（请求流与关键点）#

常见配置误区#

全局与默认段混用导致参数不生效
将应写在 defaults 或 backend 的参数放在 global，如 timeout、option 等，实际不生效。
超时参数未成体系设置
仅配置 timeout connect，忽略 timeout client/server/queue/http-request，导致随机 504 或连接断开。
健康检查与真实服务不匹配
httpchk URL/端口不一致或返回码未匹配，节点频繁上下线。
会话保持策略混用
同时使用 cookie、source、stick-table，导致粘滞失效。
日志配置不完整
未启用 option httplog 或未定义 log-format，排障困难。
SSL 证书链/SNI错误
证书链不完整或未配置 SNI，多域名握手失败。
权重不合理
弱节点权重与强节点一致，成为瓶颈。
未限制连接与并发
未配置 maxconn，突发流量压垮主机。
缺少运行时管理接口
未启用 stats 或 admin socket，无法动态下线。
TCP/HTTP 模式混用
TCP 模式使用 HTTP 选项，或 HTTP 模式缺少必要优化。

最佳实践建议（含配置示例）#

1) 统一分层与超时基线#

# /etc/haproxy/haproxy.cfg
global
    log /dev/log local0
    maxconn 50000
    user haproxy
    group haproxy
    stats socket /var/run/haproxy.sock mode 600 level admin

defaults
    mode http
    log global
    option httplog
    timeout connect 5s
    timeout client 60s
    timeout server 60s
    timeout http-request 10s
    timeout queue 30s

预期效果：所有 frontend/backend 继承一致超时，避免随机超时。

2) 健康检查与业务对齐#

backend be_app
    option httpchk GET /healthz HTTP/1.1\r\nHost:\ example.com
    http-check expect status 200
    server app1 10.0.0.11:8080 check inter 3s fall 3 rise 2
    server app2 10.0.0.12:8080 check inter 3s fall 3 rise 2

预期效果：仅当返回 200 才视为健康，避免误判。

3) 会话保持策略单一#

backend be_web
    balance roundrobin
    cookie SRV insert indirect nocache
    server web1 10.0.0.21:80 check cookie w1
    server web2 10.0.0.22:80 check cookie w2

预期效果：客户端携带 SRV cookie，稳定粘滞。

4) 连接上限与队列控制#

frontend fe_http
    bind *:80
    maxconn 20000
    default_backend be_web

backend be_web
    maxconn 10000

预期效果：并发可控，避免进程被打满。

5) 监控与运行时管理接口#

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 5s
    stats auth admin:Admin@123

预期效果：访问 http://<ip>:8404/stats 查看后端状态。

关键命令与排错流程（含解释）#

配置校验与热加载#

# 1) 校验配置语法
haproxy -c -f /etc/haproxy/haproxy.cfg

# 2) 无损重载（systemd）
systemctl reload haproxy

# 3) 查看进程与监听
ss -lntp | grep haproxy

预期效果：校验通过、端口监听正常。

运行时管理（动态下线/上线）#

# 下线 server
echo "disable server be_web/web1" | socat stdio /var/run/haproxy.sock

# 上线 server
echo "enable server be_web/web1" | socat stdio /var/run/haproxy.sock

预期效果：不重启进程即可摘除/恢复节点。

日志快速定位#

# 观察近 100 条 HAProxy 日志（RHEL/CentOS）
journalctl -u haproxy -n 100 --no-pager

# 或查看 rsyslog 文件
tail -n 100 /var/log/haproxy.log

关注字段：Tq/Tw/Tc/Tr/Tt 时延、status 状态码、backend/server 目标节点。

健康检查验证#

# 从 HAProxy 主机直接检查健康检查 URL
curl -I http://10.0.0.11:8080/healthz

预期效果：返回 HTTP/1.1 200 OK。

安装与环境准备（示例）#

# Debian/Ubuntu
apt update && apt install -y haproxy socat

# RHEL/CentOS
yum install -y haproxy socat

# 启用服务
systemctl enable --now haproxy

典型错误与修复示例#

错误1：timeout 放在 global 不生效#

现象：请求随机断开
修复：移动到 defaults

# 错误写法
global
    timeout client 60s

# 正确写法
defaults
    timeout client 60s

错误2：HTTP 选项用于 TCP 模式#

现象：配置校验报错
修复：TCP 模式删除 option httplog/httpchk，或将 mode 改为 http

defaults
    mode tcp
# 若需要 HTTP 功能
# defaults
#     mode http

错误3：证书链不完整#

现象：浏览器提示证书错误
修复：将证书链拼接为完整 PEM

cat server.crt intermediate.crt > /etc/haproxy/certs/site.pem

练习与自测#

练习1：配置健康检查
在 backend 中配置 /healthz 检查，并用 curl -I 验证返回 200。
练习2：模拟节点下线
使用 socat 下线 web1，观察 stats 页面状态变化。
练习3：压测与连接上限
用 ab -n 10000 -c 200 http://<vip>/ 测试，观察 maxconn 是否生效与排队。

生产落地检查清单#

是否通过 haproxy -c -f 校验配置
是否明确设置超时参数（connect/client/server/queue/http-request）
是否能访问 stats 并看到后端状态
健康检查 URL/返回码是否与业务一致
日志是否包含关键字段（状态码、耗时、后端）
是否设置 maxconn 与系统 ulimit 匹配
是否有动态摘除与回滚方案