防御CC攻击业务低影响防护规则调试

防御CC攻击最棘手的地方在于，规则调得太严，正常用户被误杀，业务转化率直线下降；调得太松，攻击流量又压垮服务器。真正能落地的方案不是堆砌防护强度，而是建立一套基于业务特征的“低影响”过滤模型，让攻击请求在触达核心业务前就被剥离，同时保证正常用户全程无感。

CC攻击的本质是消耗服务器资源，尤其是数据库读写、动态脚本执行和带宽吞吐。低影响防护的核心思路不是“识别攻击者”，而是“识别正常用户”，再对非正常流量做分级处理。这个顺序反了，误杀率就一定高。

很多运维一上来就对全站IP做频率限制，比如单IP每秒超过20次请求就封禁。这种做法对静态站可能有效，但对有登录、搜索、购物车等动态业务的站点，误伤极大。一个正常用户在秒杀场景下，可能瞬间发出几十个AJAX请求，和攻击流量在频率上几乎没有区别。

正确做法是先给每个请求打上业务指纹。指纹维度包括：请求URL的目录深度、是否携带合法的Cookie会话、是否包含正确的Referer、请求的是静态资源还是动态接口、User-Agent是否与常见浏览器特征一致、是否携带了必要的自定义Header（如X-Requested-With）。把这些维度组合起来，形成一个请求画像。

例如，一个没有Cookie、没有Referer、直接请求“/api/order/create”接口的请求，即使频率很低，也应当进入观察名单。而一个携带有效会话、Referer来自站内页面、请求的是“/js/main.js”的请求，即使频率高，也不应该被拦截。这样就把防护粒度从“IP维度”细化到了“请求特征维度”。

低影响防护的关键在于处置手段的梯度设计。不要一上来就封IP，因为攻击者换IP的成本极低，而正常用户被误封后可能永远流失。推荐使用三级处置流程。

第一级是JS挑战或Cookie验证。对于请求指纹异常但频率不高的流量，返回一段JavaScript代码，要求浏览器执行后回传一个计算值。正常浏览器会自动执行并通过验证，而多数CC攻击脚本不具备完整的JS执行环境，会被直接过滤掉。这个环节对正常用户几乎无感，延迟增加不超过100毫秒。

第二级是动态限速。针对通过第一级验证但请求频率仍然异常的IP，实施基于滑动窗口的动态限速。这里的关键是限速阈值不能固定，要根据业务接口的复杂度动态调整。比如“/api/search”接口的阈值可以设高一些，因为搜索本身消耗资源较少；而“/api/pay/submit”接口的阈值要设低，因为涉及数据库事务和第三方调用。可以通过Nginx的limit_req_zone配合不同的zone来实现。

第三级才是临时封禁。只有在前两级都失效，且该IP的请求持续对后端造成明显压力时，才触发封禁。封禁时间建议设置为5到15分钟，而不是永久封禁。因为大量攻击源来自动态IP池或NAT出口，永久封禁可能误伤同一出口下的其他正常用户。

真正低影响的防护，是把防护逻辑嵌入业务代码里，而不是完全依赖边缘节点。举个例子，对于需要登录后才能访问的接口，可以在用户登录成功后生成一个加密的访问令牌，前端每次请求都要带上这个令牌，后端在业务逻辑入口处做一次轻量级校验。攻击者即使绕过了边缘防护，没有合法令牌也无法触达核心业务。

这个令牌的生成可以绑定设备指纹和会话ID，使用HMAC算法签名，有效期设为会话时长。校验逻辑放在业务网关层，用内存缓存做快速比对，性能开销极低。这样做的好处是，即使攻击者伪造了Cookie，也无法伪造令牌，因为令牌的生成密钥只在服务端保存。

另一个有效的业务层防护是“动态路径混淆”。对于关键接口，可以定期更换URL路径，比如“/api/v1/order”每隔一段时间变为“/api/v1/order_7f3a”。正常用户通过页面加载时获取最新的路径，而攻击者扫描到的旧路径会直接返回404。这种方案对SEO有一定影响，需要配合规范化的canonical标签和301跳转来降低负面效果，但对于防御CC攻击效果显著。

