高防场景下慢速CC攻击被发现的核心思路，是跳出传统频率阈值的单一视角，转而在网络层会话特征、应用层行为规律与统计学异常三个维度同时建立交叉验证机制。
慢速CC攻击之所以难防,是因为它伪装得太像正常用户，一个真实的访客可能花10秒输入表单，也可能盯着页面发呆5分钟，攻击者正是利用这种“人类化”的行为模式，用极低的速率、极长的连接时间，一点一点耗尽服务器资源，以TCP连接保活类攻击为例，攻击者建立连接后以每数十秒一个字节的速率发送数据，单个请求完全合规，但成千上万个这样的连接同时存在，就足以占满并发上限，传统WAF按“每秒请求数”做拦截，面对这种打法几乎形同虚设。
高防场景下慢速CC攻击检测方法有哪些
要回答这个问题,必须先拆解慢速CC攻击的行为指纹。慢速CC攻击的三种经典形态分别是Slowloris（慢速请求头）、Slow POST（慢速请求体）和Slow Read（慢速读取响应），高防场景下它们还有各自的变体，检测方法也因此分成了四个层次，从粗糙到精细，从单点到全局。
网络层会话指纹检测
这是最直接、也最容易落地的检测手段，核心思路是让防火墙或负载均衡设备回答一个问题：这条TCP连接的生命周期健康吗？
- 针对Slowloris：检测连接建立后，请求头长时间未传输完毕的连接，行业共识认为，正常情况下一个HTTP请求头在几秒内就能传完，超过30秒仍未完成的连接属于高危信号。
- 针对Slow POST：检测Content-Length极大、但实际收包速率极低的连接，比如声明了10MB的请求体，却以每秒几字节的速度上传，持续数分钟这不是用户网速慢，而是攻击者在故意拖时间。
- 针对Slow Read：检测窗口大小异常缩小的行为，攻击者通过修改TCP接收窗口（通常设置为极小值），迫使服务器无法正常发送响应数据，导致服务器端缓存堆积。
具体操作上,可通过tcpdump -i eth0 '(tcp.flags & 0x02)!=0' -nn抓取TCP握手请求，统计SYN包之后的ACK包到达间隔，若发现大量连接的平均发送间隔超过20秒，且连接持续时间超过5分钟，基本可以判定为慢速CC攻击，在Nginx层则可通过$request_time和$upstream_response_time两个变量做筛选，输出超过60秒的活动连接记录。
会话行为模式检测
网络层特征能抓住直接拖时间的攻击,但高防场景下的攻击者早已学会“漂白”行为，他们会随机控制发包间隔，比如第一分钟间隔3秒，第二分钟间隔15秒，模拟真人浏览时的停顿，要对付这种变体，就需要观察会话的完整性模式。
核心检测逻辑是计算单位时间内的“有效行为密度”，正常用户浏览网页时，会产生一系列连续的搭载关系：请求HTML→解析→请求CSS/JS→请求图片→执行JS→可能再发起AJAX，这个链条通常在3秒内完成，攻击者虽然会周期性地发请求，但他们的行为链条往往是碎片化的只请求同一个URL，或者每次请求之间没有任何资源依赖关系。
高防设备上可以设置这样的规则：统计单个源IP在10分钟内请求的不同URL数量，以及静态资源与动态请求的比例，正常用户的静态资源请求占比通常在60%以上，而慢速CC攻击者为了节省带宽，会刻意减少资源请求，导致比例倒挂。当动态请求占比超过80%且连接持续时长普遍超过行业基线（约120秒）时，触发告警的置信度极高。
设备指纹与客户端环境校验
这不是新概念,但在高防场景下应对慢速CC时依然有效，多数慢速CC攻击工具基于简单的脚本框架，很少会完整模拟浏览器的TLS指纹（JA3/JA4）和Canvas渲染特征。
检测手段是让高防节点对可疑连接进行JS质询挑战：下发一段需要浏览器环境执行的JavaScript代码，要求客户端在3秒内计算并回传结果，真实浏览器能轻松通过，而基于HTTP库（如requests、pycurl）编写的攻击脚本几乎没有实现的可能，更重要的是，这种检测对正常用户完全无感，因为质询过程发生在高防边缘节点，不会回源到业务服务器。
需要注意的一点是,设备指纹检测对HTTP/2连接效果显著，因为HTTP/2的连接复用特性天然排除了同一条连接上串行交互的异常行为，若攻击者使用HTTP/2多路复用发起慢速攻击，其伪装的难度比HTTP/1.1高出一个数量级。
统计学偏移量异常检测
这是应对慢速CC攻击的“终局手段”，也是高防场景下最需要部署的一道防线，传统阈值告警是基于绝对数值，而统计学检测关注的是相对偏移。
具体做法是：高防平台为每个业务系统建立动态流量基线，以5分钟为粒度，记录每个URL的平均请求耗时、平均请求大小、活跃连接数、连接建立速率这四个维度的历史分布，当实时数据连续三个采集周期偏离基线超过三倍标准差时，判定为异常，这种方式能发现高度拟人化的慢速CC攻击，因为攻击者的请求量即使保持低位，其对连接池和并发数的长期占用必然造成基线偏移。
不过这种检测对高防平台的算法能力要求较高,中小规模业务可以简化操作：在业务低谷期（如凌晨2点至5点）采集一周数据作为基线样本，据行业内较为通用的经验，当活跃连接数分布的中位数与P95分位的比值长期超过1:5时，意味着有异常长尾连接在蚕食系统资源。
慢速CC攻击怎么防御，先学会识别流量特征
检测只是前提,高防场景下真正考验的是从发现到处置的闭环速度，内部机制上，推荐采用“边缘检测+源站联动”的协作架构。
高防IP识别CC攻击的联动策略
高防IP识别CC攻击之后,处置应该自动进入防御流程，而不是等待人工介入，具体操作上：
- 边缘节点触发慢速CC告警后,自动将对应会话的滑动窗口大小限制为正常值的1/4，迫使攻击连接速率进一步下降，释放出部分服务器资源。
- 将可疑连接转发到隔离的“慢速降级池”，该池内的请求不占用正常Web服务器的进程/线程资源，只提供静态错误页响应。
- 若同一源IP段（如C段）在5分钟内有超过10个连接进入降级池，直接在边缘节点封禁该IP段，封禁时长建议为15分钟（短于15分钟起不到消耗作用，超过1小时容易误伤NAT出口用户）。
针对慢速攻击的上游协议调优
在服务器端可以通过修改内核参数,加快异常连接的回收速度，以Linux服务器为例，合理调低tcp_keepalive_time和tcp_fin_timeout，让长时间空闲的TCP连接更快被系统回收，需要留意的是，这类调优存在一定副作用过短的keepalive时间可能影响跨地域用户的正常长连接业务，因此优先推荐在高防节点上操作，而非直接在源站调整。
# 在高防转发节点上，建议的参数如下（单位：秒） net.ipv4.tcp_keepalive_time = 30 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_max_syn_backlog = 1024
同时将Nginx的client_header_timeout和client_body_timeout设置为10秒，超过时间未收到完整数据直接返回408，这种方式对慢速POST的打击效果立竿见影，若业务允许，可在LVS或Nginx层同时开启request_pool限制，即单IP并发连接数超过50时，新连接直接排队等待这不影响真实用户并发操作，但能有效切断数以万计的慢速连接企图。
高防CDN结合推荐的纵深配置
在当前主流高防CDN的推荐配置组合中,“30秒空连接断开+单IP并发限制+URL访问频次指纹”的组合覆盖了慢速CC攻击的绝大多数攻击面，以国内常见高防CDN控制台为例，配有“频率控制”模块，可在其中设置针对单IP的3分钟累计请求数阈值（设置为正常基线的3倍即可），超出后自动执行JS质询或拦截，此类配置需在业务上线前完成，否则攻击发生时再调整规则，会留下较大空窗期。
建议在边缘节点开启“浏览器行为探测”开关，它会定期向活跃连接发送一个极小的Keep-Alive探测包并要求应答，真实浏览器会自动应答，而攻击脚本通常不会处理该逻辑，导致其连接被逐步标记并回收。
检测慢速CC攻击时容易掉进的三个误区
把连接总数当成唯一指标
高防场景下的一个常见误操作是：只看FF（并发连接数）数据，认为连接超过某数值就是CC攻击，但慢速CC攻击的连接数往往并不夸张一台性能不错的Web服务器可以同时挂着5万个空闲连接不崩溃，真正的压力来自连接长期占用内存和文件描述符，只盯连接数会导致两个后果：要么在正常业务波动时误报，要么等到连接堆积到处理极限才被发现，为时已晚。
遗漏了HTTPS场景下的TIME_WAIT排查
在HTTPS协议下,慢速攻击多发生在TLS握手阶段，攻击者发送ClientHello后，就保持沉默，高防机房中大量异常的
TIME_WAIT连接，常被运维人员误判为网络回包异常，白白浪费半天排障时间，识别这一类慢速CC攻击的关键是观察TLS握手完成率：正常情况下握手成功率应在99%以上，若低于90%且集中在固定来源区域，则很大概率是攻击者在消耗SSL握手资源。
防御策略过于激进
另一个极端是防御策略设置得过于敏感,比如将慢速阈值调得非常严格，结果大量使用移动网络的用户（切换基站时存在瞬断）或使用老旧浏览器的用户被当作攻击者拦截，这类误杀对业务造成的收入损失，有时比攻击本身更严重，合理的测算方式是：先开启观察模式24小时，记录被拦截请求中正常业务请求的比例，待该比例低于1%后再切换为防护模式。
慢速CC攻击和普通CC攻击的区别有哪些
两者本质区别不在攻击结果,而在攻击节奏，普通CC攻击像集中火力轰炸短时间、高并发、大流量，目标是在几分钟内击穿服务器最大连接数，慢速CC攻击像温水煮青蛙单点速率低、总量不大、周期持久，往往持续数天甚至数周，通过缓慢消耗使服务器资源处于持续紧张状态，而在流量图表上几乎看不出明显波动。
对高防节点的日志留存策略而言，慢速CC攻击的溯源分析需要至少7天以上的全量请求日志，短于这个窗口，很难绘制出一个完整攻击者群体的行为画像。
常见问题解答
高防IP识别CC攻击时，用户网速慢导致的请求缓慢会不会被误判？
正常家庭宽带用户无论是下载速度还是页面打开速度,都不会出现“单请求持续数分钟”的极端情况，即便最差的2G网络，标准HTTP页面在数秒内也能完成传输，高防设备在判定慢速异常时，会同时检查请求发起的时延分布是否呈规律性真实用户网速慢是均匀随机的，而慢速CC攻击往往呈现整数倍的规律间隔，这是机器调度的明显特征。
使用纯软件方案能从源站层面抵御慢速CC攻击吗？
部分场景可以,在源站部署Nginx并开启limit_req和limit_conn模块，能缓解低强度的慢速攻击；但对于数十万并发级别的慢速CC，纯软件方案会被大量空闲连接耗尽进程数或内存，源站层适合做最后一道防线，整体防御仍依赖高防节点的流量清洗与精确识别能力，二者配合的架构是当前抵御慢速CC的主流方式。
日志分析在慢速CC攻击被发现的过程中是什么角色？
日志是溯源和调优规则的依据,基于Nginx访问日志可以筛选出请求时长超过120秒的异常连接，再根据来源IP、请求URL和User-Agent字段做聚类分析，识别出攻击特征后，将特征回填到高防节点的自动封禁策略中，能够有效压缩攻击者的可操作空间，需要明确的是，高防节点上的自动化检测仍承担第一道告警职能，日志分析则在其中扮演验证与规则迭代的源头角色。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/634939.html
