一、先分清：CC攻击不是DDoS，处理思路完全不同

在十堰网络安全的日常应急里，有一类故障最容易引起误判：客户打电话说"网站打不开了，是不是服务器坏了"，运维登录一看，CPU 和内存占用正常，带宽只跑了 20%，Nginx 也在正常响应，但用户端就是超时。这十有八九不是服务器故障，而是CC（Challenge Collapsar）攻击。

很多人把 CC 和 DDoS 混为一谈，其实两者的防护重点完全相反：

流量型 DDoS：靠海量垃圾包把带宽打满，特征是入向流量暴涨、丢包率飙升。防护靠运营商或云厂商的流量清洗，本地设备基本无能为力。
CC 攻击：请求量不大，带宽占用很低，但每一个请求都是"合法"的 HTTP 请求，专打应用层最耗资源的那个环节——搜索接口、登录接口、列表分页、动态渲染页。特征是并发连接数暴涨、后端响应时间变长、数据库连接池被打满。

这个区别决定了：给 CC 攻击加带宽是没用的，加带宽只会让攻击者打得更顺手。真正有效的做法是在应用层做区分——把正常用户和机器流量分开，这才是本文要讲的三层防护。

二、第一步：确认是不是CC攻击

不要凭感觉判断，先用数据说话。以下四个信号出现两个以上，基本可以确认：

2.1 看并发连接与请求速率

在服务器上执行以下命令，观察实时连接情况：

# 当前 ESTABLISHED 连接数
ss -ant | grep ESTAB | wc -l
# 按 IP 统计连接数，取前 20
ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
# 实时请求速率（每秒请求数）
tail -f /var/log/nginx/access.log | pv -l -i 5 2>/dev/null

如果单个 IP 的连接数超过 100，或者总 QPS 在几分钟内从 30 跳到 800，而当时的真实用户并没有增加，那就是攻击流量。

2.2 看访问日志的"共性特征"

CC 攻击的请求往往高度同质化，用一条命令就能看出来：

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

如果排第一的 URL 占了总请求量的 60% 以上，而且集中在一个动态接口（比如 /search?kw= 或 /api/list），这就是典型的"打单点"。再看 User-Agent：

awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

如果前几名是 python-requests、Go-http-client、curl/7.x 这类脚本 UA，或者大量完全相同的"Mozilla/5.0 (Windows NT 10.0)"没有任何版本细节，基本可以锁定是工具在跑。

2.3 看后端是否被拖垮

CC 攻击的真正杀伤点在数据库。登录服务器执行 mysql -e "show processlist"，如果看到几十个 Sleep 之外的 Query 状态长期卡在同一个慢查询上，说明应用层已经被打穿。这时候重启 PHP 或 Node 进程只能撑几分钟，必须从入口限流。

三、第一层防护：Nginx 限流，5 分钟就能上线

限流是成本最低、见效最快的一层，不需要额外采购任何设备。核心是两条指令：limit_req（限制请求速率）和 limit_conn（限制并发连接数）。

3.1 在 http 块定义限流区

http {
    # 按 IP 限制请求速率：10MB 共享内存，平均 5 请求/秒
    limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=5r/s;
    # 按 IP 限制并发连接：同一 IP 最多 20 个并发
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    # 单独给登录、搜索等敏感接口定义更严格的区
    limit_req_zone $binary_remote_addr zone=req_strict:10m rate=1r/s;
}

3.2 在 server / location 块应用

