慢速CC攻击防护怎么做？连接层四步定位与限流

慢速CC攻击防护怎么做？核心是把限流维度从 QPS 切换到连接维度，并按连接建立、请求接收、连接保持、异常回收四个环节收紧，必要时前移到边缘做连接完整性校验。2026年4月，MDPI 2026年4月研究证实，Slowloris 已从 Web 扩展到 SSH/FTP 等协议，形成 Slowloris E-DoS 攻击，低速率流量极易穿透常规带宽高防的检测。

先分清三种情况：慢速攻击、普通CC，还是自己的连接池泄漏

遇到服务器连接数被打满、但带宽和 QPS 都不高时，先别急着调参，第一步要做的是把故障归因搞清楚。慢速攻击、普通 CC 和自身连接池泄漏，三者表现相似但处置方式完全不同。

慢速攻击和CC攻击的区别在于：普通 CC 靠高频请求耗尽应用资源，而慢速攻击靠极低速率维持大量未完成请求，连接数高但 QPS 极低。如果连接数满且带宽不高，大概率是慢速攻击或连接池泄漏。如果连接来源集中在内网或固定上游，且出现在发版时间点附近，就要先自查连接池泄漏，避免盲目收紧超时误杀了正常业务。

慢速CC为什么能绕过带宽型高防：低速率、少连接、不触发流量阈值

很多人疑惑：明明接了带宽型高防，为什么还被打挂？因为慢速CC攻击不靠流量突增，它用极低的带宽维持大量半开连接，占满源站连接池并消耗 CPU/内存，而基于流量突增或静态阈值的清洗设备根本感知不到。与之呼应的是，Radware 2026年上半年报告显示，Web 应用层攻击同比暴增 128% 至 187.1%，攻击者借助自动化脚本模拟正常业务逻辑，让依赖静态 QPS 阈值的防御频繁失效。针对这类攻击，Layer 7 DDoS 攻击防护需要从连接维度入手。

第一步：看连接状态分布与请求头接收耗时（可直接执行的判定命令与指标）

以 Linux 系统为例，slowloris攻击怎么检测？可以用 ss 命令快速查看连接状态分布：

ss -ant | awk '{print $1}' | sort | uniq -c | sort -nr

如果发现大量 ESTABLISHED 状态的连接长时间存在，且这些连接的请求头/请求体接收耗时异常长，就需要进一步按源 IP 聚合并发连接：

ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

Nginx 日志中并无直接的请求头接收耗时变量，实践中可用 $request_time 减去 $upstream_response_time 估算“客户端侧耗时”，并配合 log_format 增加 $connection_requests、$connection 观察单连接复用与存活情况。注意，所有阈值必须以自身业务基线为准，不要盲目套用网上数字。

第二步：收紧连接建立与请求接收阶段的超时（参数含义与副作用）

nginx怎么防slowloris慢速攻击？最直接的办法是收紧与请求接收相关的超时参数。Nginx 中主要涉及以下参数：

这些参数只提高攻击成本，不能完全免疫慢速攻击。

第三步：单IP并发与连接配额，为什么按连接数限而不是按QPS限

慢速攻击的资源占用与请求数不成正比，所以限流维度要从“每秒请求数”切换到“单源并发连接数 + 未完成请求数 + 连接持有时长”。要限制单 IP 并发连接，使用 Nginx 的 ngx_http_limit_conn_module 模块：

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;

同时要规划好 worker 连接容量。Nginx 的 worker_connections 决定了每个 worker 能同时处理的连接数，如果太小，正常流量也会被拒；如果太大，又可能被慢速攻击耗尽内存。需要根据自身业务连接数基线来调整。

在 NAT 出口等共享场景，按 IP 限并发可能误伤整个出口，可结合 User-Agent、TLS 指纹等动态维度精确定位。正如 Akamai 与 Radware 2026年研判指出，依赖静态阈值的策略在自动化攻击面前十分脆弱，限流策略也需要有动态维度。

第四步：异常连接回收与观测告警项怎么配

配置了超时和并发限制，还需要有回收机制和观测手段。对于长期未完成请求的连接，可以主动回收，比如用 Nginx 的 lingering_close 选项控制半关闭连接的处理。半开、半关闭状态的堆积也要限制，避免攻击者利用 TCP 状态消耗系统资源，相关机制可参考 SYN Flood防御。

慢客户端与恶意慢连接的区别在于前者能完成请求，后者只占坑不传数据；对前者可放宽超时，对后者应尽早断开。

建议长期观测这些指标：连接状态分布、单 IP 并发峰值、请求头接收耗时 P99、worker 连接使用率、CPU/内存与连接数的相关性。告警应基于基线偏移，而不是固定值——比如连接数比平时高出 30% 且请求头接收耗时显著增加，就触发告警。这样能避免误报，也能尽早发现慢速攻击苗头。

