当负载均衡器仍在运行，但用户却频繁遇到连接超时或失败时，问题可能不在后端应用，而在入口处的连接资源被占满。TCP连接耗尽攻击对负载均衡器的影响，取决于攻击者如何占用连接、设备如何处理连接状态，以及后端是否同步承压。
连接资源是怎样被耗尽的
负载均衡器需要为连接维护状态，并分配处理能力。攻击流量可能大量发起连接，也可能建立连接后长时间不发送数据。前一种方式可能留下尚未完成握手的半开连接；后一种则占着已建立连接不释放。两者都可能消耗连接表、内存、处理队列或文件描述符。
以 HAProxy 这类代理为例，连接上限、超时配置和系统可用文件描述符都会影响它能同时处理多少连接。达到限制后，新的正常请求可能排队、被拒绝或等待超时。若负载均衡器还需要为每个客户端另建后端连接，前后两侧的连接资源也可能分别成为瓶颈。
用户与运维人员会看到什么
入口变慢，后端未必过载
典型表现包括新连接建立时间上升、部分请求直接失败，以及负载均衡器的活动连接数接近配置上限。此时后端服务器的 CPU 或应用请求量可能并不高，因为部分连接根本没有顺利转发到后端。反过来，如果连接已被转发，后端也可能因额外会话和等待请求而变慢。
健康检查可能造成误判
当检查请求也无法及时获得连接或排队时间过长时，设备可能把原本可用的后端判为异常，进而减少可用节点。这样会把流量集中到剩余节点，形成进一步拥塞。判断时应同时查看负载均衡器的连接数、丢弃或拒绝计数、队列状态，以及后端连接数和健康检查记录，而不是只看单个 CPU 指标。
怎样区分攻击与正常流量激增
正常活动高峰通常伴随业务请求和后端处理量一起上升；连接耗尽则可能出现连接数明显增长，但有效请求量没有相应增加，或大量连接长时间处于等待状态。单一指标不能证明存在攻击，还需结合时间变化、连接持续时长、来源分布和服务日志判断。共享出口、代理和移动网络也会让多个用户呈现相似来源特征，因此不宜仅凭来源地址归因。
缓解时按顺序处理
- 确认瓶颈位置。查看负载均衡器当前连接数、连接表使用情况、文件描述符、队列和拒绝计数，并对照后端的连接数与请求量，确定耗尽发生在入口还是后端。
- 先保护现有服务。在设备支持的前提下，启用连接速率限制、来源限额或上游流量清洗；设置时结合正常并发和共享出口用户情况，避免把合法用户一并挡住。
- 回收长期占用的连接。检查客户端与后端方向的空闲超时、握手超时和连接上限。适当缩短超时可释放闲置资源，但设置过短可能中断网络较慢或长时间保持连接的正常业务。
- 核验扩容和转发能力。确认负载均衡器的连接上限、操作系统文件描述符限制及后端容量是否匹配。单纯增加上限而不检查内存、队列和后端承载能力，可能只是把故障推迟或转移。
- 恢复后复盘。保留事件时间段内的连接与拒绝指标，检查限制策略是否误伤，并持续观察健康检查和新建连接是否恢复正常。
常见问题
连接数升高就能判定遭到攻击吗？
不能。发布活动、客户端重试或业务高峰也会增加连接数，应结合有效请求量、连接持续时间和后端状态判断。
提高连接上限能解决问题吗？
只有在设备仍有内存、文件描述符和后端余量时才可能缓解。若连接被持续占用，提高上限可能延后而非消除故障。
TCP连接耗尽攻击对负载均衡器的影响会只停留在入口吗？
不一定。连接若已转发到后端，会额外占用后端连接和处理资源；因此排查和缓解应覆盖入口设备、转发链路与后端服务。
总的来说，TCP连接耗尽攻击对负载均衡器的影响不只是连接数变大，还可能表现为新连接失败、健康检查误判和后端资源被连带消耗。先定位具体瓶颈，再调整限制与超时，通常比盲目扩容更稳妥。