网站半夜突然卡死，重启几分钟后又瘫——如果你遇到过这种场景，大概率不是配置不够，而是被 CC 攻击（Challenge Collapsar，通过海量 HTTP 请求耗尽服务器资源的攻击方式）盯上了。这篇指南会教你三件事：如何确认服务器被 CC 攻击、怎样用连接数分析和日志定位攻击来源、以及如何用 Nginx 限流和防火墙规则在半小时内完成止血。和常见的泛泛而谈不同，本文以一次真实的外贸站应急复盘为主线，每一步都给出可直接复制的命令和验证标准。
先确认：这些表现说明你被 CC 攻击了
CC 攻击最容易和”流量高峰”混淆，两者的本质区别在请求质量：正常访客会加载完整页面，攻击流量则反复请求少数几个消耗资源的接口。判断时重点看四个信号，而不是单看 CPU 数字。
第一看响应时间的走势。正常高峰是”尖峰回落”，CC 攻击是”平台状持续高压”——网站响应从 200ms 涨到 5 秒以上后不再回落，重启服务只能换来几分钟喘息。第二看连接状态分布。在服务器上执行 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'，如果 TIME_WAIT（连接关闭后的等待状态）占比超过一半，说明大量连接建立后立刻被丢弃，这是 CC 攻击最典型的指纹。第三看请求集中度。访问日志里同一批 IP 每秒发起几十次请求，且全部砸向登录页、搜索接口这类动态路径。第四看资源错位：CPU 和带宽被打满，但磁盘和内存一切正常——因为攻击消耗的是计算和连接资源，不是存储。
四条信号命中三条以上，就可以按 CC 攻击进入应急流程。这里有个常见误区要提醒：发现被攻击就急着升级配置，往往适得其反。攻击者看到你换了更大的机器，只会加大请求量，钱花了问题还在。正确顺序是先分析、再限制、最后才考虑扩容或换高防方案。
连接数分析：三步定位攻击来源
确认攻击后，先别急着封 IP。封错了正常用户等于自己给自己制造故障，正确做法是按”总量 → 单 IP → 请求路径”的顺序把攻击画像摸清楚，这三步在 Linux 服务器上各只需一条命令。
第一步看总量和状态。netstat -an | grep -E ':80|:443' | wc -l 统计 Web 端口的并发连接总数，如果数字是日常水平的 10 倍以上，配合前面说的 TIME_WAIT 占比过半，攻击规模就有了量化结论。第二步找嫌疑 IP。netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 按连接数倒序列出前 20 名：单一 IP 占总连接 30% 以上可以直接列为封禁对象；如果每个 IP 只有几十个连接、总量却很大，说明对方在用代理池，这时重点要转向第三步——路径分析。
第三步分析攻击打在哪里。用 awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10 统计被请求最多的 URL，再用 grep '嫌疑IP' /var/log/nginx/access.log | tail -100 | awk '{print $7}' | sort | uniq -c 看这个 IP 最近在访问什么。CC 攻击的请求几乎总是集中在少数”贵”的路径上：登录验证、搜索接口、评论提交。找到这条路径，后面的限流规则就有了明确靶子，而不是全站一刀切。
Nginx 限流：给异常流量设一道闸门
定位到攻击路径后，限流（Rate Limiting，限制单个 IP 单位时间内的请求次数）是最快见效的止血手段。阈值怎么定？有个简单算法：正常访客阅读一个页面至少停留 3-5 秒，把全站阈值设在每秒 10 次请求、攻击路径单独收紧到每秒 2 次，就能在挡住攻击和放过真实用户之间取得平衡。
在 Nginx 配置的 http 块中加入以下规则：
# 以客户端 IP 为键定义限流区域，10MB 内存约可跟踪 16 万个 IP
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
server {
listen 80;
# 全站限流：突发流量允许排队 5 个请求，超过直接拒绝
limit_req zone=one burst=5 nodelay;
# 对定位到的攻击路径单独收紧，例如登录接口
location = /wp-login.php {
limit_req zone=one burst=2 nodelay;
limit_req_status 503;
}
}
改完先跑 nginx -t 验证语法，再 systemctl reload nginx 生效。生效后用两个指标验证效果：503 错误率应稳定在总请求的 5% 以下（过高说明阈值太紧，误伤了真实用户），CPU 负载应在一两分钟内明显回落。如果两个指标都不达标，优先怀疑配置没生效或攻击路径判断错了，回到上一步重新分析日志；限流之外，日常的负载基线怎么定，可以参考服务器配置与优化专题中的性能指标说明。
有一个坑几乎每个用 CDN（Content Delivery Network，内容分发网络）的站点都会踩：$binary_remote_addr 拿到的是 CDN 节点的 IP，所有访客在 Nginx 眼里都是同一个来源，限流一开就是全站不可访问。解决办法是用 realip 模块从 X-Forwarded-For 头还原真实客户端 IP，再套用上面的规则。配置限流前务必确认这一步，否则止血动作本身就会变成事故。
防火墙规则：把顽固攻击源挡在门外
限流解决”请求太快”，防火墙解决”来源太坏”。对连接数分析中锁定的高频 IP，在防火墙层直接丢弃比让 Nginx 逐个处理更省资源——数据包在内核层就被丢掉，根本不会消耗 Web 进程的连接池。
以最常见的 firewalld 和 iptables 为例：
# firewalld：封禁单个攻击 IP
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.45" reject'
firewall-cmd --reload
# iptables：封禁一个攻击网段，适用于同段 IP 集中攻击
iptables -A INPUT -s 203.0.113.0/24 -j DROP
# 限制单 IP 的 80 端口并发连接数，超过 20 直接丢弃
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 20 -j DROP
封禁不是一次性的动作，要按”观察—封禁—复查”的节奏循环：封禁 30 分钟后回看日志，如果攻击切换了 IP 段，就更新规则再封。特别提醒做跨境电商的站长，切忌一上来就封整个国家或地区的网段——那会挡掉大量真实客户，损失可能比攻击本身还大。另外，可以把 SSH 等管理端口改成非常规端口并只放行自己的常用 IP，先把攻击面收窄一圈。
如果你的业务对可用性要求高、又没有专职运维盯着日志，可以考虑把这类规则和高防线路配合使用。例如 Hostease 的独立服务器提供高防选项（防护方案与价格截至 2026 年 10 月，以官网实时报价为准），前置清洗掉大流量攻击后，服务器上的限流和封禁规则只需处理漏网的低频请求，两层防线各司其职。
实战复盘：一次 30 分钟的完整应急
把前面的步骤串起来看一个真实案例。某外贸独立站晚上 9 点被盯上：首页每秒被请求 80 次，CPU 飙到 95%，网站几乎瘫痪。站长按本文流程操作——先用 netstat 确认并发连接从日常的 400 涨到 9000，TIME_WAIT 占比约六成，确认是 CC 攻击；再统计 IP，发现 3 个 IP 各占 25% 的连接；日志显示这些请求全部集中在 /wp-login.php。
接下来他在 Nginx 给登录页单独设了每秒 2 次的限流阈值，并用 iptables 封掉 3 个攻击 IP 所在的 /24 网段。15 分钟后 CPU 回落到 30%，网站恢复访问，全程没有换服务器、没有升级配置、没有花一分钱买高防。这个案例的价值在于展示决策顺序：先量化确认、再精准打击，绝大多数几十 G 以下量级的 CC 攻击，靠连接数分析加限流规则就能解决，真正需要高防硬件的是少数极端场景。
复盘里还有一个容易忽略的细节：攻击停止后的 24 小时内是二次攻击高发期，攻击者会换 IP 段再来一次。所以应急结束不等于收工，日志监控要至少再保持一周。
长期防护：把下一次攻击的损失降到最低
应急只是止血，要避免每次都半夜起来救火，建议把三件事纳入日常运维。第一，基础监控加告警：CPU 负载、并发连接数、带宽（服务器单位时间内可传输的数据量，好比公路的车道宽度）三项各设阈值（比如并发连接超过日常均值 5 倍就告警），攻击发生时第一时间知道，而不是等客户投诉。第二，静态资源接入 CDN，让攻击流量在前置节点被吸收，回源请求大幅减少，相当于给源站加了一层缓冲垫。第三，如果业务持续被攻击或攻击量级明显上升，推荐评估自带 DDoS 防护的主机方案，把专业清洗能力补齐。
如果你现在正运营着对可用性敏感的业务，建议今天就做一次演练：挑一个低峰时段，按本文步骤完整走一遍连接数分析和限流配置，确认自己能在 15 分钟内独立完成应急。更多的服务器安全与性能内容，可以结合我们的服务器配置与优化专题和TTFB 网站加速指南一起看。总结一下：确认攻击特征、三步定位攻击源、限流加防火墙止血、最后补上长期监控——这四步就是应对 CC 攻击的完整闭环，照着做，下一次攻击来临时你就不会再手忙脚乱。