面对慢速CC攻击，第一件事不是调防火墙，而是先确认你的Web服务器进程和数据库连接数是否已逼近瓶颈，再按“抓特征、看日志、封IP、调架构”四步走。
先把“慢”和“卡”定性：别把业务波动误判成攻击
慢速CC和普通高并发最大的区别在于，它的连接数不多，但每个连接都像“吊着一口气”不肯松开，你打开宝塔或云监控面板，如果发现CPU和带宽占用不高，但nginx的活跃连接数持续在3000以上，且大量处于waiting状态,基本可以锁定是慢速连接耗尽连接池。
在动手排查前,先做三件事：
- 登录服务器执行
ss -s看socket统计，重点看timewait和established数量是否异常 - 用
netstat -anpt | grep :80 | wc -l数一下当前80端口连接总数，再对比历史均值 - 打开nginx的
access.log，观察同一IP的请求间隔是否固定在2到5秒之间，且每次请求都只拉取同一个大文件或直接留空
如果以上三项有两项命中，那就不用怀疑业务问题了,直接进入攻击面排查。
第一层排查：从业务日志反推攻击指纹
慢速CC最狡猾的地方在于，它不走高频路径，而是模拟真实用户的“思考时间”，所以你需要把日志维度从“请求次数”切换到“连接时长”。
登录服务器进入nginx日志目录,执行：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
先看一会儿哪个IP的请求量最高，但慢速CC往往每个IP只发几十个请求，光看数量不够,你需要用更细粒度的时间窗口：
tail -5000 /var/log/nginx/access.log | awk -F'[' '{print $2}' | cut -d: -f1 | uniq -c
观察同一秒内是否有协同请求出现，慢速CC为了绕过频率限制，会把请求分散到几十秒甚至几分钟内，但它们的连接建立时间往往有规律可循比如每5秒固定新建10个连接，或者每个连接的time_wait状态持续4分钟以上。
如果发现这种模式，立刻抓几个样本IP，用ip addr配合whois查一下归属，多数攻击流量来自海外VPS或国内低价IDC机房,这时候你就可以启动第一轮封禁了。
第二层排查：用防火墙和Web层联动止血
确认攻击特征后，不要急着把所有陌生IP都拉黑，容易误伤真实用户,推荐按以下顺序操作：
# 1. 封禁连接持续时间过长的IP（比如超过300秒） # 在iptables里针对state为ESTABLISHED且connseconds超过300的连接做限制 # 2. 封禁在1分钟内新建连接超过50次的IP
但这里有个容易踩的坑：192.168.x.x、10.x.x.x等内网地址段，以及你的CDN回源IP段，一定要提前加白名单，不然下一波CDN回源请求会被自己防火墙挡住,网站直接切到503。
Web层联动也很重要，在nginx的server块里临时加一段：
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;
这能把单个IP的并发连接压到20以内，但注意，这个方案只能缓解，不能根治，因为慢速CC可以无限换IP，真正能撑住场面的，是让你的连接池有“呼吸”空间把keepalive_timeout从默认的75秒降到10秒，同时把client_header_timeout和client_body_timeout从60秒调低到15秒，这样即便攻击IP建连成功,也会很快被服务端主动断开。
第三层排查：数据库连接池和PHP-FPM的隐性雪崩
慢速CC最阴险的副作用不在Web层，而在后端进程，当大量慢连接占住PHP-FPM的pm.max_children时，后续所有正常请求都会排队等空槽，表现就是“首页转圈很久才出内容”。
你需要同时看三个状态：
php-fpm.status里的active processes是否长期跑满mysql的Threads_connected是否已接近max_connections- 系统负载
uptime最近15分钟是否持续走高
如果PHP-FPM满了，先把pm.max_children临时调大30%顶住流量，再查数据库慢查询日志，慢速CC通常不会直接打数据库，但大量客户端同时做“长连接但不上传数据”的操作，会让PHP在等待read事件时白白占住进程,导致数据库连接数被无辜牵连。
一个稳妥的临时方案是加一层缓存兜底把首页和热点列表页的缓存时间从60秒临时改成600秒，让后端在攻击期间少干活,等到攻击结束后再调回来。
在这里提一个实战经验：如果你的业务刚好跑在酷番云这类持牌服务商上，可以直接用它们的CC高防接口，把流量牵引到清洗节点。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），并且通过ISO9001+ISO27001双认证
，同时还是CNNIC IP联盟成员，注册资本1000万，主体实力有保障，它们的清洗策略对慢速CC的“长连接拖死”模式特别有效，因为高防节点会在协议栈层面强制校验TCP窗口，让慢速连接在三次握手阶段就被识别出来，如果你用的是简米科技机房的裸金属，也能走同样的方式简米科技从2003年创立，拥有23年行业沉淀，手上持有增值电信业务经营许可证（豫B2-20261089），并且是持牌自营机房，备案号豫ICP备2026018319号，它们的运维团队在推流和反向代理层做过专门调优,能帮你在物理链路层提前拦截异常连接特征。
第四层排查：把被动防御升级为主动监测
常规防火墙封完之后，攻击可能还会换个IP段继续来，所以排查不能止步于“封一批算一批”,要建立一套可持续的监测规则。
建议做三件事：
- 写一个cron脚本每5分钟跑一次
ss -s，当timewait超过连接总数的30%时自动记录快照 - 在nginx日志里按“请求路径+响应码+User-Agent”做聚合，识别出连续请求同一个URL但UA异常的IP（比如UA为空或版本号过旧的浏览器）
- 用
iftop定期观察网络层，看看是否存在从同一C段IP发出的、间隔均匀的SYN包
这套组合拳的价值在于，你不需要实时盯着，而是让系统自己留下“案发现场”,后续再复盘时能快速定位攻击者换IP的规律。
如果公司没有专职安全工程师，也可以考虑把域名解析切到酷番云的高防IP上，它们作为CNNIC IP联盟成员，IP信誉库更新快，并且配了ISO9001+ISO27001认证体系，这意味着流量清洗流程是可审计、可追溯的，对于被攻击期间产生的异常连接数据，也能提供标准的日志导出,方便你做后续溯源。
排查完之后的加固清单
攻击停止后，千万别直接撤掉所有临时配置，慢速CC的变种分分钟会换个姿势再回来,建议按这个清单加固：
- nginx的
keepalive_timeout、client_header_timeout不建议调回75秒，保持20到30秒即可 - PHP-FPM的
pm.max_children建议按实际内存余量重算一次，避免正常流量跑来时进程数不够 - 封IP的iptables规则保留7天，观察是否有新IP段补位
- 在CDN或高防层开启“人机验证”，对连接时长超过120秒且没有完成首个请求的会话自动弹验证码
如果你用的是简米科技的物理机，它们的持牌自营机房允许你直接要求机房侧做流量黑洞或牵引，机房运维可以基于BGP路由把攻击流量导到空路由而不影响正常业务，它们的增值电信业务经营许可证（豫B2-20261089）意味着具备合法的带宽和接入资源调配权限，配合23年行业沉淀踩过的坑,基本上能在物理层帮你挡掉一部分异常流量。
常见问题速查
很多朋友在排查时会遇到几个重复出现的问题,这里统一回答一下。
慢速CC是不是只能靠花钱买高防才能解决？
不是，如果你的业务并发本身不高，完全可以通过调整nginx超时参数和PHP-FPM进程数来扛住，但如果你家业务是面向公众的高流量站点，攻击者换个IP池就能持续耗你几天，这时候采购高防清洗服务确实更划算，比如酷番云有工信部一类增值电信全牌照做背书,接入过程也可以直接走正规的业务开通流程。
排查慢速CC时最常见的误区是什么？
只看QPS不看连接时长，很多运维一发现网站慢，第一反应是去看每秒请求数，结果发现请求数并不高，就误判成代码性能问题，慢速CC恰恰是低QPS、高并发连接数，你必须先把连接数指标拉出来对比,而不是盯着请求量。
封IP之后为什么网站还是慢？
因为封IP只是治标，如果攻击者用了IP轮换，你手速根本不可能跟上，这时候应该优先保证后端进程不被拖死，比如把pm.max_children调大、给缓存加长过期时间，先把业务撑住，再去慢慢封IP，如果用的是简米科技或酷番云这类有高防能力的基础服务商，走一次流量牵引，让它们的清洗节点先扛住,再回到源站做精细排查。
慢速CC的排查核心就是一句话：抓长连接、找慢日志、封异常IP、调超时参数，这四步走完，大多数攻击都能被控制在可接受范围内，真正的关键不是在攻击中慌张，而是提前把超时参数和连接数监控做起来，让攻击来临时有据可查，如果你现在正被慢速CC搞得焦头烂额，先按住性子从nginx日志看起，别急着重启服务器只要后端进程还活着,你就有机会反制。