CC攻击来袭?手把手教你打造云服务器防护盾

网站突然变慢、后台登录超时、数据库连接池被打满——如果你的云服务器出现了这些症状，大概率正在遭受CC攻击。和动辄几百G带宽的DDoS洪水不同，CC攻击不需要巨大的流量，它的杀伤力在于用看似正常的HTTP请求把服务器的CPU、内存和数据库连接一点一点耗干。正因为每一个请求单独看都像正常用户，传统的带宽扩容根本不起作用。

这篇文章从实战角度出发，讲清楚怎样一步步在云服务器上搭建一套完整的CC攻击防护体系。

先搞清楚你面对的是什么

CC攻击的本质是"资源耗尽型攻击"。攻击者控制大量代理IP或肉鸡，对你的网站持续发起高频HTTP请求，专挑那些需要服务器做大量计算的页面下手——比如搜索接口、登录验证、商品列表、订单查询这类需要频繁读写数据库的动态页面。

它的危险之处在于三点：单个请求合法，频率不一定极高，但持续时间长。很多站长被打了半天才反应过来，服务器资源早已被掏空。

第一层：Nginx层面的基础拦截

Nginx是大多数云服务器的入口，在这一层做好基础防护可以挡掉一大批低级CC攻击。

限制单IP并发连接数和请求速率

在nginx.conf的http段中配置：

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=30r/s;

在server段或location段中应用：

limit_conn conn_limit 50;
limit_req zone=req_limit burst=60 nodelay;

这组配置的含义是：每个IP最多同时保持50个连接，每秒最多处理30个请求，允许短时突发到60个。超出限制的请求直接返回503。数值需要根据自身业务的正常流量水平来调整，设置太低会误伤正常用户。

针对动态接口单独加严

搜索、登录、API这类高消耗接口，应该单独设置更严格的限流：

location /api/search {
    limit_req zone=api_strict burst=10 nodelay;
    proxy_pass http://backend;
}

api_strict可以定义为rate=5r/s，让敏感接口拥有独立且更严格的频率管控。

屏蔽异常User-Agent

很多低级CC工具的User-Agent为空或带有明显的工具特征。在server段加入：

if ($http_user_agent = "") { return 403; }
if ($http_user_agent ~* "python|curl|wget|httpclient|okhttp") {
    return 403;
}

注意，这只是基础过滤。高级CC攻击会伪造正常浏览器的User-Agent，不能完全依赖这一条规则。

第二层：系统内核参数调优

云服务器默认的内核参数往往偏保守，在CC攻击下很容易因为连接数耗尽而崩溃。以下几个关键参数建议调整：

# 开启SYN Cookie防护
net.ipv4.tcp_syncookies = 1

# 加速TIME_WAIT状态的回收
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 增大半连接队列和全连接队列
net.ipv4.tcp_max_syn_backlog = 65535
net.core.somaxconn = 65535

# 减少keepalive超时时间
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3

写入 /etc/sysctl.conf 后执行 sysctl -p 生效。这些参数的作用是让服务器更快释放无效连接，腾出资源处理真实请求。

第三层：iptables/nftables实时封堵

当Nginx日志中发现某些IP请求频率明显异常时，可以用iptables直接在网络层拦截，连HTTP解析的资源都不消耗：

iptables -I INPUT -s 恶意IP -j DROP

手动封IP效率太低，可以写一个简单的自动化脚本，每分钟分析一次Nginx访问日志，把超过阈值的IP自动加入封禁列表：

#!/bin/bash
tail -n 5000 /var/log/nginx/access.log \
  | awk '{print $1}' \
  | sort | uniq -c | sort -rn \
  | awk '$1 > 500 {print $2}' \
  | while read ip; do
      iptables -C INPUT -s "$ip" -j DROP 2>/dev/null \
        || iptables -I INPUT -s "$ip" -j DROP
    done

配合crontab每分钟执行一次，能够快速响应突发的CC攻击。注意同时维护一个白名单机制，避免把监控系统或合作方的IP误封。

第四层：fail2ban自动化联动

fail2ban是Linux下成熟的入侵防御工具，可以实时监控Nginx日志并自动封禁异常IP。

安装后创建一个针对CC攻击的自定义规则文件 /etc/fail2ban/jail.d/cc-attack.conf：

[cc-attack]
enabled = true
filter = cc-attack
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=cc, port="80,443", protocol=tcp]

对应的过滤器 /etc/fail2ban/filter.d/cc-attack.conf：

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"

含义是：60秒内同一IP触发100次匹配则封禁1小时。这比手动脚本更可靠，fail2ban会自动管理封禁和解封的生命周期。

第五层：接入高防CDN，从根源上解决问题

以上四层都是在服务器本机做防护，能挡住中小规模的CC攻击。但当攻击源IP数量达到数千甚至上万个、每个IP的请求频率又控制在正常范围内时，单机防护就力不从心了。

这时候需要在服务器前面加一层高防CDN。将域名的DNS解析指向CDN的CNAME地址后，所有流量先经过CDN的边缘节点。CDN节点具备AI行为分析引擎，能从访问路径、会话连贯性、TLS指纹、请求时序等多个维度判断请求是否来自真实用户。恶意请求在边缘就被拦截，根本不会到达你的源站服务器。

同时，高防CDN会隐藏源站的真实IP。即使攻击者拿到了你的源站IP，也可以通过更换IP并仅允许CDN回源IP访问的方式彻底切断直连攻击路径。在iptables中只放行CDN回源网段，拒绝所有其他来源的直接访问：

iptables -A INPUT -p tcp --dport 80 -s CDN回源IP段 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s CDN回源IP段 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

这样即使源站IP泄露，攻击者也无法绕过CDN直接打到服务器。

总结一下

应对CC攻击不能靠单一手段，而是需要构建多层纵深防御体系。Nginx限流解决基础过滤，内核调优提升连接处理能力，iptables和fail2ban实现自动化封堵，高防CDN从外层彻底隔离攻击流量和真实源站。四层叠加起来，你的云服务器才真正具备了抗住CC攻击的能力。