百度云防护自定义CC支持更多特征同时统计：配置教程与实战案例

一、为什么”更多特征同时统计”是一次重要升级

要理解这次升级的价值，得先看传统 CC 防护的痛点。

1.1 传统 CC 防护的困境

传统 CC 防护的核心逻辑是按 IP 统计请求频率：某个 IP 在 N 秒内请求超过 M 次，就判定为攻击并拦截。

这个逻辑在早期很有效，因为当时的攻击者工具简单、IP 有限。但现在的 CC 攻击已经进化了：

攻击演进	特征	传统 IP 频率防护的效果
早期 CC	单 IP 高频请求	有效，直接拦
代理池 CC	成千上万 IP，每个 IP 只请求几次	失效，每个 IP 都不超阈值
分布式真人 IP	IP 分散且真实，频次低	几乎失效
指纹伪造 CC	UA 轮换、IP 轮换，但工具指纹不变	失效，需要看 JA3/JA4
精准打击 CC	只打某个接口（如登录、搜索）	失效，需要按 URI 统计

问题出在哪？不是频率阈值设得不对，而是”统计维度选错了”。

CC 防护的本质是”在正确的维度上做频率统计”。维度选错，阈值再调也没用——攻击者只要把流量摊薄到多个维度上，单一维度的统计就永远不超标。

1.2 升级解决了什么

这次升级带来两个关键能力：

• 特征种类扩展：统计维度从原来的有限几项，扩展到 11 种（IP、JA3、JA4、User-Agent、URI PATH、国家、省份、自定义 header-key、自定义 query-key、自定义 cookie-key 等）。
• 多特征组合统计（最多 5 个）：可以在一条规则里用”且”关系叠加多个特征，一个特征不达标就不触发，只有全部特征都命中且累计超阈值才处置。

用一个比喻说明差异：

二、11 种统计特征详解与适用场景

这是本次升级的核心。每种特征都是一把”筛子”，选对了才能把攻击流量筛出来。下面逐个说明。

特征	统计对象	最适合的场景	推荐度
IP	客户端来源 IP	通用基础维度，单点高频攻击	必备
JA3	TLS 握手指纹	识别换 IP 换 UA 但工具不变的攻击	强烈推荐
JA4	新一代 TLS 指纹（含更多维度）	JA3 被伪造时的进阶识别	强烈推荐
User-Agent	HTTP 请求头 UA	UA 固定的采集器、脚本工具	常用
URI PATH	请求的具体路径	精准打击某接口（登录/搜索/下单）	强烈推荐
国家	IP 归属国家	业务不出海，境外流量集中攻击	场景化
省份	IP 归属省份	业务有明确地域范围（本地服务）	场景化
自定义 header-key	指定请求头的值	有 API 网关、App 专属头、鉴权头的站	进阶
自定义 query-key	URL 指定参数的值	带特征参数的接口（如 device_id、token）	进阶
自定义 cookie-key	指定 Cookie 的值	带会话标识、设备标识的业务	进阶

2.1 IP：基础但仍不可少

IP 是最基础的统计维度，但在组合统计里它的角色变了——不再是唯一依据，而是”限定条件之一”。

典型用法：和 JA3 组合，把”某 IP 高频”升级为”某 IP 且同工具指纹高频”，误报率显著下降。

2.2 JA3 / JA4：识别”换了马甲的同一个人”

这是本次升级最有价值的能力。原理很简单：

攻击者可以换 IP（代理池）、可以换 UA（随机生成），但他所用的攻击工具（Python 脚本、扫描器、压测工具）在 TLS 握手中的特征参数是相对固定的。这个特征就是 JA3/JA4 指纹。

类比一下：一个人可以换衣服、换发型、换手机号，但走路的步态特征很难变。JA3/JA4 就是网络世界的”步态识别”。

所以当你看到日志里几千个 IP、UA 各不相同，但它们JA3 指纹高度集中——基本可以确定是同一次 CC 攻击。

JA3 与 JA4 的区别：

• JA3：基于 TLS Client Hello 的五个字段计算，应用广泛，但部分攻击工具已能伪造。
• JA4：下一代指纹方案，纳入更多维度和规范化处理，对伪装型工具的识别能力更强。

实战建议：先用 JA3 观察一两天，看命中情况；如果发现攻击者能绕过 JA3，再叠加 JA4 一起统计。

2.3 URI PATH：对付”专打某个接口”的精准 CC

很多 CC 攻击不是漫无目的地刷全站，而是盯着最耗资源的那个接口打：

