CC攻击的本质不是拼带宽，而是拼服务器处理请求的能力。攻击者控制大量代理或肉鸡，持续向目标网站发起看似正常的HTTP请求，这些请求往往精准指向搜索、数据库查询、动态页面生成等高消耗资源的功能点。当请求量超过服务器单位时间内能处理的上限，CPU、内存、数据库连接数会迅速被耗尽，正常用户访问就会变得极慢甚至完全无法打开。防御CC攻击的核心思路，不是单纯堆硬件，而是要在请求到达业务逻辑之前，用最小的成本识别并拦截恶意流量，同时保证正常请求不受影响。

第一步：先区分CC攻击与正常流量高峰

很多运维人员一看到服务器负载升高，第一反应就是被攻击了，但实际可能是正常业务增长或促销活动带来的突发流量。误判会导致错误的防御策略，比如把正常用户也拦截掉。判断CC攻击有几个明显特征：请求频率异常集中、User-Agent高度相似或固定、请求的URL分布极不均匀、大量请求不携带Cookie或Referer、访问时间间隔极短且规律。通过分析Nginx或Apache的访问日志，统计单位时间内同一IP或同一UA的请求次数，就能快速定位异常来源。如果日志显示某个IP每秒请求超过几十次甚至上百次，而正常用户不可能达到这个频率，基本可以判定为CC攻击。

第二步：利用Web服务器层做基础限速与连接控制

在Nginx中，可以通过ngx_http_limit_req_module和ngx_http_limit_conn_module两个模块实现请求频率和并发连接数的限制。这两个模块工作在请求处理的早期阶段，消耗资源极少，能有效拦截大量洪水式请求。配置示例如下：

http {
    # 定义请求频率限制区域，按客户端IP限制，每秒最多10个请求，突发20个
    limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
    # 定义并发连接数限制区域，每个IP最多同时保持5个连接
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

    server {
        location / {
            # 应用请求频率限制，突发允许20个，超过则返回503
            limit_req zone=req_per_ip burst=20 nodelay;
            # 应用并发连接数限制，超过则返回503
            limit_conn conn_per_ip 5;
        }
    }
}

这个配置能挡住大部分简单的CC攻击，但要注意rate和burst的值需要根据业务实际情况调整。如果设置过严，会误伤正常用户；设置过松，攻击者仍然能消耗服务器资源。对于API接口或登录接口这类高消耗的URL，可以单独设置更严格的限制，比如每秒1到2个请求。同时，建议在limit_req触发时返回503状态码而不是444，因为444会直接断开连接，某些情况下可能导致客户端不断重试，反而增加服务器压力。

第三步：通过防火墙和内核参数加固系统层防御

Web服务器层面的限制能处理一部分攻击，但如果攻击流量巨大，请求还没到达Nginx就已经占用了大量系统资源。这时候需要借助iptables或firewalld在系统层面做IP封禁和连接追踪限制。一个常用的方法是使用iptables的recent模块，对短时间内新建连接过多的IP进行动态封禁：

# 在INPUT链上记录每个IP的新建连接
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name CC_ATTACK --rsource
# 如果同一IP在60秒内新建连接超过30个，则直接丢弃
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 30 --name CC_ATTACK --rsource -j DROP

除了防火墙规则，内核参数优化也能显著提升服务器在遭受CC攻击时的稳定性。重点调整net.ipv4.tcp_max_syn_backlog、net.core.somaxconn、net.ipv4.tcp_syncookies等参数。开启SYN Cookie能有效防御SYN Flood型CC攻击，避免半连接队列被打满。调整net.ipv4.ip_local_port_range扩大可用端口范围，防止连接数过高时端口耗尽。这些参数需要写入/etc/sysctl.conf并执行sysctl -p使其生效。系统层的防御不能替代应用层防御，但能在大流量攻击时为上层服务争取更多处理空间。

第四步：部署专业的WAF或反向代理做智能识别

当攻击者使用大量代理IP、随机User-Agent、模拟真实浏览器行为时，基于固定规则的限速和封禁就会失效。这时候需要引入具备行为分析能力的WAF或反向代理层。专业的WAF能通过机器学习模型分析请求特征，识别出自动化攻击流量。例如，正常用户访问网站时，通常会先请求HTML页面，然后加载CSS、JS、图片等静态资源，请求之间有一定的时间间隔和逻辑顺序。而CC攻击工具往往只请求某个特定URL，或者按照固定顺序循环请求，缺少完整的页面资源加载行为。WAF可以通过检测请求序列的完整性、鼠标移动轨迹、Cookie有效性等维度来区分人机流量。

