慢速攻击难以识别，核心策略是在“应用层行为基线”和“连接层状态异常”两条线上同时设卡，放弃对单包特征的依赖。 它不靠高流量取胜，而是用低频慢速连接拖住服务器资源，传统WAF和IPS基于特征库的检测思路，在这种攻击面前基本失效，下面这套补充策略，是我从实际对抗中总结出来的，直接对着操作。
慢速攻击识别不了怎么办：先认清它藏在哪里
慢速攻击最麻烦的地方在于每一个单独请求看起来都是合法的，它不会像CC攻击那样汹涌澎湃，也不会像DDoS那样流量暴涨，它像一个慢性子的人，占用着你服务器的连接线程，喝着茶不走，如果你还在用“每秒请求数超过阈值就拦截”的逻辑，那慢速攻击可以轻松绕过这种防线。
慢速攻击和CC攻击有什么区别
很多人把慢速攻击和CC攻击混为一谈,但识别逻辑完全不同，CC攻击是高频高并发，单位时间内请求量巨大，特征明显，容易触发阈值报警，慢速攻击则是低频低速率，一台攻击机可能只发几十个并发连接，每个连接都正常地发送一部分数据，然后停在那里，一个典型的区别场景：你的服务器CPU占用率很低，内存也正常，但连接数缓慢爬升，新用户开始打不开页面这是慢速攻击的典型画像，行业共识认为，慢速攻击最难缠的点在于“慢”，它让一切基于速率阈值的防护系统失去依据。
为什么传统防护设备抓不到它
传统防护设备依赖三类指标：流量带宽、请求速率、数据包特征，慢速攻击这三样都不占：带宽消耗极低，请求速率甚至低于正常用户，数据包内容完全合法，我见过一个真实案例，攻击者用Slowloris变种，每个连接发一个不完整的HTTP头，保持连接不断开，1000个连接就拖垮了一台4核8G的服务器，从流量图上完全看不出异常，因为总带宽才用了不到5Mbps，这就是它难识别的根源你盯着流量看，永远看不到问题。
四个立竿见影的慢速攻击防护策略识别方法
既然慢速攻击不按常理出牌,你就不能按常理去防守，下面这些方法不需要更换全套设备，大多在现有nginx、负载均衡或防火墙上就能配置验证。
连接状态维度的排查
慢速攻击最核心的特征不是包内容,而是连接的“半死不活”状态，你可以登录服务器，用netstat命令统计当前连接状态：
netstat -nt | awk '{print $6}' | sort | uniq -c | sort -nr
正常情况下,ESTABLISHED和TIME_WAIT占比最高，如果看到大量SYN_RECV或连接长时间处于ESTABLISHED但收发字节数几乎为零，那就是危险信号，更精细的做法是统计每个连接从建立到发送完第一个HTTP请求的时间差：正常用户这个时间在几百毫秒到几秒之间，慢速攻击则可能拖到几分钟。当超过30秒尚未发送完整请求头的连接数量超过总连接数的30%时，大概率正在被慢速攻击。
流量特征的细粒度分析
不要看总流量,要看每个连接的平均速率，慢速攻击的速率通常在每秒几百字节到几KB，远低于正常页面加载的速率，在负载均衡层开启访问日志记录bytes_sent和request_time字段，按客户端IP聚合，筛选出“连接数多但平均速率低”的地址，具体操作：统计过去5分钟内每个IP建立的连接数、传输总字节数，用字节数除以连接数，低于某个阈值（比如1KB以下）的IP全部标记为可疑，这种基于“连接速率分布”的分析方式，能准确覆盖绝大多数慢速攻击变种。
基线学习与动态阈值
这是业内专家指出最有长期价值的策略,把你的业务流量按时间维度分片记录：每周一上午10点的平均连接速率分布、平均请求完成时间、每IP平均并发数，全部建立历史基线，慢速攻击来临时，虽然绝对数值不高，但会显著偏离该时段的基线，比如平时该时段平均并发连接是500，攻击时缓慢涨到800，涨幅60%但绝对值依然“正常”，动态阈值算法不盯绝对数字，而是盯偏离率，设置偏离基线的百分比阈值，比如超过平时均值的50%就告警，这套方案可以最大程度降低误报率，也不会被攻击者摸清固定阈值后躲避开。
主动探测与蜜罐链接
慢速攻击为了保持连接,会周期性地发送小部分数据来“续命”，你可以利用这个行为反制：在页面HTML里藏一个不可见的额外资源引用，比如一个1x1像素的图片<img src="/probe.gif">，正常浏览器会自动请求它并短时间内完成传输，攻击脚本不会解析HTML，不会请求这个资源，所以一旦某个连接建立了主请求但不请求probe资源，同时传输速率极低，就可以高置信度判定为恶意，这个办法实操成本极低，却能直接利用攻击工具的盲区。
慢速攻击防护方案怎么落地的部署建议
识别到攻击只是第一步,真正的挑战是让防护策略生效且不误伤正常用户，这里分自建防护和云防护两条路，各有各的坑。
自建防护与云防护选哪个
自建方案的优势是可控性强,数据不出内网，适合对隐私敏感的行业，你在nginx层可以配置client_header_timeout 10s、client_body_timeout 10s，这些参数用于限制接收客户端请求头和主体的超时时间，超过就主动断连，但自建的缺陷也很明显云上的防御带宽是无限的，自建却有实打实的硬件瓶颈，慢速攻击虽然带宽小，但占满连接表后，你的服务器依然无法服务正常用户。
云防护方案则更省心,比如简米云WAF或酷番云的大禹高防，它们的检测引擎天然基于连接行为和基线模型，且部署在前端节点，攻击还没到源站就被拦截，两者对比可以看这张表：
| 对比维度 | 自建方案 | 云防护方案 |
|---|---|---|
| 初始成本 | 依赖现有硬件，增量成本低 | 按防护峰值计费 |
| 生效速度 | 需手动调参，验证周期长 | 配置完后分钟级生效 |
| 维护负担 | 自己盯着基线数据，投入人力大 | 服务商持续更新规则和模型 |
| 防护资源 | 受限于单机连接表 | 全球节点冗余，抗压能力强 |
防护策略调整的落地步骤
无论选哪条路,都按这个顺序去配置：
- 先在测试环境完整复现慢速攻击（可以用slowhttptest工具，自带Slowloris、Slow POST、Slow Read三种模式）
- 观察攻击时的连接数曲线和内存占用曲线,明确你的业务承受阈值
- 在现网设备上逐步收紧超时参数,每次调整后观察24小时误报率
- 同时开启上述的基线采集功能,积累两周数据后再启用动态阈值告警
- 配置告警通知渠道,确认慢速攻击防护效果后再补充更换正式防护方案
慢速攻击防护方案费用预期
云防护的收费模式比较复杂,说实话没有一个固定的价格。基础WAF包年价格通常在几千元左右，但要注意慢速攻击防护通常属于“Bot管理”或“行为分析”这类增值模块，是单独计费的
，如果走自建路线，主要成本是你的运维时间，按市场普遍行情看，大多数中小型网站每年花在慢速攻击防护上的合理预算在两三千到一万区间，这个区间内，云厂商的基础防护套餐基本够用。
验证你的防护是否真的有效
配置完成后不要急着收工。没有一个防护策略能永远生效，慢速攻击的工具也在不断进化，你需要一套可重复的验证流程，每个季度把slowhttptest工具再跑一遍，确认攻击时Web服务的响应时间没有显著劣化，同时观察误报率是否上升，另一个重要指标是先于攻击发生的告警：当基线系统发出偏离警告时，你能提前多少时间介入处理，如果总是在用户投诉后才发现问题，你的策略还需要继续调整。
慢速攻击的核心破绽在于“它必须保持连接不中断”这一行为本质，紧紧盯住连接存活时间和数据发送速率，一切就都会清晰起来。调整好超时参数，建好基线模型，大多数慢速攻击都可以在早期被发现并拦截在你源站之前，这道防线不是一劳永逸的工程，而是一个需要持续校准的常态运维动作。
慢速攻击防护策略补充建议Q&A
问：慢速攻击防护的价格一般受什么影响？
答：主要看三个因素：防护节点数量、是否包含Bot管理模块、以及清洗能力上限，防护节点越多、包含行为分析能力的套餐价格越高，按行业报价来看，具备完整慢速攻击防护能力的云WAF年费从几千到三四万不等，具体取决于业务规模和建议配置。
问：慢速攻击一般会持续多久？
答：没有标准答案，有的攻击是短时试探，持续几十分钟；有的则是长期慢性消耗，断断续续拖上几周，做防护时要预设攻击者具备持续对抗能力，把“攻击长期化”当默认前提，靠自动化基线监控来应对长期慢速消耗，而不是指望一次性封禁解决所有攻击。
问：慢速攻击识别不了怎么办，如果服务器已经被拖垮了还能做什么？
答：服务器资源耗尽时，先做紧急处置恢复服务：重启Web服务进程清空连接表是第一步，如果你用的是nginx，执行nginx -s reload来重置worker进程，通常能快速释放被占用的连接，然后临时在防火墙上封禁来源IP段，为后续加防护争取时间，恢复服务后立即启用上述基线监控方案，避免再次陷入被动。