页面变慢、请求超时，不一定是服务器处理能力不足。TCP连接耗尽型攻击对业务的影响，取决于攻击占用的是半连接队列、已建立连接，还是应用层处理资源。新手可先看连接状态和错误变化，再决定是否启用防护，避免把正常流量高峰误判成攻击。
先分清连接耗尽发生在哪一层
TCP建立连接通常要经过三次握手。客户端发送SYN后，服务器会暂存等待完成握手的请求；大量请求若停留在这里，可能挤满半连接队列，这类情形常被称为SYN flood。另一类情况是连接已建立，但大量连接长时间占用文件描述符、内存或服务工作线程，导致新连接排队或失败。
两者的表现并不相同：半连接异常时，握手完成率可能下降；已建立连接堆积时，系统中ESTABLISHED状态连接增多，应用进程也可能接近连接数或文件描述符上限。单看连接总数不足以定性，还应与访问量、连接持续时间和服务日志对照。
业务影响：从用户症状追到资源瓶颈
- 新用户无法接入：连接队列或可用连接槽位不足，表现为建连超时、连接被重置，部分用户可能反复重试。
- 已接入用户变慢：工作线程被占用后，普通请求等待时间增加；若依赖同一主机的其他服务，也可能受到资源竞争影响。
- 错误范围扩大：CPU、内存、文件描述符或网络状态跟踪表耗尽时，故障可能从单个服务扩展到同机其他网络服务。
排查时可在 Linux 主机上用 ss -s 查看连接概况，并按端口观察 SYN-RECV、ESTABLISHED、CLOSE-WAIT 等状态；再对照系统负载、文件描述符使用情况、应用错误日志和监控基线。若连接数骤增但请求量没有相应增长，且来源分布或连接持续时间异常，风险较高；不过共享出口、代理或合法长连接也会造成来源集中，不能仅凭单一特征封禁。
按攻击位置选择缓解方式
半连接队列压力明显
确认操作系统和内核支持后，可启用 SYN cookies，降低等待握手状态占用资源的风险；也可检查半连接队列与监听队列设置是否与业务负载相称。扩大队列只能增加缓冲空间，无法独自解决持续超量流量，且具体参数效果受内核版本、应用监听方式和主机资源影响。
已建立连接占满服务资源
优先在负载均衡器或服务入口设置合理的连接数、并发数及每来源速率限制，并为连接读写配置超时。限制过严会误伤共享网络中的正常用户；设置过松则难以保护后端。若业务允许，可让空闲连接及时关闭，但长连接服务需先评估心跳和重连策略。
入口带宽或主机资源已被压垮
主机本地规则可能来不及处理到达流量，应联系网络服务提供方或使用具备流量清洗能力的上游设施，在流量抵达源站前过滤。防火墙规则适合限制明确且可识别的异常流量，不适合盲目封禁大量地址；攻击来源分散时，单纯按IP限速可能效果有限。
新手可执行的排查与处置顺序
- 记录发生时间、受影响端口、用户错误类型和流量变化，先确认是单个服务还是整台主机异常。
- 检查连接状态、队列、CPU、内存、文件描述符及应用日志，并与平时基线比较；保留短时间间隔的多次观测，避免被瞬时波动误导。
- 确认入口设备和应用是否有连接数、速率及超时设置，先采用小范围、可回滚的调整，并观察正常用户失败率。
- 若源站资源或带宽持续饱和，尽快升级到上游清洗或网络侧协助，同时保留日志与时间线供后续复盘。
TCP连接耗尽型攻击对业务的影响不能只用“连接很多”概括。先定位半连接、已建立连接或应用资源中的瓶颈，再匹配防护层级，通常比直接提高容量或封禁来源更稳妥。
常见问题
连接数高就代表遭到攻击吗？
不代表。发布活动、爬虫或长连接业务都可能增加连接数，应结合请求量、连接状态、来源特征和历史基线判断。
SYN cookies 开启后就能彻底防住吗？
不能。它主要帮助降低半连接队列压力，对已完成握手后的连接耗尽、带宽拥塞或应用层资源耗尽并非通用解法。
可以直接封禁连接最多的来源吗？
不宜只按连接数处理。共享出口可能承载许多真实用户，误封会扩大业务损失；应先核实来源和请求行为，并采用可回滚的限制策略。
什么时候需要联系上游？
当主机已无法稳定响应，或入口带宽、网络设备资源持续饱和时，应尽早联系网络服务提供方，因为本机防护未必能处理到达链路的流量。