CC攻击的本质不是拼带宽，而是拼服务器处理请求的资源消耗。攻击者通过控制大量傀儡机或代理节点，持续向目标网站的特定URL发起看似正常的HTTP请求，这些请求往往集中在搜索接口、动态页面、验证码刷新、登录提交等需要消耗数据库或CPU资源的路径上。当请求量超过服务器单位时间内的处理上限，正常用户就无法访问，表现为页面卡顿、响应超时或直接502/503。因此，抵御CC攻击的核心思路只有一条：在请求进入业务逻辑之前，用最低成本识别并拦截异常流量，同时保证正常用户的请求不受影响。

一、先区分CC攻击与普通高并发

很多运维人员一看到服务器负载升高就以为是CC攻击，实际上普通高并发和CC攻击有本质区别。普通高并发的流量来源分散、请求路径多样、User-Agent和Referer分布自然，且流量高峰通常与业务活动时间吻合。CC攻击则表现为：大量请求集中在少数几个URL、请求间隔极短且规律、同一IP或IP段反复出现、User-Agent高度一致或完全缺失、Referer为空或固定值。通过分析Nginx或Apache的访问日志，统计单位时间内请求频率最高的IP和URL，可以快速判断攻击类型。建议先用命令统计访问频次，例如：

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

如果排名靠前的IP请求量远超正常水平，且请求路径单一，基本可以判定为CC攻击。

二、Nginx核心防护配置

Nginx是目前使用最广泛的Web服务器和反向代理工具，其内置的限流模块和连接控制能力足以应对多数中小规模CC攻击。关键配置包括限制单IP请求速率、限制并发连接数、限制请求体大小以及超时时间优化。

在http块中定义限流区域：

limit_req_zone $binary_remote_addr zone=cc_limit:20m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:20m;

在server或location块中应用：

limit_req zone=cc_limit burst=50 nodelay;
limit_conn conn_limit 20;

上述配置表示每个IP每秒最多20个请求，突发最多50个，超过部分直接返回503，同时限制每个IP并发连接数为20。需要根据业务实际调整rate和burst值，过严会误伤正常用户，过松则无法有效拦截。对于搜索、登录等敏感接口，可以单独设置更严格的限流策略，例如每秒5个请求，突发10个。

另一个容易被忽略的配置是client_body_timeout和client_header_timeout，适当缩短这两个值可以快速释放被慢速攻击占用的连接资源。建议设置为10秒以内。

三、利用防火墙与内核参数加固

仅靠Nginx限流在面对大规模分布式CC攻击时仍然不够，因为攻击请求依然会到达服务器并消耗连接资源。此时需要在防火墙层面进行IP封禁和连接跟踪优化。iptables的hashlimit模块可以根据源IP的包速率进行动态封禁，例如：

iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-name http_limit --hashlimit-above 30/sec --hashlimit-burst 50 --hashlimit-mode srcip -j DROP

该规则表示单个源IP每秒超过30个TCP包时直接丢弃。配合ipset可以批量封禁攻击源IP，效率远高于逐条iptables规则。内核参数方面，建议调整以下参数：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 5000

开启SYN Cookies可以防御SYN Flood类攻击，减少半连接队列占用。降低SYN重试次数和FIN超时时间可以加快连接回收速度，提升服务器在攻击状态下的抗压能力。

四、CDN与WAF的协同防御

对于流量规模较大的CC攻击，单机防护的瓶颈在于带宽和计算资源。接入CDN后，攻击流量会被分散到边缘节点，源站只处理回源请求。CDN服务商通常自带基础的CC防护能力，例如根据请求频率、IP信誉库、行为特征进行拦截。但CDN的默认防护策略往往比较宽松，需要根据业务场景手动配置防护规则。建议开启CDN的智能限速、IP黑名单、区域封禁等功能，并将回源IP加入源站防火墙白名单，只允许CDN节点访问源站。

WAF（Web应用防火墙）则侧重于应用层攻击检测，可以识别CC攻击中常见的特征，例如同一Cookie反复请求、特定User-Agent高频访问、请求间隔异常等。WAF的规则引擎可以针对特定URL设置访问频率阈值，并支持验证码挑战、JS跳转等人机识别手段。将CDN与WAF串联使用，可以形成“边缘清洗+应用层过滤”的双层防线。

五、动态挑战与行为验证

当攻击请求已经绕过限流和防火墙时，最后一道防线是在应用层增加动态挑战机制。常见做法是对可疑请求返回一段JavaScript代码，要求客户端执行计算并回传结果，或者弹出验证码要求人工识别。这种方式对正常用户影响较小，但能有效阻断自动化攻击脚本。实现方式可以是在Nginx层通过Lua脚本判断请求频率，对超过阈值的IP返回验证页面，验证通过后写入Cookie白名单，后续请求携带合法Cookie即可正常访问。

需要注意的是，动态挑战不应全站启用，否则会严重影响搜索引擎抓取和用户体验。建议只对搜索、登录、注册等敏感接口启用，并设置合理的挑战触发阈值。

六、日志监控与自动化响应

CC攻击的防御不是一次性配置就能一劳永逸，攻击者会不断更换IP和请求特征。因此需要建立持续的监控和自动化响应机制。可以通过脚本定时分析Nginx访问日志，提取高频IP并自动加入防火墙黑名单。例如使用crontab每分钟执行：

awk '{print $1}' access.log | sort | uniq -c | sort -rn | awk '$1 > 100 {print $2}' | xargs -I {} iptables -A INPUT -s {} -j DROP

更完善的做法是使用Fail2ban等工具，根据自定义规则自动封禁异常IP，并设置封禁时长。同时建议将访问日志接入ELK或类似日志分析平台，实时监控QPS、错误率、响应时间等指标，当指标异常时触发告警。

七、架构层面的冗余与弹性扩容

无论防护策略多么完善，单台服务器的处理能力始终有限。在架构设计上，应尽量将静态资源与动态请求分离，静态资源走CDN或对象存储，动态请求通过负载均衡分发到多台后端服务器。当遭遇大规模CC攻击时，可以快速扩容后端实例，通过增加处理能力来分摊攻击压力。云服务器的弹性伸缩功能可以在负载持续升高时自动增加节点，配合负载均衡器的健康检查，实现攻击状态下的业务可用性保障。

此外，数据库层面也需要做好连接池配置和慢查询优化，因为CC攻击往往针对数据库密集型接口。将热点数据缓存到Redis或Memcached中，减少数据库直接查询压力，可以显著提升抗攻击能力。

八、常见误区与注意事项

很多运维人员在配置CC防护时容易陷入几个误区。第一是过度依赖IP封禁，攻击者使用代理池时IP变化频繁，封禁效果有限且容易误伤共享IP的正常用户。第二是限流阈值设置过严，导致正常用户频繁触发验证码或直接无法访问，造成业务损失。第三是忽视IPv6流量，部分攻击者已经开始使用IPv6地址发起攻击，而防火墙和限流规则往往只针对IPv4。第四是只防HTTP不防HTTPS，攻击者可以直接对443端口发起请求，绕过针对80端口的防护规则。

正确的做法是结合多种手段，根据实际业务流量基线动态调整阈值，定期复盘攻击日志，持续优化防护策略。同时保持对新型攻击手法的关注，例如HTTP/2慢速攻击、TLS握手消耗攻击等，及时更新防护方案。

CC攻击的防御本质上是一场资源消耗的博弈，没有绝对完美的方案，但通过合理的分层防护和持续优化，可以将攻击影响降到最低，保障核心业务的稳定运行。