不止 HTTP：SSH/FTP 等管理面服务的同类风险与暴露面收敛

慢速CC攻击防护不能只盯着 80/443 端口。前述 MDPI 2026 年 4 月研究把 Slowloris 机制验证于 SSH 和 FTP 协议，形成了 Slowloris E-DoS 攻击：攻击者在身份验证阶段维持大量半开连接，拖垮服务器 CPU 与内存。非 HTTP 协议通常需要按端口做专用防护，因此优先采用端口收敛与白名单，而非把管理端口直接置于公网。

具体可以这样做：

• 配置认证阶段超时（比如 sshd 的 LoginGraceTime，建议调低）和未认证连接数上限（MaxStartups），防止半开连接堆积。
• 管理端口不对公网直开，通过跳板机或零信任接入。
• 按源 IP 收敛访问白名单，只允许办公网或堡垒机 IP。

注意，这是研究性验证，并不是说 SSH/FTP 已经被大规模攻击，但风险是真实存在的，提前收敛暴露面总归没错。

边缘侧能做什么：请求完整性校验与连接配额前移

源站参数调优的天花板在于“连接终结在源站”。要真正降低压力，得把请求完整性校验、慢连接识别、并发配额和连接收敛前移到边缘。

高防CDN能防慢速CC攻击吗？只有当边缘在七层连接层做请求完整性校验、慢连接识别和并发配额时，才能真正挡住慢速攻击；单纯网络层清洗或静态QPS限频对其基本无效。比如 RockCloud 高防CDN、智能WAF 和源站保护服务，就通过源站隐藏和回源连接收敛，让源站只面对完整请求，这样慢速攻击就被挡在边缘侧。

对于 SSH/FTP 等非 HTTP 服务，应通过端口收敛和专用防护，而不是直接暴露到公网。选型时可参考高防IP和高防CDN区别权衡架构取舍。

慢速CC攻击防护自查清单

下面的清单可以直接拿去照着做，确保每个环节都覆盖了：

• [ ] 用 ss 命令查看连接状态并聚合并发连接。
• [ ] 日志记录请求头/体耗时，与基线对比。
• [ ] 分级设置超时参数，测试后放量。
• [ ] 用 limit_conn 限制单IP并发连接数。
• [ ] 开启连接回收机制并增加基线偏移告警。
• [ ] 收敛 SSH/FTP 管理端口，通过白名单接入。
• [ ] 评估是否将连接校验和配额前移到边缘。

建议先按第一步命令跑出连接状态与耗时基线，再决定是否把连接层校验与并发配额前移。若源站已收紧超时仍被打满，可对照清单评估边缘方案或联系 RockCloud 技术支持结合自身连接特征调优。

常见问题

慢速攻击和CC攻击有什么区别？

普通人眼里的 CC 攻击，大多指高频请求耗尽应用资源，QPS 很高；慢速攻击则是“细水长流”，单看流量不大，但靠大量未完成请求把连接池和系统资源拖垮。区别主要体现在带宽占用、QPS 和连接存活时长上。

服务器连接数满了但带宽不高是什么原因？

常见原因有两种：慢速攻击或自身连接池泄漏。慢速攻击的特征是连接数高、带宽低、单连接存活长；连接池泄漏则通常与发版相关，且连接来源集中在内网。可以先按文中第一步的命令排查，再结合发版时间点判断，不要盲目调参，免得误伤正常业务。

只调Nginx超时够吗？

不够。超时参数只是提高了攻击成本，但攻击者的慢速连接可以卡在超时时间内，持续消耗资源。要彻底解决问题，需要配合连接数限制、回收机制，甚至把防护前移到边缘，做连接完整性校验。

高防CDN能防慢速CC攻击吗？

看情况。普通带宽型高防只对流量突增敏感，对慢速攻击基本无效。但如果在七层连接层做了请求完整性校验、慢连接识别和并发配额，就能有效拦截。选型时要问清服务商是否支持连接维度校验，而不是只看防御带宽。

SSH端口被大量半开连接占满怎么办？

立即调整 sshd 配置：调低 LoginGraceTime（比如 20 秒），设置 MaxStartups 限制未认证连接数，并开启白名单只允许可信 IP 接入。如果公网必须开放，建议通过跳板机或 VPN 接入，从根上缩小暴露面。

收紧超时会不会影响大文件上传和SSE？

会。client_body_timeout 收紧后大文件上传可能超时；keepalive_timeout 收紧会断开长轮询和 SSE 连接。解决方法是按 location 分级配置：对普通 API 收紧，对上传接口放宽 body 超时，对 SSE 相关路径单独设置 keepalive 策略，做到精准限制不误伤。