HTTP慢速攻击的本质是“以慢取胜”攻击者用极低速率发送畸形的HTTP请求，让服务器为永远等不到完整的请求而挂起大量连接，连接池被占满后，正常用户就再也挤不进去了。
先拆穿HTTP慢速攻击的把戏
HTTP慢速攻击不像传统DDoS那样用海量流量砸门,更像一个没有礼貌的客人进了餐厅，坐下来点菜，但半天说不清楚要吃什么，服务员只能一直陪着干等，服务器为了响应一个HTTP请求，需要先收到完整的请求头、请求体，攻击者把请求拆成碎片，每隔几十秒才挤一个字节过来，服务器不知道对方是不是网络慢，只能老老实实保持连接等待超时，一个连接占用的内存和线程不算多，但连接池有上限，当成千上万个“慢吞吞”的连接同时占坑，新来的正常请求就找不到空位了。
HTTP慢速攻击原理：极低速率如何骗过服务器
服务器判断一个连接是否存活,依赖超时机制，普通情况下，TCP连接建立后发送数据，服务器会重置计时器，慢速攻击卡在这个机制上它发送数据，但发送速率低于服务器设定的最小超时阈值。
举个例子,一台nginx服务器的client_header_timeout通常设置为60秒，攻击者发一个HTTP请求头，第一行发送完毕后，停50秒再发第二行，服务器一看，连接还没断，数据还在传，只能继续等，等到连接数攒到几千个，worker进程的并发连接数就满了，nginx默认的worker_connections是1024，意味着一个worker最多同时处理1024个连接，其中几百个被慢速请求占据，剩余的那几百个根本扛不住正常的访问流量。
行业共识认为,这类攻击最阴险的地方在于它“合法”，攻击流量和正常流量在网络层几乎无法区分，没有异常的大包，没有畸形协议标志，就是正常的TCP握手和数据传送，只是节奏慢得令人发指，传统流量清洗设备看到的是字节数极少的“健康”流，很难触发阈值告警。
HTTP慢速攻击和DDoS有什么区别
很多站长会把慢速攻击和DDoS混为一谈,实际上两者从原理到防御思路都截然不同：
- 攻击目标不同：DDoS攻击打的是带宽和网络设备的转发能力；慢速攻击打的是应用层的并发连接上限。
- 流量特征不同：DDoS是“洪水”，每秒几十GB很常见；慢速攻击是“滴灌”，单个攻击连接每秒可能只有几字节到几十字节。
- 检测难度不同：DDoS一打就能从流量监控上看到断崖式异常；慢速攻击打两三天，带宽曲线依然平得像一条直线，但网站就是越来越卡。
- 防御成本不同：抗DDoS需要硬抗流量，加带宽或上高防；防慢速攻击主要靠调参数和应用层限流，纯软件层面就能处理大部分场景。
搞清楚了区别,你就能明白为什么慢速攻击在2026年依然是中小站点的噩梦成本低、见效快、溯源难，一个攻击者用一台破电脑就能拖垮一台性能不错的服务器。
服务器是怎么被“慢请求”一点点拖垮的
连接池耗尽的完整链路可以拆成三步。
第一步：攻击者建立大量半连接或慢速连接
攻击者用工具（比如经典的Slowloris或是Slowhttptest）批量发起TCP请求，每个连接只发一部分HTTP数据就停住，为了让服务器认定连接是“活着”的，工具会在超时前补发一个字节，比如一个空格或一个换行符，把计时器不断重置，服务器层面，这些连接的状态停留在ESTABLISHED，既没有完成请求，也没有超时断开。
第二步：系统资源被长期占用
每一个挂起的连接都会占用一个文件描述符、一块接收缓冲区内存、一个线程或协程，在内核层面，net.ipv4.tcp_max_syn_backlog和somaxconn参数决定了半连接队列和全连接队列的长度，当慢速连接把全连接队列塞满，新到的TCP握手就会被内核直接丢弃，这时候你会看到很多SYN_RECV状态的连接，正常的用户访问表现为连接超时或白屏。
第三步：应用层连接池彻底枯竭
以Java应用为例,Tomcat默认的maxThreads是200，200个线程全被慢请求占住后，线程池会触发拒绝策略，新增请求直接抛出异常，以PHP-FPM为例，pm.max_children耗尽后，后续请求进入队列，队列满了就返回502 Bad Gateway，就算你没有写业务代码，服务器层面配置再合理，只要连接池被占住，服务就是瘫的。
业内专家指出,很多中小项目的崩溃点不在代码性能，而在连接池设计默认参数给得太宽松，又没有做连接级的速率限制，等于把后门打开了一半。
怎么判断网站是不是遭受了慢速攻击
网站变慢不一定是被打了,但有几个特征能帮你快速锁定慢速攻击的嫌疑。
- 带宽占用极低但网站响应极慢：这是慢速攻击最典型的特征，去流量监控面板看一眼就能排除流量型攻击。
- 连接数暴涨且大量处于ESTABLISHED状态：用命令
ss -s或者netstat -an | grep ESTABLISHED | wc -l查看，正常情况下连接数应该是平稳曲线，如果突然涨了几十倍且长时间不回落，大概率有问题。 - 日志里出现大量超时记录：nginx的error.log里会刷出“client timed out”之类的信息，Apache则会出现“Request exceeded the limit”报错。
- 个别IP的连接数异常集中：执行
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20，能直接看到哪些IP在疯狂占连接，慢速攻击虽然会换源IP，但早期阶段往往还是有迹可循的。
如果你确认了是慢速攻击,那“网站被慢速攻击了怎么办”就有了明确答案，往下看防御部分。
服务器防慢速攻击的实战配置
防御慢速攻击不需要花哨的硬件设备,把服务器和应用层参数调好，90%的慢速攻击都能被挡在外边。
调整超时时间，缩短挂起周期
核心思路是让服务器别那么“耐心”，nginx里这几个参数建议结合业务实际情况收紧：
client_header_timeout 10s; # 请求头超时，默认60秒太宽松 client_body_timeout 10s; # 请求体超时，防慢POST keepalive_timeout 15s; # keepalive连接超时 send_timeout 10s; # 响应超时，防慢读
Apache用户对应修改下面的指令：
RequestReadTimeout header=10-20,MinRate=500 RequestReadTimeout body=10-20,MinRate=500
Java应用（Spring Boot）可以在配置里调整Tomcat的connection-timeout：
server.tomcat.connection-timeout=10000
这几个配置等于告诉服务器：你只有10秒时间把请求头发完，超过了直接断开，合法的宽带用户不受影响，因为正常请求都在几百毫秒内就完整发送了。
限制单IP连接数，从源头掐断
光调超时还不够,攻击者可以反复重连，更好的做法是限制单IP的并发连接数，nginx用limit_conn模块：
http {
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;
limit_conn_zone $server_name zone=perserver:10m;
limit_conn perserver 200;
}
这样单个IP最多只有20个并发连接,一个攻击者就算换了多个IP，要攒够几千个连接也需要庞大的IP池，攻击成本直接翻倍。
应用层漏洞修复，根治Slow POST和Slow Read
针对慢POST攻击,重点加校验请求体的最小传输速率，nginx使用client_body_in_file_only和nginx_http_limit_req_module配合自定义规则，或者更简单在server层级开启：
client_body_buffer_size 1k; client_max_body_size 1m;
请求体超过1M直接拒绝,很多小流量慢速攻击直接失效，Slow Read攻击则需要通过iptables限制单IP的并发和速率：
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 -j REJECT
这条命令限制了每个IP到80端口的并发连接数,超过20个的新建连接全部被拒。
上WAF或专用防护，省心但费钱
自建防护毕竟需要运维精力,预算充足的情况下，云WAF是个省心选项，国内主流云厂商的WAF都内置了慢速攻击检测规则，价格通常在几千到几万元每年，根据QPS和域名数量不同浮动，如果你用的是裸金属服务器又不想买WAF，可以自己部署开源方案，比如ModSecurity配合OWASP核心规则集，虽然没有商业WAF那么智能，但对付基础慢速攻击绰绰有余。
防御慢速攻击的常见误区
加了CDN就等于防了
CDN能隐藏源站IP,但如果攻击者已经拿到了源站IP，CDN的加速节点反而可能变成慢速攻击的放大器攻击者把请求发到CDN节点，CDN节点会保持到源站的长连接，源站一样被拖垮，所以CDN要搭配源站连接超时调优，双管齐下。
只要网速够大就没事
这是把慢速攻击和流量型攻击混为一谈了,慢速攻击走的是应用层连接池，跟带宽没半点关系，就算你有100G的带宽，连接池只有1024，照样几分钟就能被填满。
频繁调整超时时间到极致就能解决
超时时间设得太短（比如2秒）确实能防住慢速攻击，但也会误伤正常用户移动网络下的用户弱网访问，HTTP请求头传2秒很常见，建议先将超时调到10秒左右，同时配合最低速率限制（比如nginx的limit_rate）来平衡可用性和安全性。
Q&A：关于HTTP慢速攻击原理和防御，你常问的三个问题
问：HTTP慢速攻击能打到HTTPS站点吗？
能,HTTPS建立TLS握手后，攻击者依然可以在应用层以极低速率发送加密后的HTTP数据，服务器完成TLS解密才能拿到明文请求，这个解密过程本身还要消耗额外的CPU资源，更麻烦的是，HTTPS握手阶段无法用明文检测规则匹配，所以很多WAF对HTTPS慢速攻击的识别能力会打折扣。
问：服务器被慢速攻击打崩了，紧急恢复应该先做什么？
第一步不是调防御参数,而是先手动清掉已挂起的连接，可以在服务器上执行nginx -s reload快速重置所有worker进程，或者用tcpkill工具按源IP批量杀掉恶意连接，紧接着修改超时配置、加connlimit限制再重启服务，这个操作顺序能让你在几分钟内恢复服务，而不是在页面打不开的情况下慢慢调配置。
问：慢速攻击只针对HTTP吗？HTTPS和HTTP/2有没有什么区别？
HTTP慢速攻击原理不仅适用于HTTP/1.x，对HTTP/2同样有效，HTTP/2引入了多路复用，多个请求复用同一个TCP连接，这意味着一个慢速请求挂住的连接会拖累其他并行的请求，影响面更大，但HTTP/2的SETTINGS_MAX_CONCURRENT_STREAMS参数可以限制单连接内的并发流数，部分攻击面会被天然收紧，HTTP/3基于UDP的QUIC协议在连接迁移和超时机制上不同，降低了慢速攻击的成功率，但部署率仍未完全普及，慢速攻击本质上针对的是“服务器等待完整请求”这个流程，只要应用层还有等待，攻击就有机可乘，每一层协议都收紧超时和速率限制，才是根治慢速攻击的正确姿势。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787831.html
