TCP连接洪水防护策略的重点，不是盲目封禁流量，而是先判断攻击压在哪一层，再保护有限的连接状态和服务资源。TCP 洪水可能表现为大量半开连接，也可能是大量已建立连接占满应用处理能力；两种情况所需措施不同。
先分清是哪类连接洪水
常见的 SYN 洪水利用 TCP 三次握手：服务器收到 SYN 后会等待后续确认，并暂存连接状态。请求如果持续涌入，待处理队列可能被占满，正常用户便难以建立连接。另一类洪水能够完成握手，却持续占用连接、文件描述符或应用线程，单靠 SYN cookies 通常解决不了。
排查时同步观察新建连接速率、SYN_RECV 与 ESTABLISHED 状态数量、监听队列溢出、CPU、内存及应用响应。Linux 可用 ss 查看连接状态；重点是看变化是否持续、是否集中在特定服务端口，以及队列压力是否和服务异常同时发生。单看连接总数，无法判断是否遭受攻击。
按顺序建立防护
- 确认影响范围。记录异常开始时间、受影响端口、连接状态和服务错误。核对近期发布或流量变化，避免把合法业务高峰误判为攻击。
- 先在网络边缘减压。联系网络服务商或防火墙运维人员，评估上游清洗、边缘访问控制或 SYN 代理。上游处理适合入口带宽或本机网络设备已承压的情况；只在服务器上过滤，未必能缓解到达链路的流量。
- 检查操作系统连接队列。Linux 管理员可核对 net.ipv4.tcp_syncookies 是否启用，并检查 SYN 队列与监听队列容量。SYN cookies 能在队列压力大时减少半开连接占用，但不能替代扩容，也不能解决已完成握手的连接耗尽。调整队列前要确认应用监听设置及内存余量。
- 对入口流量设限。可在防火墙或负载均衡层按端口和来源特征做连接速率限制，并为可信业务留出余量。限制太严可能误伤共享出口后的多个正常用户；基于单一来源地址封禁，也可能挡不住分散来源的洪水。
- 保护应用并验证。为连接设置合理的空闲超时，检查工作线程、文件描述符和连接池上限；调整后观察队列溢出、成功建连率与业务错误是否改善。恢复时逐步撤销临时规则，避免遗留限制影响正常访问。
措施怎么选，局限在哪里
本机防护与上游防护
内核参数和主机防火墙部署快、控制细，适合队列或主机资源吃紧但入口链路仍可用的情况。若洪水已压满接入链路，应优先让上游网络处理。SYN 代理可在握手完成后再向源站建立连接，减少源站承担的半开状态；但代理自身也需要容量，且引入新的配置和故障点。
限速与容量调整
速率限制能快速压低异常请求，但阈值应以正常业务基线为依据，并保留突发余量。增大队列可以容纳短时波动，却不会让服务器无限承载连接；若应用处理速度不足，队列变大可能只是延后失败。可用受控压测验证修改效果，避免在生产高峰盲目调整。
常见问题
开启 SYN cookies 就够了吗？
不够。它主要缓解半开连接造成的队列压力，对已建立连接占满应用资源或链路拥塞无效。
能否直接封锁所有异常来源？
不建议只按单一来源判断。来源可能分散，且共享出口用户会被连带影响；应结合连接行为和业务规则处理。
什么时候需要联系上游？
当入口带宽、边缘设备或多台源站同时受影响时，尽早联系网络服务商评估上游缓解方式。
有效的TCP连接洪水防护策略应覆盖网络入口、连接队列和应用容量，并通过监测验证每次调整；只改一个参数，往往无法应对不同类型的洪水。