server {
    listen 443 ssl http2;
    server_name www.example.com;

    limit_conn conn_per_ip 20;
    limit_req zone=req_per_ip burst=20 nodelay;
    limit_req_status 429;
    limit_conn_status 429;

    # 搜索接口：最容易被 CC 打的地方，单独收紧
    location /search {
        limit_req zone=req_strict burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }

    # 静态资源不限流，避免误伤正常用户
    location ~* \.(js|css|png|jpg|webp|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

参数怎么定？这几个数字是实战调出来的：

rate=5r/s + burst=20：正常用户点开一个页面会并发请求 10 到 20 个资源，burst 太小会误伤，20 是一个比较安全的起点。
nodelay：不加这个参数，超出的请求会被排队延迟处理，用户会感觉网站变慢；加上它，超出部分直接返回 429，正常用户几乎无感，攻击者立刻被挡。
敏感接口 rate=1r/s：登录、短信验证码、搜索这些接口正常用户不会一秒点一次，可以压到 1r/s。

上线后一定要观察一天，重点看 429 的比例。正常情况下 429 应该低于总请求的 0.5%，如果超过 3%，说明阈值定得太严，正在误伤真实用户。

四、第二层防护：人机校验，把脚本挡在业务逻辑之外

限流只能"减速"，挡不住分布式 IP 的慢速攻击。第二层要解决的是"这个请求到底是不是人发出来的"。

4.1 拦截伪造与空 UA

大量 CC 工具的 UA 是写死或为空的，第一步先在 Nginx 层做基础过滤：

# 空 UA 直接拒绝
if ($http_user_agent = "") { return 403; }
# 常见脚本 UA 拉黑
if ($http_user_agent ~* "(python-requests|Go-http-client|curl/|scrapy|apache-httpclient)") {
    return 403;
}
# 禁止直接以 IP 访问（绕过 CDN 直连源站的特征）
if ($host !~* ^(www\.)?example\.com$) { return 444; }

4.2 Cookie 挑战（JS Challenge）

真正的浏览器会执行 JavaScript 并携带 Cookie，脚本通常不会。可以在 Nginx 里用 auth_request 或 Lua 做一次轻量挑战：首次访问返回一段计算 Cookie 的 JS，客户端带正确 Cookie 再来才放行。云 WAF 产品一般把这个功能叫"JS 挑战"或"5 秒盾"，开启后能挡掉 90% 以上的低成本 CC 工具流量。

4.3 高频路径加验证码

对于搜索、登录这类必然被盯上的接口，与其被动挨打，不如主动加一道图形验证码或滑块。经验数据是：加上滑块后，搜索接口的机器请求下降 95% 以上，而真实用户的完成率仍有 92% 左右——这个交换是划算的。

五、第三层防护：隐藏源站 + CDN 清洗

前两层都在源站上做，问题是攻击流量已经打到了你的服务器，带宽和连接数已经被消耗。第三层的思路是让攻击者根本找不到源站。

接入 CDN 或云 WAF，把域名解析指向 CDN 节点，源站只允许 CDN 回源 IP 段访问（在安全组里配置白名单），其他来源一律拒绝。
换掉暴露过的源站 IP。很多企业源站 IP 是通过历史 DNS 记录、邮件头、子域名泄露出去的。接入 CDN 后必须更换服务器 IP，否则攻击者直连 IP 就能绕过所有防护。
迁移管理后台。后台不要放在公网 80/443 上，改成独立端口 + IP 白名单，或者干脆走内网 / 跳板机。十堰不少企业网站被攻破，入口就是暴露在公网的 /admin。
开启 CC 防护策略。主流云 WAF 都提供基于 QPS、基于会话频率的 CC 防护规则，把"单 IP 10 秒内超过 50 次请求"设为观察模式跑三天，确认误杀率后再切阻断。

六、两个十堰本地的处置复盘

案例一：十堰某商贸公司官网，搜索接口被打瘫 6 小时。现象是首页能开、点搜索就转圈，数据库 CPU 打满。排查发现攻击集中在 /search?kw=，单 IP 峰值 340 请求/秒，UA 全是 python-requests/2.28。处置动作：先在 Nginx 加 limit_req zone=req_strict burst=5，5 分钟内搜索接口恢复；随后在 WAF 层封禁该 UA 段并加入滑块验证；最后把搜索改成 Redis 缓存热门关键词，同一关键词 5 分钟内只查一次库。整个过程业务停机时间 40 分钟，后续一周未再复发。

案例二：十堰某制造企业，被"慢速 CC"拖了两周。这家企业没有明显的流量峰值，但每天上午 10 点前后网站必然变慢，运维重启就好，第二天照旧。查日志才发现是 200 多个 IP 轮流访问，每个 IP 每分钟只发 8 个请求，刚好卡在限流阈值下面。这类攻击靠单 IP 限流无效，最终方案是：接入 CDN 隐藏源站 + 开启基于会话的 CC 策略 + 把动态页改成静态生成（SSG）。改造后首屏响应从 1.8 秒降到 220 毫秒，攻击流量在 CDN 边缘就被消化，源站几乎没有感知。

七、常态化防护清单

CC 攻击不会只来一次，把下面几条做成常态，比事后救火划算得多：

限流配置纳入版本管理，新上线的接口默认继承全局限流规则；
为 /search、/login、/api/* 单独设定阈值，并监控 429 比例；
热门列表页、详情页尽量做静态化或加缓存，减少打到数据库的请求；
源站只对 CDN 回源 IP 开放，管理后台走白名单；
配置日志告警：单 IP 5 分钟内 429 超过 50 次、QPS 突增 3 倍自动通知；
每季度做一次压测，摸清自家服务器在多少 QPS 下会出问题，这个数字决定了限流阈值该定在哪。

八、结语

CC 攻击的本质不是"流量太大"，而是"请求太贵"。防护的核心思路始终是三条：在入口用限流降低成本，在中间用人机校验区分真假，在外围用 CDN 隐藏源站。三层叠加，绝大多数针对中小企业的 CC 攻击都能被挡在业务之外。

作为扎根本地的技术服务商，十堰易度网络传媒有限公司在十堰网络安全领域服务过多家制造、商贸、教育类企业，处理过从单点接口被打瘫到持续两周慢速 CC 的各类场景。如果你发现自家网站出现"能打开但很慢""上午必卡""后台进不去"这类规律性故障，不要急着加带宽或者换服务器——先做一次流量分析，很可能问题就出在应用层。十堰企业的网站安全，值得用一套完整的防护体系来对待，而不是等被打挂了才想起限流。

十堰企业网站被CC攻击怎么办：Nginx限流、人机校验与CDN防护实战（2026版）