• 电商：秒杀接口、下单接口、库存查询接口
• CMS：搜索接口（未缓存时最耗数据库）
• SaaS：登录接口、短信发送接口、导出接口

这种情况下，全站维度的频率统计会被大量正常请求稀释，阈值必须设得很高才不误伤——结果就是攻击也拦不住。

用 URI PATH 做统计维度，就变成了”单接口级别的频率控制”，可以设得很严格，且不影响其他页面。

2.4 国家 / 省份：地理维度的精准限定

适用于业务有明显地域属性的场景：

• 纯国内业务：境外流量占比极低，突然出现大量境外请求基本是攻击。
• 本地化服务：只服务某省或某市的业务，可用省份维度把异常来源筛出来。
• 数据合规要求：某些业务要求限制访问来源地域。

注意：这类特征建议作为组合条件而非单独条件，避免直接封禁整个国家/省份造成误伤（尤其是有海外用户的业务）。

2.5 自定义 header / query / cookie：最灵活的进阶武器

这三个特征是给”有技术能力的站长”准备的，价值在于可以把业务自身的标识纳入统计。

特征	可统计内容	典型用法
自定义 header-key	任意指定请求头的值	App 专属头（如 X-Device-ID）频率统计；API 网关的 X-API-Key
自定义 query-key	URL 中指定参数的值	统计 device_id、channel、token 等参数的出现频率
自定义 cookie-key	指定 Cookie 的值	统计会话 ID、设备指纹 Cookie 的频率

举个实际例子：如果你的 App 请求都带 X-Device-ID 头，那就可以统计”同一 Device-ID 的请求频率”。因为设备 ID 比 IP 稳定得多，这个维度的识别精度很高。

三、完整配置步骤

下面按界面实际操作顺序，一步步说明如何配置一条自定义 CC 规则。

步骤 1：进入规则配置

在百度云防护控制台进入 防护配置 → CC 防护 → 添加规则（智能 CC 与精准自定义 CC 在同一入口）。

步骤 2：选择防护类型

防护类型	说明	适用情况
智能 CC	系统自动识别并处置，无需人工配规则	刚接入、无运维精力、常规防护
精准自定义 CC	手动指定匹配条件 + 统计特征 + 频率阈值	有明确攻击特征、需要精细控制

本次要讲的是精准自定义 CC——点击选中后，下方会出现”执行并命中匹配条件后，启动频率设置校验”的提示，表示规则会先做条件匹配，再进入频率统计。

步骤 3：配置优先级

取值范围 0-200，数值越小优先级越高。同一请求命中多个防护场景时，以优先级高的场景为准。

建议规划：

• 0-50：紧急拦截类规则（正在被攻击的接口）
• 51-120：常规业务规则（登录、搜索等重点接口）
• 121-200：兜底宽松规则

步骤 4：配置匹配条件（决定”对谁生效”）

匹配条件决定这条规则作用在哪些请求上，最多可添加 5 个（用”且”关系组合）。

可选字段包括 IP、URI、UA、Header 等。填写要点：

• IP 支持单 IP 或 CIDR 网段格式，例如 1.1.1.1/24
• 暂不支持正则表达式，只能填精确值
• 最多填写 200 个值，用英文逗号分隔，或按回车键逐条确认

设计建议：匹配条件宜窄不宜宽。先框定要保护的范围（比如只保护 /api/login），再用统计特征做频率判断。如果匹配条件写成”全站”，等于放弃了精准性。

步骤 5：配置统计信息（核心步骤）

这是本次升级的重点区域，包含三部分：

① 统计特征选择（最多 5 个，用”且”组合）

点击”+ 添加『且』特征“可继续增加维度，当前显示 (2/5) 表示已用 2 个、上限 5 个。每个特征右侧可填一个值用于进一步限定（0/32 表示最多 32 字符）。

② 时间窗口

请求在 [10-1800] 秒内——即统计的时间范围，支持 10 秒到 30 分钟。填入 10-1800 之间的整数。

③ 频率阈值

秒超过 [2-50000] 次，触发处置动作——即在该时间窗口内请求数超过多少次时触发。支持 2 到 50000 的整数。

参数配置速查表：

参数	取值范围	配置建议
优先级	0-200	数值越小越优先，紧急规则填 0-50
匹配条件数量	最多 5 个	宜窄不宜宽，先框定保护范围
IP/值填写数量	最多 200 个	英文逗号分隔，不支持正则
统计特征数量	最多 5 个	组合维度越多越精准，但需权衡复杂度
时间窗口	10-1800 秒	按”正常峰值 × 2″原则估算
频率阈值	2-50000 次	参考日志中正常用户的实际请求量
处置时长	60-3600 秒	首次建议 300 秒，确认后再延长

