CC攻击（Challenge Collapsar）是针对Web应用层最常见的攻击手段之一。与DDoS那种依靠海量流量打带宽不同，CC攻击的请求量可能并不夸张，但每一个请求都直指业务中最消耗资源的接口，比如数据库查询、全文检索、复杂数据渲染等。攻击者通过控制大量代理或肉鸡，模拟正常用户行为持续发起请求，直到服务器CPU、内存、数据库连接池被耗尽，真实用户无法访问。WAF（Web应用防火墙）是防御CC攻击的核心工具，但很多部署了WAF的站点依然被打垮，问题往往不在WAF本身，而在于配置和调优不到位。
理解CC攻击的特征与识别难点
要做好调优，首先得明白CC攻击长什么样。典型的CC攻击有几个明显特征：单一IP或单一会话在短时间内高频访问同一URL、请求头中User-Agent高度重复或明显异常、请求参数虽然合法但访问路径高度集中于少数几个动态接口、来源IP分布呈现代理池特征（比如同一C段大量IP轮流请求）。
识别难点在于攻击请求在协议层面完全合法。攻击者可以伪造真实的浏览器User-Agent，可以携带正常的Cookie，甚至可以使用无头浏览器执行JavaScript，让每一个请求看起来都像真人操作。这就决定了单纯的IP黑名单或简单频控根本挡不住高级CC攻击，必须组合多种识别维度，并根据业务流量特征动态调整阈值。
另一个容易被忽视的点是业务自身的流量模型。比如秒杀活动开始瞬间，正常用户的请求频率可能比攻击还猛；搜索引擎爬虫的抓取行为也可能触发频控规则。调优的本质就是在误杀和漏杀之间找到平衡点，而这个平衡点因业务而异，没有通用答案。
核心防护策略的配置与调优
频率限制是抗CC的第一道防线，关键在于维度的选择和阈值的设定。不要只按单一IP维度限频，因为攻击者手里动辄几万个IP。建议采用多维度组合限频：IP+URL、IP+会话、全局URL维度等。以Nginx配合WAF的场景为例，一个常见的配置思路如下：
http {
# 按 IP + URI 维度限频：每秒 20 个请求，突发容忍 40 个
limit_req_zone $binary_remote_addr$uri zone=cc_per_uri:10m rate=20r/s;
# 全局按 IP 限频：每秒 100 个请求，防止单 IP 打多个接口
limit_req_zone $binary_remote_addr zone=cc_per_ip:10m rate=100r/s;
server {
location /api/search {
# 搜索接口消耗大，阈值收紧
limit_req zone=cc_per_uri burst=40 nodelay;
limit_req_status 429;
}
location / {
limit_req zone=cc_per_ip burst=200 nodelay;
}
}
}阈值怎么定？不要拍脑袋。正确做法是先开观察模式（只记录不拦截）跑几天，通过日志统计出正常流量的P99请求频率，然后把拦截阈值设定在正常峰值的3到5倍。阈值太紧会误杀，太松等于没设。对于登录、搜索、下单这类重点接口，可以单独收紧；对于静态资源则放宽甚至不限。
人机识别是第二道防线。当前主流WAF都支持JavaScript质询（JS Challenge）机制：客户端首次访问时返回一段JS代码，要求浏览器计算并回带结果，通过验证后下发Cookie放行后续请求。真实浏览器能执行JS并通过质询，而纯HTTP脚本工具则会卡在这一步。对于无头浏览器发起的高级CC，可以进一步升级到行为验证码，比如滑块、点选，只在频率异常时触发，避免影响正常用户体验。
会话跟踪同样重要。很多CC攻击会不断更换IP但复用同一会话标识，或者不断新建会话但IP不变。针对前者可以对单会话请求频率限速，针对后者可以限制单IP在单位时间内的会话创建数量。把IP、Session、UA指纹、TLS指纹（JA3）等多个维度交叉验证，识别准确率会显著提升。
误杀控制与持续优化
防护规则上线后最大的风险是误杀。多家运营商通过NAT出口共享公网IP，一所大学、一家公司可能上万人共用几个IP，直接按IP封禁一刀切，等于把大量真实用户挡在门外。因此封禁策略要分层设计：轻度超频只做延迟处理（比如排队响应），中度超频触发JS质询，重度超频才进入验证码环节，只有确认为自动化工具（质询不通过、JS不执行、TLS指纹异常）才执行封禁。
同时务必给封禁加上自动解封机制。推荐用递增封禁时长的方式：第一次违规封5分钟，再犯封30分钟，第三次封24小时。并且把已知搜索引擎爬虫UA加入白名单，同时验证其反向解析，防止攻击者伪造百度、Google的UA绕过检测。
# GeoIP + 白名单组合：可信来源直接放行
geo $trusted_client {
default 0;
# 搜索引擎爬虫网段（示例）
66.249.64.0/19 1; # Google
157.55.39.0/24 1; # Bing
}
server {
location / {
if ($trusted_client) {
# 可信来源跳过 CC 检测，直接走业务逻辑
return 200;
}
# 其他来源进入 WAF 检测链
}
}持续优化离不开日志分析。建议每周复盘一次WAF拦截日志和放行日志，重点关注三类数据：被拦截请求中是否出现正常业务特征（说明阈值偏紧）、被放行请求中是否存在高频异常模式（说明规则漏报）、触发质询的通过率（通过率过低说明质询策略过严）。根据复盘结果微调阈值，逐步收敛到适合自身业务的平衡点。
最后提醒一点：WAF不是万能的。当攻击流量规模大到把出口带宽打满，应用层防护就无能为力了，这时需要配合运营商流量清洗、CDN分散接入等手段形成纵深防御。平时做好接口的性能优化和缓存，减少单个请求的资源消耗，本身也是提高抗CC能力的有效方式。安全从来不是一次性配置，而是一个持续对抗、持续调优的过程。