如果你正在处理TCP Sockstress，先别急着照搬网上的参数。如果你刚接触服务器运维，可能会被各种DDoS攻击术语搞晕。SYN Flood听过，但Sockstress是什么？简单说，它是一种更”温柔”但同样致命的TCP连接耗尽攻击，专门欺负那些只关注带宽却忽略连接数的服务器。本文面向没有安全基础的小白，用最直白的语言讲清楚它的原理，并给出实际可操作的内核和WAF配置方法。
一、Sockstress攻击到底是什么？先搞懂TCP三次握手
验证与回滚
要理解Sockstress，必须先回忆一下TCP连接是怎么建立的。你自己上网冲浪时，浏览器和服务器之间会经历一次”礼貌的握手”：
- 第一次握手：你的电脑发一个SYN包给服务器（相当于敲门说：”在吗？”）
- 第二次握手：服务器收到后，回复一个SYN-ACK包（”在，请进”）
- 第三次握手：你的电脑再发一个ACK包（”好嘞”）
完成这三次后，连接才真正建立，可以传输数据了。
现在，Sockstress攻击者不按套路出牌。它只完成前两次握手，然后——不发了。服务器傻傻地等着第三次握手，把这条连接标记为”半连接”（SYN_RECV状态），并分配一小块内存来保持状态。攻击者会同时打开成千上万个这样的半连接，填满服务器的连接表（即backlog队列）。一旦连接表满了，新来的正常用户就无法建立连接了。
和著名的SYN Flood相比，Sockstress的不同点在于：SYN Flood通常只发SYN包（第一次握手）就完事了，根本不回应服务器的SYN-ACK；而Sockstress会正经回应SYN-ACK，使服务器认为连接正在建立中，因此占用资源的时间更长、更隐蔽。很多防火墙能轻易识别SYN Flood，但对Sockstress却掉以轻心，因为它看起来像是正常的TCP连接建立过程。
关联教程：此处可内链到“TCP Sockstress部署与验证”内容。
TCP Sockstress：二、Sockstress攻击为什么难以防御？
配置前的检查
传统的DDoS防护主要对付带宽洪水（比如UDP Flood），而Sockstress是资源耗尽型攻击，攻击流量本身很小。攻击者可以用一根网线、一台低配VPS就瘫痪你十几万并发连接的服务器。更麻烦的是，它针对的是服务器端操作系统的TCP协议栈实现——无论你是Nginx、Apache还是Tomcat，底层都是Linux在处理TCP连接，所以攻击面在操作系统层面。
好在Linux内核提供了不少参数来调节TCP行为，我们可以通过调优来减小攻击影响。同时，配合WAF（Web应用防火墙）的限速和黑名单功能，可以建立多层次防线。
TCP Sockstress：三、Linux内核防护：关键参数调优
以下调整需要在服务器上以root身份执行（建议先备份原始值）。你可以直接写在 /etc/sysctl.conf 中永久生效，或者临时用sysctl -w 修改。注意：不同Linux内核版本参数名略有差异，但主流发行版（CentOS 7/8、Ubuntu 20.04+）都支持。
1. 启用SYN Cookies（必开）
net.ipv4.tcp_syncookies = 1
这个选项让服务器在SYN_RECV队列（半连接队列）快满时，不维护半连接状态，而是通过一种加密算法直接在SYN-ACK包中嵌入信息。当客户端回复ACK时，服务器通过校验即可确认连接合法性。这样攻击者即使发送大量半连接，也不会消耗完内核内存。默认是1（开启），但确认一下没坏处。
2. 缩小SYN_RECV队列大小并缩短超时
net.ipv4.tcp_max_syn_backlog = 1024 （可根据实际情况调整，通常设置1024或2048）
net.ipv4.tcp_synack_retries = 1 （或0）
tcp_max_syn_backlog控制服务器最多能保留多少个未完成三次握手的半连接。攻击者填满这个队列就完了，所以把它设置得小一点，让队列消耗更快，配合SYN Cookies一起使用。tcp_synack_retries是服务器重发SYN-ACK的次数，默认5次（重试约3分钟）。如果攻击者不回ACK，服务器会傻等。设成1或0可以加速回收半连接。
3. 设置全连接队列的最大值
net.core.somaxconn = 1024
全连接队列（ESTABLISHED状态）是已经完成三次握手的连接，等待应用程序accept()处理。如果应用程序处理慢，队列满了新连接也会被拒绝。适当调大能提高并发能力，但不要太大（否则内存占用高）。一般1024或2048足够。
4. 快速关闭TIME_WAIT连接
Sockstress攻击如果已经完成全连接（比如攻击者发了ACK但立即发送FIN断开），服务器会进入TIME_WAIT状态等待2MSL（约60秒）。太多TIME_WAIT会消耗端口和内存。可用：
net.ipv4.tcp_fin_timeout = 15 （默认60，可降为15）
net.ipv4.tcp_tw_reuse = 1（允许重用TIME_WAIT的端口）
注意：tcp_tw_recycle在较新内核中已被移除，不建议使用。只用tcp_tw_reuse即可。
5. 开启TCP Fast Open（辅助）
net.ipv4.tcp_fastopen = 3
这个选项可以在三次握手中捎带数据，减少握手次数。对防御Sockstress没有直接作用，但可以提升正常用户的体验，也算一种缓解。
把这些参数写入/etc/sysctl.conf后执行sysctl -p使其生效。
进阶阅读：此处可内链到“TCP Sockstress性能优化”指南。
四、WAF限控配置：第二道防线
内核调优只能缓解，不能完全阻止攻击者消耗服务器资源（因为攻击者依然可以完成少量连接并进行缓慢读写）。配合WAF可以做更精细的限制。以下以常见的GoEdge WAF（或类似支持连接数限速的WAF）为例说明思路。
1. 限制单IP并发连接数
在WAF的“频率限制”或“连接数限制”模块中，设置：
- 单IP最大并发连接数：比如50（取决于你的业务类型，普通网站设为30～50即可）
- 统计周期：1秒或5秒
- 超出后动作：记录日志并返回403或重置连接
这样攻击者每个IP只能建立少量连接，无法填满内核连接表。
2. 限制单IP新建连接速率
很多WAF支持“新建连接数/秒”限制：
- 单IP每秒允许新建连接数：比如20
- 超出后返回503或连接重置
Sockstress攻击通常需要快速建立大量半连接，限制新建速率可以有效削弱它的效率。
3. 开启SYN代理
如果你的WAF或CDN具备SYN代理功能（或称TCP代理、七层反向代理），建议开启。WAF作为中间人先与客户端完成三次握手，再向后端服务器建立连接。这样一来，攻击者的半连接全部打在WAF节点上，后端服务器完全不受影响。云厂商的WAF通常默认带此功能，自建WAF如Nginx+ngx_http_limit_conn_module也能模拟类似效果。
4. IP黑名单与自动封禁
当WAF检测到某个IP在短时间内出现大量SYN_RECV或TIME_WAIT的连接时，可以自动将其加入黑名单一段时间（比如10分钟）。这需要WAF具备日志分析和联动能力。GoEdge支持通过自定义规则匹配连接数异常。
5. 从云平台层接入DDoS高防
如果你使用的是云服务器，强烈建议将域名解析到云厂商的DDoS高防IP上。高防节点自带海量带宽和专用清洗设备，能够在上游拦截掉绝大多数连接耗尽攻击。对于自建IDC，可以考虑使用IP信誉库或黑洞路由。
相关阅读：此处可内链到“TCP Sockstress常见问题”专题。
五、验证防护效果（测试环境操作）
实际操作要点
想确认配置是否生效？可以用hping3模拟Sockstress攻击（仅限你拥有的服务器，严禁攻击他人）。
例如，模拟单IP发送大量SYN包但不完整三次握手：
hping3 -S -p 80 --flood -V 你的服务器IP
然后在服务器上查看连接状态：
ss -tane | grep SYN_RECV | wc -l
如果开启了SYN Cookies且tcp_max_syn_backlog较小时，SYN_RECV不会飙高。同时正常用户应该仍能打开网页。可以使用wrk或ab进行压力测试同时看正常请求的成功率。
注意：不要在生产环境做压力测试。最好搭建一台测试服务器，模拟攻击环境。
六、总结：多层防护才是正解
故障定位思路
Sockstress攻击虽然隐蔽，但并非无解。通过Linux内核参数调优（重点开启SYN Cookies、缩小半连接队列、加快超时回收），配合WAF的并发连接限制和新连接速率控制，以及云上SYN代理，中小型网站可以抵抗大部分这类攻击。对于高价值业务，建议直接上DDoS高防服务。
最后提醒一句：任何单一配置都可能有局限性。比如SYN Cookies在极端流量下仍会消耗CPU，连接数限制可能误伤使用NAT的大量真实用户。因此，持续监控连接队列长度（ss -tane | wc -l）和CPU指标，根据实际情况微调参数才是长久之计。
希望今天的科普和配置指南能让小白也能从容应对Sockstress攻击。动手试试吧，在测试环境里调一调，感受一下前后差异。把这些步骤跑通后，TCP Sockstress基本就能稳定落地。
延伸阅读