步骤 6：配置生效范围

选项	含义	何时使用
仅作用于当前规则的匹配条件	只对第 4 步匹配到的请求生效	精准防护，推荐默认选择
作用于整个防护站点	规则影响全站请求	全站性攻击、兜底策略

步骤 7：选择生效模式

• 永久生效：规则持续生效，适合长期存在的攻击特征。
• 按时间段生效：只在指定时间段生效，例如只在活动期间开启。
• 按周期生效：按周期性规律生效，适合有固定高峰的业务。

步骤 8：选择处置动作

处置动作	效果	适用强度
JS 挑战	对命中规则的访问发起 JavaScript 挑战，合法浏览器可自动执行并通过验证，无法执行 JS 的异常请求将被拦截	推荐首选，误伤最小
观察模式	仅记录不拦截，用于验证规则准确性	新规则上线第一步
拦截 / 封禁	直接阻断请求或封禁来源	确认无误报后使用

处置时长：填 60-3600 秒。建议首次设置短一些（如 300 秒），便于观察效果，确认无误报后再延长。

为什么要先选 JS 挑战？因为它是”自适应”的：真实浏览器的用户感知几乎为零（挑战自动通过），而脚本工具因为没有 JS 执行环境会被拦住。这比直接封 IP 的误伤率低得多。

步骤 9：配置防护站点并保存

最后在”防护站点配置”中选择规则作用的站点（可搜索站点名称快速定位），可跨站点配置——如果多个站点有相同的攻击特征，一条规则就能覆盖。

确认配置后保存。建议先选观察模式运行 1-3 天，核对命中日志确认无误报后再切换为正式处置动作。

四、三个实战案例

案例一：代理池 CC 攻击登录接口

背景：某电商网站 /api/login 接口持续被打，用户反馈登录变慢、部分时段超时。

排查发现：

• 攻击源 IP 超过 8000 个，分散在全国各地
• 每个 IP 请求频率都很低（10 秒内 3-5 次），远低于常规阈值
• 但 User-Agent 高度集中——90% 以上是几个固定的 UA 字符串
• JA3 指纹只集中在 2 个值上

攻击者手法：典型的代理池 + 固定工具组合。IP 是租来的，但用的还是那套脚本，UA 和 TLS 指纹没变。

规则配置：

配置解读：这里的关键是把统计维度从 IP 换成”JA3 + UA”组合。攻击者虽然有 8000 个 IP，但 JA3 只有 2 个、UA 只有几个——按这个维度统计，每个组合的请求量立刻超标，直接命中。

效果：接入 JS 挑战后，正常用户浏览器自动通过验证、无感知；脚本因为无法执行 JS 被拦截。10 分钟后登录接口恢复正常。

案例二：精准打接口的 CC 攻击（CMS 搜索页）

背景：某资讯站用的是 WordPress，站内搜索页面 /?s=关键词 响应极慢。搜索功能未做缓存，每次请求都会穿透到数据库做全表 LIKE 查询。

排查发现：

• 搜索接口 QPS 从平稳的 20 涨到 600+
• 攻击请求的关键词都是无意义的随机字符
• 来源 IP 分散，单 IP 频率不高
• 但请求全部集中在这一个 URI

难点：如果按全站维度做频率统计，阈值必须设很高（因为正常页面浏览量很大），结果就是搜索接口的攻击拦不住。

规则配置：

配置解读：

• 用匹配条件把规则作用域缩到搜索接口，不影响其他页面
• 用 URI PATH 作为统计特征，实现”单接口级别的频率控制”
• 因为只统计搜索接口，阈值可以设得很低（20 次），拦截力度强且不误伤

效果：搜索接口 QPS 从 600 回落到 30 以内，数据库负载恢复正常。同时正常的搜索用户（60 秒内搜 20 次以内）完全不受影响。

案例三：境外集中攻击 + 定制化业务标识

背景：某纯国内业务的 SaaS 系统（用户全部在中国大陆），夜间持续遭到异常请求，产生大量无效短信验证码费用。

排查发现：

• 攻击流量 95% 来自境外 IP
• 目标集中在 /api/sms/send 短信发送接口
• 请求都缺少 App 正常请求携带的 X-Device-ID 头