下面给出一套可实际部署的Nginx配置片段，展示如何在不影响正常用户的前提下过滤CC攻击流量。

# 定义请求指纹判断变量
map $http_cookie $has_cookie {
    default 0;
    "~*session_id" 1;
}

map $http_referer $valid_referer {
    default 0;
    "~*^https?://(www\.)?example\.com" 1;
}

# 第一级：对无Cookie且无Referer的动态请求做JS挑战
location /api/ {
    if ($has_cookie = 0) {
        set $challenge "1";
    }
    if ($valid_referer = 1) {
        set $challenge "0";
    }
    if ($challenge = "1") {
        rewrite ^ /challenge.html last;
    }

    # 第二级：对通过挑战的IP做动态限速
    limit_req zone=api_zone burst=30 nodelay;
    limit_req_status 429;

    proxy_pass http://backend;
}

# 第三级：对持续超限的IP做临时封禁
location /challenge.html {
    add_header Set-Cookie "cc_challenge=1; Path=/; Max-Age=3600; HttpOnly";
    return 200 "<script>document.cookie='cc_challenge=1;path=/';location.reload();</script>";
}

这套配置的核心在于：先判断请求是否具备正常浏览器特征，不具备的请求被引导到挑战页面，而不是直接拒绝。挑战页面设置一个Cookie后自动刷新，正常浏览器会带着新Cookie重新请求，从而通过第一级过滤。对于通过挑战但频率异常的IP，limit_req模块会返回429状态码，而不是直接断开连接，这样前端可以捕获429并做友好提示或自动重试。

低影响防护不是配置完就一劳永逸，必须配合实时监控和自动调整。重点监控三个指标：正常用户的验证通过率、429响应比例、后端资源消耗趋势。如果验证通过率低于95%，说明挑战逻辑可能过于严格，需要放宽指纹判断条件。如果429比例超过5%，说明限速阈值偏低，需要提高burst值。

建议在业务低峰期做基线采样，记录正常流量下各接口的请求频率分布、Cookie携带率、Referer合法率等指标。当攻击发生时，对比实时数据与基线的偏离程度，动态调整防护参数。例如，如果攻击流量集中在某个特定URL，可以只对该URL启用更严格的限速，而其他URL保持宽松策略。

另外，日志分析是调试规则的重要依据。建议在Nginx日志中记录每个请求的指纹字段和处置结果，格式如下：

log_format cc_debug '$remote_addr - $request_uri - cookie:$has_cookie - referer:$valid_referer - status:$status - limit:$limit_req_status';
access_log /var/log/nginx/cc_debug.log cc_debug;

通过定期分析这个日志，可以快速定位误杀案例，比如某个正常用户的请求因为Referer字段缺失而被挑战，从而针对性地优化判断逻辑。

如果业务部署在CDN后面，防护策略需要分层设计。边缘节点负责过滤掉大部分无特征的攻击流量，源站只接收经过边缘节点清洗后的请求。但要注意，边缘节点不能完全信任，因为攻击者可能直接攻击源站IP。因此源站自身也必须部署一套轻量级的防护规则，作为最后一道防线。

在边缘节点上，可以启用更激进的挑战策略，因为边缘节点的计算资源相对充裕，且离用户更近，挑战延迟更低。在源站上，则只保留基于IP信誉库和请求指纹的简单过滤，避免消耗源站宝贵的计算资源。两者之间的信任传递可以通过自定义Header实现，比如边缘节点在验证通过后添加一个“X-Edge-Validated: 1”的Header，源站只对缺少该Header的请求做严格检查。

这种协同模式的好处是，即使攻击者绕过了边缘节点，源站也能通过缺失的自定义Header快速识别并拒绝请求，而正常用户从边缘节点转发的请求则畅通无阻。

低影响防护的最终目标不是让攻击流量完全消失，而是让攻击流量对业务的影响降到可接受的范围。通过请求指纹建模、分级处置、业务层令牌校验、动态路径混淆以及边缘与源站协同，可以构建一套既能有效抵御CC攻击、又不伤害正常用户体验的防护体系。关键在于持续监控和动态调整，让规则始终贴合业务的实际流量特征。