慢速攻击并不靠海量流量取胜，它用极小的带宽，通过长时间占用服务器连接资源，就能让应用响应迟缓甚至彻底瘫痪，这是一种典型的“四两拨千斤”式拒绝服务手法。
想象一下，一个正常的用户访问网站，会快速发送完整的HTTP请求头，然后接收数据，而慢速攻击者就像在饭店里点了一桌子菜，却每吃一口就停下来刷半小时手机，占着桌子不让服务员翻台，服务器端的“服务员”也就是连接线程，就这样被一个或多个“慢吞吞”的客人牢牢占住，直到资源耗尽，真正想吃饭的客人（正常用户）只能在外面排队等位。
![[免备CDN/WAF防火墙] 网站加速与WAF防御全搞定！QEdge亚太CDN保姆级配置实战 【完整重制版】](https://i1.hdslb.com/bfs/archive/a7f9d3c4181da749857cfef38d60feb354f16b81.jpg)
慢速攻击原理是什么为什么几十K流量就能击垮一台高配服务器
慢速攻击的反常之处在于，它打破了“攻击必须靠大流量”的常规认知，业内专家指出，几个普通的攻击源，用不到1Mbps的带宽，就足以让一个具备千兆带宽和强劲CPU的Web应用失去响应。
核心命门：服务器愿意“等”你
HTTP协议是建立在TCP之上的，服务器在处理请求时，默认会为每个连接分配资源，并等待客户端发送完整的数据，这个“等待”过程有超时时间，通常从几十秒到几分钟不等，慢速攻击就是精准踩中了这个“信任”机制。
- 攻击者建立连接后，久久不发送任何数据,或者每隔很长一段时间才发送一个字节。
- 服务器以为客户端网络慢，或者还在思考，于是傻傻地保持着连接,阻塞资源。
- 攻击者同时开启成千上万个这样的连接，服务器的连接池（或者线程池）瞬间被占满。
真正的流量攻击是拿大炮轰门，而慢速攻击是拿一把把小锁,把服务器所有的锁孔都堵死。
三大经典慢速攻击手法
在具体的攻击实施中，有几类模式已经被广泛记录，它们都遵循“占着茅坑不拉屎”的逻辑：
- Slowloris（慢头部攻击）：攻击者发送一个不完整的HTTP请求头，比如只发送
GET / HTTP/1.1\r\n，然后不发后续的Host字段和终止符\r\n\r\n，服务器会一直等待请求头变完整，攻击者通过定时发送一个额外的X-Custom: header来维持连接存活，防止超时断开，这是最常见的慢速攻击,主要用于消耗Web服务器的并发连接数。 - 慢速POST攻击（Slow Body）：攻击者发送完整的请求头，并声明会提交一个很大的
Content-Length（比如10GB），但实际发送请求体（Body）的速度极慢，比如每10秒才发送一个字节，服务器为了保证能接收完整个上传内容，会持续为该连接分配内存和I/O资源，这种攻击对需要解析请求体的应用（如API接口）杀伤力极大。 - 慢速读取攻击（Slow Read）：攻击者向服务器发起一个正常的下载请求，服务器开始发送数据，但客户端的TCP接收窗口被攻击者设置得极小（比如只有1字节），这导致服务器每发送一小段数据后，就必须等待客户端确认，否则不能继续发送,大量服务器内存被用于缓存待发送的数据。
如何判断应用是否正在遭受慢速攻击
很多运维人员发现应用卡顿后，第一反应是看带宽占用或CPU负载，结果发现数值都很“健康”,这正是慢速攻击的迷惑性所在。
排查服务器的现象观察
当你遇到以下反常迹象时,应该立刻警惕：
- 服务器带宽出口和入口流量都很低,但应用响应时间呈指数级上升。
netstat命令显示有大量TIME_WAIT或ESTABLISHED状态的连接，且对端IP集中在少数几个IP段。- 连接数虽多，但每个连接的收发字节数极低（比如平均<100字节）。
- 查看Web服务器状态页（如Nginx的
stub_status），发现Active connections数值异常巨大，且waiting连接占比极高。
一条命令快速验证
登录服务器,执行以下命令查看当前TCP连接状态：
netstat -nt | awk '{print $6}' | sort | uniq -c | sort -n
如果发现SYN_RECV和ESTABLISHED状态数量异常,再通过以下命令查看具体是哪些IP在占用连接：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
重点： 正常情况下，一个IP的并发连接数不应超过几十，如果出现单个IP占据数百甚至数千个ESTABLISHED连接，且这些连接大多处于空闲状态,那么大概率就是慢速攻击在作祟。
慢速攻击怎么防御从应用到系统层的完整加固方案
防御慢速攻击的核心思路是：不要无条件信任客户端，让服务端占主导权，并设置严格的“耐心”上限。
Web应用层防护（以Nginx为例）
Nginx是当前使用最广泛的Web服务器,其自带的模块就能有效缓解部分慢速攻击：
- 调整
client_header_timeout和client_body_timeout：将这两个值从默认的60秒调低至10-15秒,超时后Nginx会主动断开连接。 - 设置
keepalive_timeout：建议设置为10秒左右,避免空闲连接长久占用。 - 限制请求体大小：对于不需要上传功能的接口，设置
client_max_body_size为1m,能有效过滤掉慢速POST攻击中的大体积请求声明。
系统内核层防护（针对TCP栈）
Web层防护无法解决TCP层已被占满的问题,还需同步调整系统内核参数：
# 减少SYN队列的等待时间，加快处理失败的半连接 sysctl -w net.ipv4.tcp_synack_retries=1 sysctl -w net.ipv4.tcp_syn_retries=1 # 降低TCP连接的超时回收时间 sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_intvl=30 sysctl -w net.ipv4.tcp_fin_timeout=10 # 开启SYN Cookie，防止TCP层被完全淹没 sysctl -w net.ipv4.tcp_syncookies=1
注意： 调整内核参数需要结合服务器实际业务场景，过于激进的参数可能导致正常的长连接（如WebSocket）被误杀。
专业防护设备的“主动验证”机制
对于高价值应用，建议在前端部署专业的DDoS防护设备或云WAF，它们应对慢速攻击的核心能力在于主动探测：
- 对于新建的连接，如果长时间不发送数据，防护设备会伪装成服务器向客户端发送一个JS Challenge（JavaScript验证码）或者302重定向。
- 真正的浏览器会自动执行JS或跟随跳转,从而在超时前建立新的有效连接。
- 攻击者使用的自动化脚本通常不会解析JS或处理Cookie,因此其连接会被视为无效并直接丢弃。
这种方法可以有效识别并拦截大量基于Python、Scapy等脚本发起的慢速攻击。
慢速攻击防护方案与云服务商选型参考
谈论防御方案时，许多运维人员会纠结于购买高防IP还是升级WAF，二者在防护慢速攻击时的侧重点有显著区别,我整理了以下对比供你参考：
| 防护类型 | 工作层 | 核心优势 | 局限性 | 参考价格区间（国内主流云厂商） |
|---|---|---|---|---|
| 传统高防IP | 网络层（L3/L4） | 流量清洗能力强，主要抗DDoS大包洪水 | 对慢速攻击的检测逻辑较弱，可能误杀正常连接 | 基础防护（5G-10G）约1000-3000元/月 |
| 云WAF | 应用层（L7） | 能解析HTTP语义，精准识别Slowloris和慢POST | 对HTTPS加密流量解密检测有额外性能开销 | 基础版数百元/月，高级版数千元/月 |
| 负载均衡+WAF | 四层/七层联动 | 先由LB分发流量，WAF卸载SSL并检测恶意连接，扩展性好 | 架构复杂，需要专业运维人员调试 | 按实例规格计费，组合方案约3000-5000元/月 |
补充说明： 以上价格仅为国内云厂商的大致市场行情，用于体现不同方案的资源投入水平，选择具体服务时，建议向服务商索取针对慢速攻击的压测报告，并明确要求提供连接速率限制功能即限制单个源IP每分钟新增连接数,这是最直接有效的兜底策略。
常见问题排查指南
为什么服务器没宕机，但用户就是打不开页面？
这是慢速攻击的典型特征：系统资源（CPU、内存、带宽）看似正常，但Web服务器的并发连接数已到上限，新用户的请求根本得不到处理机会，你可以观察Nginx的级别日志，通常会包含20832 worker_connections are not enough的报错。
加了CDN之后慢速攻击防住了，但源站IP被绕过之后又打不开了怎么办？
这暴露出一个常见的防护盲区：CDN只保护了域名入口，而源站IP泄露后可直接被攻击，首先确认源站防火墙是否仅对CDN回源段开放端口，并修改源站默认端口，如果业务依赖回源，则需在源站前单独部署上述提到的负载均衡或WAF进行兜底，同时考虑到某些地区用户访问的延迟,可在源站上层设置白名单策略。
慢速攻击和普通流量突增的区别是什么？
两者导致的业务现象相似，但处理策略完全不同，流量突增时，服务器连接数上升，但每个连接的请求是完整的、速率是正常的；慢速攻击则是连接数上升，但平均请求速率极低，流量突增可以通过临时扩容来解决，而慢速攻击即便扩容数倍，只要攻击者能继续建立连接，依然会被拖垮，打个比方：高速公路上车流增大，扩宽车道就能疏堵；但如果是每辆车都停在路边不走,扩再宽的路也无济于事。
慢速攻击之所以“反常”，是因为它利用了服务器对“耐心”和“信任”的设定，用极小的成本实现了高烈度攻击的效果，防御的关键在于放弃“来者不拒”的被动策略，通过设置超时、减少等待、主动探测等手段,彻底扭转服务器与客户端之间的博弈地位。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787783.html
