技术帮助 · 发布时间：
攻击流量经过清洗后仍可能形成明显的业务请求高峰。出现超时、错误率上升或页面变慢时，先确认瓶颈是否真的在回源连接：对照清洗侧请求量、源站活跃连接数、连接等待队列和后端响应时间。攻击流量清洗期间业务回源连接数耗尽的调优措施，应先找出连接被谁占用，再逐项调整，避免盲目扩容。
1. 先确认连接耗尽发生在哪一层
回源连接池、接入代理和应用服务可能各自有连接上限。查看监控中活跃连接数、连接建立失败数、等待队列、文件描述符使用量，以及上游连接耗时和 5xx 比例；再对比清洗前后的变化。若代理连接数已满但后端响应正常，优先检查代理池配置；若连接数持续增长且响应时间变长，后端变慢也可能是根因。
- 确定告警对应的代理、应用实例和时间段。
- 对照各层连接上限、当前占用和队列长度，找出最先触顶的环节。
- 保留调整前的指标与配置，逐项变更并观察错误率和延迟。
2. 检查长连接复用与连接池
如果每个请求都新建回源连接，握手和连接关闭会带来额外开销。检查代理到源站是否启用长连接复用，以及空闲连接保留时间、每个后端的连接池上限是否与应用能力匹配。以 Nginx 等反向代理为例，应同时核对上游连接复用配置和后端是否支持持久连接；只提高连接池上限，可能把压力转移给应用。
调整时先小幅增加可复用连接，并观察空闲连接数、连接建立速率和后端资源。若连接长期空闲占用资源，可缩短空闲保留时间；若请求频繁建立新连接，再检查代理与后端的协议及持久连接设置是否一致。
3. 限制突发并发，避免队列失控
清洗并不意味着业务请求一定恢复到平时水平，合法访问也可能集中到达。为单个后端设置合理并发上限，并在可控范围内使用排队或限流；超过处理能力的请求应尽早返回可识别的错误，而非无限等待并占住连接。设置值要结合压测、实例数和请求耗时确定，不存在适用于所有业务的固定数字。
4. 校准超时与重试，防止连接被拖住
连接超时、响应超时和客户端等待时间应区分设置。超时过长会让慢请求长期占用连接；超时过短则可能把正常的慢响应误判为失败。检查代理、应用和调用方的超时顺序，并限制重试次数。多个层级同时重试时，请求量会叠加，形成重试风暴；对非幂等操作尤其要谨慎，不能简单地对所有失败请求自动重试。
5. 排查后端变慢与容量分配
连接耗尽往往是结果而非起点。检查应用线程或工作进程是否繁忙、依赖服务是否变慢，以及请求是否集中落到少数实例。可在确认健康检查有效后，将流量均匀分配到健康实例；有扩容条件时按监控逐步增加实例，并验证连接上限、文件描述符和下游容量同步足够。必要时对非关键请求做降级，优先保住核心业务。
推荐排查顺序
- 定位首先触顶的连接层，确认连接池与队列。
- 核对长连接复用，减少不必要的新建连接。
- 按后端处理能力设置并发上限与排队策略。
- 收敛超时和重试，避免失败放大请求量。
- 检查实例分布和后端耗时，再决定扩容或降级。
每次只改一类参数，并观察活跃连接、等待队列、响应延迟和错误率是否共同改善。这样处理攻击流量清洗期间业务回源连接数耗尽的调优措施，既能缓解连接压力，也能避免把故障推向后端。
常见问题
提高连接池上限就能解决吗？
不一定。后端处理能力不足时，提高上限可能加重拥塞，应先确认瓶颈位置和实例承载能力。
清洗后仍有高并发，是否说明清洗失效？
不能仅凭并发判断。清洗后的合法请求可能仍然集中到达，应结合清洗侧统计、源站请求特征和业务指标判断。
应该先调超时还是先扩容？
先定位连接占用原因。若请求因后端变慢而堆积，应处理后端或扩容；若连接反复建立或重试放大，则先修正复用和重试策略。