规则配置：

配置解读：

• 国家维度：快速把境外来源筛出来——因为业务 100% 在国内，境外请求本身就是强异常信号
• 自定义 header-key：正常 App 请求必带 X-Device-ID，脚本请求通常没有。即使攻击者伪造了这个头，因为是真机才有的稳定值，仍可结合频率统计拦截
• 按时间段生效：攻击集中在夜间，配置夜间生效，白天自动关闭，把对业务的影响降到最低
• 慢速阈值配长窗口：300 秒 / 10 次是宽松阈值组合，专门对付”慢速低频”的分布式攻击——单 IP 慢慢刷，靠时间累积暴露

效果：无效短信费用从日均数百元降至接近 0，且因为用了 JS 挑战，App 正常用户的请求（可执行 JS）全部正常通过。

五、配置避坑指南

结合实战经验，以下五个坑最容易踩：

坑	后果	正确做法
新规则直接上拦截	误伤正常用户，业务受损	先”观察模式”跑 1-3 天，核对命中日志
匹配条件写全站	失去精准性，阈值被迫放宽	先框定具体接口，再做频率统计
只用 IP 单维度	遇到代理池 CC 直接失效	叠加 JA3/JA4 或 UA 组成多特征
阈值照搬他人配置	要么误伤要么漏拦	先查日志统计正常用户峰值，按”峰值 × 2″设定
处置时长设得过长	误判导致用户被长时间阻断	首次 300 秒，确认无误报后再延长

最重要的一条：留好观测期。自定义 CC 的威力来自精准，而精准的前提是”你了解自己的正常流量长什么样”。上规则前先看几天日志，比任何参数建议都管用。

六、常见问题

Q1：统计特征最多能配几个？是不是越多越好？

最多 5 个。但不是越多越好——特征越多，”同时满足”的门槛越高，可能漏掉部分攻击流量。建议从 2 个特征（通常是 IP + JA3 或 IP + URI）起步，观察效果后再决定是否增加。

Q2：匹配条件的值支持正则吗？

不支持。只能填精确值或 IP/CIDR 网段（如 1.1.1.1/24），最多 200 个，用英文逗号分隔或回车逐条确认。如果需要模糊匹配，建议改用 URI 前缀或调整匹配字段。

Q3：JS 挑战会影响 SEO 吗？

不会，前提是把搜索引擎爬虫加白名单。这也是 WAF 配置的基本要求——百度、搜狗等正规爬虫必须在白名单里，否则会影响收录。

Q4：规则配错了怎么办？

及时删除或调整规则即可。但如果已经造成误伤，优先排查：① 匹配条件是否过宽；② 阈值是否过低；③ 是否选错了统计特征。建议保留配置备份，便于回滚。

Q5：智能 CC 和精准自定义 CC 能同时用吗？

可以，二者是互补关系。智能 CC 做兜底（自动识别常规攻击），精准自定义 CC 做专项（针对特定接口和特征）。同一请求命中多个场景时，按优先级数值小的规则为准。

七、小结

这次自定义 CC 升级的核心价值，可以用一句话概括：

把 CC 防护从”单一 IP 频率”升级为”多维度组合统计”，让防护跟得上攻击的演进。

三个关键点：

• 11 种统计特征覆盖了 IP、TLS 指纹、HTTP 特征、地理维度、业务自定义标识五个层面，能应对代理池、指纹伪造、精准打接口等主流 CC 手法。
• 最多 5 个特征组合（且关系）是精准性的来源。IP 单独统计会失效，但”IP + JA3″组合能立刻锁定换 IP 的攻击者。
• 配置的关键在于顺序：先框定匹配范围（保护谁）→ 再选统计特征（按什么维度算）→ 最后定阈值和处置（怎么拦）。顺序对了，配置就成功了一半。

如果你的站点正被 CC 攻击困扰，尤其是遇到”IP 分散、频率不高”的分布式攻击，建议优先尝试 JA3/JA4 + IP 的组合统计——这是目前应对代理池 CC 最有效的手段之一。

---

如果你的站点正被恶意爬虫、CC 攻击困扰，或需要一套开箱即用的 Web 应用防护，可以了解百度云防护 Web 应用防火墙（专业版 299 元/月，年付 2399 元，可联系主机吧客服购买）——支持自定义访问策略、URI 频率限制、BOT 防护、威胁情报与 API 防护，无需改动源站代码，改 DNS 即可接入。包年包月计费，流量峰值买多少防多少，无后付费陷阱。