HAProxy CPU 很低却连接超时：检查每秒连接上限 maxconnrate

高峰期浏览器出现 ERR_CONNECTION_TIMED_OUT，HAProxy CPU、内存和当前连接数都不高，配置却有 maxconnrate 1000。这种情况下，限制可能落在每秒新连接数，而不是并发连接数或计算资源。先检查连接接入速率及实际限制，不能只看 CPU 判断容量还有余量。

本文针对配置了全局 maxconnrate 的 HAProxy。这个设置达到上限时会暂停接受连接，可能使客户端连接等待或超时；单凭超时和低 CPU，不能确定一定命中它。网络丢包、监听积压、其他连接或会话限制仍需按观测结果区分。

maxconn 与 maxconnrate 是不同约束

以下是说明差异的配置片段，不是容量建议：

global
    maxconn 150000
    maxconnrate 1000

maxconn 控制并发连接上限，maxconnrate 控制每进程每秒连接接入上限。当前连接远少于 150000，不代表每秒新建速率没有达到 1000。一个长连接维持很久，和很多短连接频繁建立、断开，对这两类限制的压力不同。

每秒 HTTP 请求也不等于每秒新连接。连接复用、多路复用和客户端连接行为都会改变对应关系；不能把请求数固定乘二，再称其为准确的连接速率。线程数增加也不会自动把每进程的这个限制翻倍。

这里沿用 HAProxy 1.8 中已有的限制名称，相关规则也适用于当前 3.2 文档。旧配置中的 nbproc、旧 TLS 参数和内核调优项不应顺带复制到当前部署，先使用实际版本和运行配置。

在故障时段查看接入限制与峰值

从已有、受权限控制的 Runtime API 或监控读取 show info，查看实际处理流量的工作进程。该命令是 Runtime API 命令，不是直接交给 shell 的可执行文件；连接方式按既有 socket 管理流程使用，不为这次排查把管理接口暴露到公网。

重点对应 ConnRate、ConnRateLimit、MaxConnRate，并结合 CurrConns、Maxconn 判断速率与并发限制。配置文件里的值还可能被运行时变更覆盖，应确认正在运行的限制，而不是只看磁盘上一份旧配置。

在故障时段连续观察。一次低频采样看到 ConnRate 很低，不能排除之前的短时突发；历史峰值也只说明某时到过该速率，不证明当前每次超时都由它造成。多进程或多实例环境中，确认监控连接的是哪一个实例、进程以及统计时间范围。

如果连接速率接近限制、超时随突发接入出现，可将这个限制列为重点验证对象。若并发达到 maxconn，先查并发限制；若接入速率没有对应证据，继续检查其他限额、网络和后端队列，不把删除 maxconnrate 当作统一修复。

调整保护值之前，先确认后端能承担新增流量

maxconnrate 本来可以保护服务。提高或移除它，会让更多连接进入处理路径，可能增加 TLS、内存、文件描述符和后端压力。CPU 当时低不等于整个链路可以无限接入。

先保留原配置和实际运行值，在受控测试或维护安排下，以明确的容量目标调整单一限制。同时观察接入延迟、错误率、后端资源和请求成功率，避免一次修改并发上限、超时和内核参数，使结果无法判断。

通过配置变更时，校验后按现有方式平滑重载，并确认新工作进程实际取得设置。Runtime API 也支持运行时调整连接速率，但这类操作会立即影响各 frontend，且不等同于持久修改配置；采用时要记录新旧值和对应进程，安排恢复，不只留下无法追踪的临时状态。

如果限额仍有必要，可在容量允许范围内调整，同时减少不必要的连接 churn。连接复用是否可改，应按应用协议和现有超时策略验证，不能仅为降低数值强制改变 WebSocket 等业务行为。

验收要看高峰接入，不只看正常时段

在相同业务条件下，确认原来的连接建立超时减少，实际请求成功，后端没有出现新的过载；同时核对运行中的限额与变更目标一致。普通时段能够访问并不能证明高峰问题已经消失。

若后端压力或错误率上升，恢复原配置与实际运行限制，按原流程重载或撤回运行时变更。降低限制仍可能使新的突发连接等待，因此回退后应继续处理容量需求；保留变化前后的指标，不能把服务重新启动后的短暂低流量当成修复证据。