摘要：# 当CC攻击撞上服务器：聊聊并发连接数那点事儿 我上周刚处理完一个客户的紧急情况，挺典型的。 客户是个中型电商，平时流量挺稳，结果大促前突然网站卡成PPT，客服电话被打爆。登录后台一看，好家伙，CPU直接飙到98%，连接数比平时翻了二十倍不止，但真实…

当CC攻击撞上服务器：聊聊并发连接数那点事儿

我上周刚处理完一个客户的紧急情况，挺典型的。

客户是个中型电商，平时流量挺稳，结果大促前突然网站卡成PPT，客服电话被打爆。登录后台一看，好家伙，CPU直接飙到98%，连接数比平时翻了二十倍不止，但真实订单没见涨。“这是被CC了吧？” 我第一反应就是这个。

说白了，这就是典型的CC攻击（Challenge Collapsar）——不搞大流量洪水，专挑你Web服务器的“软肋”下刀，用海量慢速请求，一点点耗光你的连接池和计算资源。很多老板觉得上了高防IP就万事大吉，结果发现攻击一来，服务器自己先趴窝了，防护墙再高也白搭。问题往往不是没上防护，而是服务器自己没准备好。

今天咱们不聊那些空泛的防护方案，就从一个运维老兵的视角，掰开揉碎了讲讲，面对CC攻击这种“牛皮糖”式的骚扰，你的Web服务器在并发连接数优化和资源管理上，到底有哪些实实在在的、能立刻动手的调整空间。

并发连接数：不是数字越大越好

先泼盆冷水。很多运维兄弟一遇到卡顿，第一反应就是调高max_connections（Nginx）或者MaxRequestWorkers（Apache）。心里想的是：“池子大了，总能多装点水吧？”

真不是这么回事儿。

我见过最离谱的，是把Nginx的连接数调到好几万。结果攻击一来，连接数是上去了，但每个连接都半死不活地挂着，CPU和内存瞬间被这些“僵尸连接”吃干抹净，整个系统直接僵死。这就好比把家里大门彻底敞开，说能多进人，结果进来的全是堵在门口不走的，真正想买东西的客人反而挤不进去了。

所以，优化第一步是搞清楚你的家底。你的服务器（尤其是CPU和内存）到底能健康地支撑多少个并发连接？别信厂商的标称值，那是在理想环境下测的。你自己用压力测试工具（比如wrk、jmeter）跑一下，看看在业务正常响应时间（比如95%的请求在200ms内返回）的前提下，连接数到多少时，系统负载开始直线上升。这个数，才是你该设的上限。

资源管理：给连接加上“计时器”和“过滤器”

光限制总数还不够，你得管好每个连接的生命周期。CC攻击最烦人的一点，就是它故意把连接时间拉得很长（慢速攻击），或者频繁建立新连接（高频攻击）。针对这两点，有几招特别管用：

• 缩短超时时间： 这是立竿见影的一招。检查你Nginx配置里的client_body_timeout、client_header_timeout、keepalive_timeout这些参数。对于大多数Web业务来说，一个正常的请求根本不需要几十秒的传输或保持时间。大胆地把它们调低到合理的范围（比如5-15秒）。 攻击者的连接会因为超时被迅速掐断，释放资源给正常用户。这感觉，就像给游泳池加了循环过滤系统，死水呆不久。

• 限制请求速率： 在Nginx里用limit_req模块，给单个IP的请求速率设个门槛。比如，同一个IP每秒最多允许发起10个新连接。这招专治高频CC。当然，得小心别误伤用公共网络出口的正常用户（比如公司、学校），所以这通常要配合其他策略一起用。

• 用好连接状态跟踪： Linux系统自个儿就有法宝，比如net.netfilter.nf_conntrack_tcp_timeout_established这类参数，可以调整系统追踪TCP连接状态的时长。对于Web服务器，适当调低established状态的超时（比如从默认的5天降到1小时），能有效防止连接状态表被撑爆。很多DDoS导致的服务器失联，根子就在这张表满了，跟防护带宽压根没关系。

内核参数调优：把地基打牢

上面说的是Web服务器层面的，再往下走，就是操作系统内核了。这里水更深，但调好了效果也最扎实。

• 文件描述符（File Descriptors）： 每个TCP连接都要占用一个。用ulimit -n看看你当前用户的限制，通常默认1024根本不够用。务必把它调高（比如65535或更高），并在/etc/security/limits.conf里做永久设置。同时，检查sysctl里的fs.file-max，这是系统总限制，也得够大。

• TCP/IP协议栈调优： 这一块参数很多，说两个最关键的。一个是net.core.somaxconn，它定义了系统监听socket（比如Nginx监听的80端口）的最大连接队列长度。如果这个值太小，在高并发时新连接会被直接丢弃（你会在错误日志里看到“connection reset by peer”）。把它调到2048或4096，让你的服务器能“排好队”处理请求。 另一个是net.ipv4.tcp_max_syn_backlog，它决定了半连接队列的长度。CC攻击里有一种SYN Flood变种，就爱怼这里。适当调大它，并结合启用net.ipv4.tcp_syncookies = 1，能在一定程度上缓解这类攻击。

（对了，调内核参数前务必做好记录和备份，线上环境别蛮干。最好先在测试环境验证效果。）

架构思考：别把鸡蛋放一个篮子

最后聊点“虚”但更根本的。为什么CC攻击总能找到漏洞？ 很多时候，是因为我们的架构太“直给”了——用户请求直接怼到源站服务器。

稍微有点追求的站点，真该考虑源站隐藏。别让你的真实服务器IP暴露在公网上。前面用高防IP、高防CDN或者云WAF扛着，它们负责清洗流量，只把干净的请求通过专线或者安全隧道回源到你的服务器。这样，攻击者连你的“家门”朝哪开都不知道，还CC个啥？

再进一步，业务如果能做动静分离，把图片、CSS、JS这些静态资源扔到对象存储或者CDN上，Web服务器只处理动态API，那么它需要维护的连接数和计算压力会小很多，抗CC的能力自然就上去了。

写在最后

防护CC攻击，从来不是买个硬件或者开个服务就一劳永逸的。它更像是一场攻防双方在资源管理效率上的贴身肉搏。

今天聊的这些优化，从Web配置到内核参数，其实都是在做一件事：让你的服务器更“小气”，只把宝贵的连接、CPU时间和内存，留给真正的用户请求。 对于那些赖着不走、疯狂敲门的“流氓”，要果断地设置门槛、缩短接待时间、甚至直接拒之门外。

说句大实话，很多所谓“高防服务器”，无非就是帮你把这些系统层的优化预先做了一部分。但你如果自己能搞明白这些门道，不仅能省下不少钱，下次再遇到突发流量（无论是攻击还是真实爆款），你心里也绝对不会慌。

行了，道理就这么多。下次再感觉网站“卡得不对劲”，别光盯着带宽流量图，先看看你的服务器连接数和系统负载吧，答案八成就在那里。