在架构上，将WAF或反向代理部署在源站前面，所有流量先经过清洗再转发到源站。这样即使攻击流量再大，源站只需要处理经过过滤后的正常请求。对于没有预算购买商业WAF的团队，可以使用开源的ModSecurity配合自定义规则，或者使用Nginx+Lua脚本实现简单的行为分析。例如，通过Lua脚本检查请求是否携带合法的Cookie，如果没有则返回一个JavaScript挑战页面，要求客户端执行JS并重新请求。大多数CC攻击工具不支持JS执行，因此无法通过挑战，而正常浏览器可以自动完成。

第五步：优化应用层代码和数据库查询，降低单请求消耗

CC攻击之所以能快速拖垮服务器，往往是因为被攻击的URL背后有高消耗的数据库查询或复杂计算。如果能把单个请求的资源消耗降低，服务器能承受的请求量就会大幅提升。检查被攻击的页面是否存在未优化的SQL查询、是否缺少缓存、是否有不必要的循环或递归。对于搜索功能，可以限制搜索关键词长度、增加搜索结果缓存时间、对热门搜索词做静态化处理。对于列表页和详情页，使用Redis或Memcached做页面缓存，减少数据库访问次数。如果攻击者针对的是某个动态接口，可以考虑对该接口做异步化处理，将耗时操作放入队列后台执行，前端快速返回。

数据库层面，确保所有查询都走索引，避免全表扫描。对于高并发场景，使用读写分离和连接池来分散压力。如果攻击者大量请求同一个需要数据库查询的URL，即使请求频率不高，数据库连接数也可能被占满。设置数据库的最大连接数和查询超时时间，防止单个慢查询拖垮整个数据库服务。另外，将静态资源与动态请求分离，静态资源使用CDN分发，动态请求单独处理，这样即使动态部分受到攻击，静态资源仍然可以正常访问，用户体验不会完全中断。

第六步：利用CDN和分布式架构分散攻击流量

对于大规模CC攻击，单台服务器无论怎么优化都难以承受。CDN的节点分布在全球各地，攻击流量会被分散到不同节点上，源站只需要处理回源请求。CDN服务商通常自带DDoS和CC防护能力，能在边缘节点识别并拦截恶意请求。配置CDN时，需要将源站IP隐藏，只允许CDN节点回源，防止攻击者绕过CDN直接攻击源站。可以通过防火墙规则限制只有CDN的IP段才能访问源站的80和443端口。

如果业务规模较大，可以考虑将服务拆分为多个微服务，部署在不同的服务器或容器中，通过负载均衡分发请求。这样即使某个服务受到攻击，其他服务仍然可以正常运行。使用Kubernetes等容器编排平台，可以根据流量自动扩容，在攻击发生时快速增加实例数量来应对。但自动扩容需要配合流量清洗，否则攻击流量也会触发扩容，导致成本急剧上升。

第七步：建立实时监控和自动化响应机制

防御CC攻击不是一次性配置就能高枕无忧的，攻击者会不断变化手法。需要建立实时监控体系，对服务器负载、请求量、响应时间、错误率等指标进行持续监控。当指标异常时，系统能自动触发告警并执行预设的防御策略。例如，使用Prometheus收集Nginx和系统指标，配合Alertmanager发送告警。当检测到某个IP的请求频率超过阈值时，自动调用API将该IP加入防火墙黑名单。监控数据还能帮助分析攻击特征，为后续的防御策略调整提供依据。

日志分析是监控的重要组成部分。建议将访问日志集中存储，使用ELK或类似工具进行实时分析。通过聚合统计，可以快速发现攻击来源IP段、攻击目标URL、攻击时间分布等信息。对于大规模攻击，可以分析出攻击者使用的代理IP池，提前将整个IP段加入黑名单。同时，保留攻击期间的日志样本，用于后续的安全审计和策略优化。

防御CC攻击需要多层配合，从系统层到应用层，从固定规则到智能分析，每一层都有其不可替代的作用。单纯依赖某一种手段很容易被绕过，只有将限速、封禁、行为分析、缓存优化、架构分散和实时监控结合起来，才能在攻击发生时最大程度降低服务器负载压力，保证业务的持续可用。