看到监控里的连接数陡升，先别急着封禁来源。正常流量增长、客户端重试、后端变慢，都可能让连接暂时堆积。判断是否遭遇攻击，要把连接状态、来源分布和服务表现放在一起看。本文给出一套可执行的TCP连接洪水识别与缓解方案，重点是先确认瓶颈，再选择影响范围合适的措施。
先看连接“处于什么状态”
总连接数只是一个总量，不能说明连接是否完成建立。Linux 主机可先查看 ss -s 的汇总，再用 ss -ant state syn-recv 观察等待握手完成的连接；也可查看 established 状态，了解已建立连接的变化。不同系统和工具版本的输出略有差异，应与平时基线对比。
- SYN_RECV 集中增加：可能是大量握手请求尚未完成，需进一步核对来源、入口流量和服务器响应，不能仅凭这一项定性。
- ESTABLISHED 增加：既可能是访问真实增长，也可能是客户端没有及时关闭连接，或应用处理变慢。
- 连接数不高但服务不可用：还要检查带宽、CPU、文件描述符、应用线程和连接跟踪表等资源是否先达到瓶颈。
如果网络侧能提供数据，可同时核对新建连接速率、入站包速率和流量曲线。攻击流量常表现为短时间内异常集中，但分布特征并不固定；来源多、来源少或连接状态异常，都不能单独作为结论。
用交叉证据区分攻击与业务波动
核对业务侧变化
把连接曲线与请求量、错误率、响应时间及发布记录对齐。活动开始、客户端版本更新或上游重试策略变化，都可能带来真实连接增量。若请求量同步上升、响应仍正常，优先按扩容和容量管理处理；若连接激增而有效请求没有相应增长，且超时、拒绝连接等指标恶化，则需要继续查验。
检查资源与来源特征
查看主机的 CPU、内存、文件描述符使用情况，以及防火墙或系统的连接跟踪表是否接近容量上限。日志中的源地址分布、连接持续时间和失败比例可作辅助证据；代理或负载均衡环境下，应用日志里的来源地址可能是代理地址，不能直接据此封禁。必要时由网络团队在入口设备或抓包点核实握手过程。
从低风险排查到入口缓解
- 保留现场：记录异常开始时间、连接状态、流量、错误率和资源曲线；确认是否有部署、配置或流量来源变化。
- 定位最先饱和的环节：区分链路带宽、主机网络栈、连接跟踪表、负载均衡器和应用进程，避免只在服务器上调参数却忽略上游瓶颈。
- 先保护业务：若问题来自某类合法客户端重试或应用变慢，修复超时、连接复用或后端容量问题；若确认是异常新建连接，再按服务特性设置限速、连接上限或过滤规则，并小范围观察误伤。
- 处理握手压力：Linux 的 SYN cookies 可在 SYN 队列承压时作为保护手段，但它不是增加带宽或修复应用故障的替代品。调整队列、超时或系统参数前，应确认内核配置和业务负载，并逐项变更、记录回滚办法。
- 升级到网络入口：当链路已拥塞，主机防火墙通常无法恢复已经被占满的带宽。联系网络服务提供方或具备清洗能力的上游，在入口侧协同过滤；恢复后继续监控连接状态与业务错误率。
规则不要仅凭单个源地址或固定阈值长期封禁。共享出口、代理和校园网络等场景可能让许多用户呈现为同一地址；限速阈值应根据业务基线、峰值和可接受的误拦截风险确定，没有适用于所有主机的通用数值。
常见问题
连接数升高就等于洪水攻击吗？
不是。业务增长、应用变慢和重试风暴也会推高连接数，应结合状态、流量与业务指标判断。
只启用 SYN cookies 就能解决吗？
不能。它主要帮助应对握手队列压力；带宽拥塞、已建立连接耗尽或应用故障仍需分别处理。
什么时候应该找上游协助？
当入口链路接近饱和、主机侧措施无法恢复可用性，或攻击流量来自大量分散来源时，应尽早联系上游协同处置。
处理这类告警的关键不是先套用一条封禁规则，而是用状态和业务证据定位瓶颈，再分层采取措施。把基线、变更记录和回滚方案纳入TCP连接洪水识别与缓解方案，通常比单纯增加连接上限更稳妥。