CC防护

功能简介

CC 防护用于抵御 CC（Challenge Collapsar）攻击，即短时间内对站点发起大量请求的攻击。

一个网站可以配置多条规则，按优先级自上而下执行，命中即停止（「观察」类规则除外）。同一条规则由四部分组成：

组成	回答的问题
匹配范围	这条规则管哪些请求
统计方式	命中的请求里哪些算一次、算进来的按谁归堆
阈值	多长时间内超过多少次
超过阈值后	超了做什么

CC 防护支持按网站配置；选择「全局网站」时规则对所有站点生效，执行顺序是本站点规则 → 全局站点规则。

CC防护

操作步骤

1. 进入「CC防护」页面。
2. 顶部先选择分组与网站（分组只是筛选，不影响防护）。
   • 网站保持 「全部网站」（默认）时，列表会列出所有站点的规则，并多出一列「网站」标明归属，方便通盘检查；此时「上移 / 下移」只在同一个站点内部生效，不会影响别的站点。
   • 注意区分：「全部网站」是列表的查看范围，只影响你看到什么；而下拉里的 「全局网站」是一个真实的配置对象，配在它上面的规则会对所有站点生效。
3. 点击 新建规则，在弹窗中按四段填写：

① 匹配范围

• 全部请求：这条规则管这个网站的所有请求。
• 按条件匹配：逐条添加条件，条件之间是「并且」。每条条件由「匹配目标 + 判断方式 + 值」构成；选择请求头 / Cookie / 查询参数 / JSON 请求体字段时，还要填字段名（说明取哪一个）。
• 高级条件（脚本）：用脚本表达复杂条件。与「按条件匹配」是同一件事的两种写法，二选一。

判断方式决定右侧填什么：「存在 / 不存在」不需要值；「属于 / 不属于」是多选；「介于」要两个数；其余填一个值。

请求方法、协议、文件扩展名、响应状态码、响应 Content-Type、是否机器人这几类取值是可枚举的，右侧会变成下拉：既能点选常用值，也能直接输入没列出的值。注意文件扩展名带点（.js 而不是 js），响应 Content-Type 的实际取值常带 ; charset=utf-8，所以默认用「前缀匹配」而不是「等于」。

② 统计方式

• 统计口径
  • 排除静态资源（推荐）：js、css、图片等不计数。一次页面加载会带出几十个子请求，把它们算进来会让阈值失真——这是阈值最容易配不准的原因。
  • 全部请求：所有请求都计数。
  • 仅页面文档请求：只统计用户真正翻页的请求。
• 统计维度：决定请求按谁归堆计数。
  • 客户端 IP（默认）
  • IP + URL：同一 IP 对不同接口分开计数
  • Cookie 值 / 请求头值 / 查询参数值：需填字段名，适合按登录用户或业务 uid 限频，可避免大 NAT 出口被整体限住
  • 站点总量：整站共用一个计数

⚠️ Cookie、请求头、查询参数这类取值可被客户端伪造，攻击者每个请求换一个取值即可绕过限频，除非上游有可信代理保证该字段不可篡改。另外，没带该字段的访客会自动回退按 IP 统计，不会被合并成一桶一起限住。

③ 阈值

• 时间窗口（秒）与请求次数：即「N 秒内最多 M 次」。
• 突发容忍：吸收「一次页面加载并发多个子请求」造成的瞬时突发，只在窗口首段生效。

④ 超过阈值后

动作	说明
人机验证（默认）	弹出验证码。误伤成本远低于封 IP。通过后进入「持续时间」长度的免挑战期，同一页面的子请求不会被重复挑战；免挑战期结束后再超过阈值会重新要求验证，因此它是可重复的关卡，不是过一次就一劳永逸
观察	只记录不阻断，并且继续执行后续规则。上线新规则前建议先用它跑一段时间
拦截	拦下本次请求
封禁	在设定时长内挡住该来源。作用范围可选仅本站点（默认）或全部站点

还可以设置「命中后不再执行全局 CC 规则」。

• 已验证爬虫豁免（新建规则默认开启）：开启后，完成完整身份验证的搜索引擎爬虫不计入这条规则的计数。 「观察」动作不受此开关影响——观察本来就不阻断，豁免了反而看不到爬虫的真实流量。

身份验证走的是各家官方文档要求的两步：反查来访 IP 拿到域名、确认域名后缀，再对该域名做正向解析、 确认能解析回原来那个 IP。只有两步都通过才算完成验证。 仅域名后缀对上、正向解析确认不了的， 仍按原来的判定放行（不会被当成伪装爬虫），但拿不到豁免——豁免的把握程度不应超过身份验证的把握程度。

如果某个搜索引擎抓得太猛把站点拖慢了，把这个开关关掉，再加一条「是否机器人 = 是」的匹配条件， 就能只对爬虫限速而不影响真人访客。

4. 点击 确认 保存。规则立即生效，无需重启。

列表里可以用「上移 / 下移」调整优先级，用开关临时停用某条规则。点击 显示CC封禁IP 可查看当前被封禁的来源、作用范围与剩余时间，并可解除。

日志显示触发了人机验证，却没弹出挑战？

先查一处：网站编辑 →「人机验证」→ 永不挑战的路径。列在那里的路径对所有触发来源生效， CC 规则要求的验证同样会被跳过。此时日志的「触发规则」里会带上 命中验证码排除URL，本次未挑战。

这是设计如此：路径被放进那份清单，通常是因为「被挑战就会坏掉」（支付回调、Webhook、 健康检查、纯接口），属于硬约束，不该被单条规则推翻。 要让它被挑战，把它从清单里移除；若本就无意挑战它，改在 CC 规则的「匹配范围」里排除更清楚。

排除这一条之后，再看「触发规则」这一列的文案，两种情况：

日志文案	含义
CC人机验证:规则名[短码]	本次要求访客完成验证，挑战页已经发出
CC人机验证-免挑战期内放行:规则名[短码]	访客刚通过过验证，还在「持续时间」设定的免挑战期内，本次直接放行

第二种是正常行为，不是故障：验证通过后计数窗口并不会立刻清零，如果不给一段缓冲， 访客刚通过验证的下一个请求就会因为仍然超过阈值而被再次挑战，陷入死循环。 免挑战期一过，再超过阈值就会重新要求验证。

想缩短这段放行时间，把该规则的「持续时间」调小即可（它对人机验证动作的含义就是免挑战时长）。

访客反馈被拦了，怎么定位是哪条规则

• 验证码页底部有一串「识别码」，那是本次请求的访问识别码。让访客把它发过来，在「防御日志」按「访问识别码」筛选，就能看到触发的规则、时间、来源 IP 与 URL。
• 规则列表里每条规则名下方有一个短码（形如 CC-7F3A2B）。防御日志的「触发规则」列会带上它，照着短码就能对上是哪条规则。

短码只出现在后台，不会显示给访客。给访客看的一律是每次请求都不同的访问识别码——页面上放随请求稳定的标识，等于让人可以反复试探出自己命中或绕过了哪条规则。

这条规则到底拦到人没有：命中看板

规则列表有一列「触发数」。数字可以点开，里面是这条规则的命中看板：

• 触发总数、按动作分成几档（观察 / 人机验证 / 拦截 / 封禁）各多少次
• 首次触发与最近触发时间
• 触发最多的来源排行，按统计维度归堆。按 IP 统计时这里就是 IP，按 IP+URI 统计时是「IP|路径」，按请求头 / Cookie 统计时是那个字段的取值

它主要回答两个问题：阈值是不是定低了（正常访客大量上榜）， 以及是不是真有人在打（少数来源次数远高于其余）。

有三点要先说清楚，不然容易把数字读错：

1. 只统计「触发」，不统计「匹配」。 一个请求命中了规则的匹配范围只是被计入这条规则的计数， 不算一次触发；超过阈值并执行了动作才算。所以一条规则「触发数 0」不等于它没在工作， 多半正相反——没人越线。
2. 进程内统计，WAF 重启后归零。 看板顶部写着统计起点，读数字前先看一眼那个时间。 需要长期留痕的信息在防御日志里，那才是账本。
3. 来源排行有条数上限。 攻击者换着来源打时，看板只收录最早出现的那一批， 这种情况下会显示一条「不是全部」的提示。总的触发数不受影响，仍然是真实值。

生效优先级

一个请求会依次经过：

1. 站点防护状态关闭 → 什么都不检测
2. 命中 IP / URL 白名单 → 跳过全部检测（含 CC）
3. 自定义规则里的放行并跳过 CC → 跳过整个 CC 检测
4. CC 规则的匹配范围不命中 → 该请求不计数，看下一条规则
5. 命中但未超阈值 → 不动作，看下一条规则
6. 超过阈值 → 执行「超过阈值后」
7. 站点开启了仅记录模式 → 上一步的拦截类动作降级为只记日志

规则表单里「超过阈值后」旁边的 ⓘ 打开的就是这张表，配规则时不必回来翻手册。

两个常见问题：

• 想让某些请求完全不走 CC：可以用自定义规则的「放行并跳过 CC」（跳过整个 CC），也可以把它排除在匹配范围外（只影响这一条规则）。推荐后者，就近可见。
• 站点「仅记录模式」与规则「观察」的区别：前者是站点级总闸，会把所有规则的拦截都降级；后者是单条规则的动作。同时存在时以站点级为准。

紧急模式：被打的时候一键放下闸门

CC 页面右上角有「紧急模式」按钮，对标 Cloudflare 的 Under Attack Mode。

开启后，该站点的所有访客都要先完成一次人机验证，通过后 30 分钟内不再重复挑战。 它不看阈值，也不改动你已有的任何一条 CC 规则——关掉就完全恢复原状， 所以可以在被打的时候直接按下、事后直接关掉，不必担心把配置改乱。

选全局网站开启则对所有站点生效，适合一次被打一片的情况。

按下去之前先确认这一件事

紧急模式与 CC 规则的「人机验证」动作共用同一套闸门，所以站点的 「永不挑战的路径」对它同样生效。

App 与 API 客户端跑不了 JS 挑战。 如果你的站点有移动端或对接方在调接口， 必须先到「网站编辑 - 人机验证 - 永不挑战的路径」把这些接口路径列进去， 否则紧急模式一开，这些客户端会被全部挡在门外。建议平时就配好， 真到要用的时候才不用现想。

自动关闭

开启时可以选 30 分钟 / 1 小时 / 6 小时 / 24 小时，或者「手动关闭前一直开」。

建议选一个到期时间。 紧急模式让全部真实访客都多走一道挑战， 忘了关的代价是由他们承担的。选了「手动关闭前一直开」的话， CC 页面顶部会一直挂着一条红色提示，列出还开着的站点，就是提醒你去关。

两个边界

• 站点的防护总开关关闭时紧急模式不生效——它挂在 CC 检测下面，是第 1 条优先级管的事。
• 自定义规则里的「放行并跳过 CC」同样会跳过紧急模式（第 3 条优先级）。

阈值填多少？让它按你的日志算

规则编辑页「阈值」输入框旁边有一个 📊 按历史流量推荐。它拿这个站点自己的访问日志， 按你当前填的统计周期 / 统计口径 / 统计维度圈样本，算出分布再给建议值。 全部本地计算，不外传任何数据。

面板上有三样东西：

	说明
分布数字	P50 / P95 / P99 / 最大值。一句话读法：「99% 的访客在 60 秒内不超过 42 次请求」
分布图	请求最多的那批客户端按峰值降序排；红色虚线是阈值，可以直接拖，拖到哪里就实时告诉你会打到几个客户端、多少次请求
三档建议	宽松 P99×5 ／ 均衡 P99×3（默认）／ 严格 P99×1.5

应用推荐值会自动切成「观察」

这是故意的，不能关。推荐值再准也只是历史统计，直接上封禁等于拿真实访客试错。 先跑 24 小时，在防御日志里看看都命中了谁，确认没有误伤再改成人机验证或封禁。

什么情况下不给推荐

宁可不给，也不给一个看起来很准的错数——你拿它去配封禁，错了是真实访客被挡在外面。

情况	面板会说
新站点 / 样本太少	不给推荐值，改给业界参考值并标注来源
统计维度是 Cookie / 请求头 / 查询参数	不给推荐：日志里没有可靠还原这些维度的字段。可先按 IP 估个量级
统计口径是「仅页面文档」	不给推荐：该口径靠请求头 Sec-Fetch-Dest 判定，日志里还原不可靠。可切「排除静态资源」
规则还带着 UA / 地域等条件	给推荐值，但标注「样本没有按这些条件收窄，实际命中会少于估算」
日志量特别大	给推荐值，但标注已自动缩短天数

推荐永远只是「填进输入框」，保存与否由你决定。

CC 按哪个 IP 计数

来自两处站点级设置，配在「网站编辑 → 其他配置」：

设置	作用
真实IP来源	决定怎么从 X-Forwarded-For 等头里解析出访客真实 IP
IP提取模式	决定 CC 用哪个：网卡模式=连接过来的 IP；代理模式=上一步解析出的真实 IP

CC 计数、封禁匹配、人机验证标记三处口径一致，都按被访问站点的这两项设置取。 挂在「全局网站」上的 CC 规则同样按被访问站点取——IP提取模式描述的是「该站点部署在什么后面」， 是部署事实；全局网站不承载流量，它自己那一项取不到实际意义。

站点在 CDN / Nginx 后面就必须选代理模式。否则 CC 看到的是回源节点的 IP， 所有访客会被并成少数几个 IP 一起计数，轻则误伤，重则一次封禁打掉整个回源节点。

字段说明

字段	说明
网站	规则所属站点，选择全局网站时对所有站点生效
规则名	便于识别，会出现在攻击日志里
规则短码	系统自动分配、不可修改，形如 CC-7F3A2B；攻击日志的「触发规则」里会带上它，用来对应是哪条规则
优先级	数字越小越先执行
匹配方式	全部请求 / 按条件匹配 / 高级条件（脚本）
统计口径	哪些请求算一次
统计维度	算进来的请求按谁归堆
时间窗口	统计的时间长度（秒）
请求次数	窗口内允许的最大次数
突发容忍	额外容忍的瞬时突发次数
超过阈值后	观察 / 人机验证 / 拦截 / 封禁
持续时间	动作生效时长（秒）。人机验证=通过后的免挑战时长；封禁=封禁时长
封禁作用范围	仅本站点 / 全部站点
已验证爬虫豁免	开启后完成完整身份验证的搜索引擎爬虫不计入本条规则；「观察」动作不受影响
启用规则	关闭后该规则不参与判定

支付回调、第三方 Webhook 被拦了怎么办

这类流量不属于爬虫——它们的 User-Agent 是 okhttp、Java/1.8、Go-http-client 之类， 不带任何爬虫特征，所以「已验证爬虫豁免」对它们不起作用。它们只能由你显式放行。

三种做法，影响面从小到大：

做法	影响范围	适用场景
在 CC 规则的匹配范围里排除该路径（推荐）	只影响这一条规则	大多数情况。就近可见，配置时一眼能看出哪些请求被排除了
自定义规则「放行并跳过 CC」	跳过整个 CC 检测	该来源要同时避开多条 CC 规则时
IP 白名单	跳过全部检测（含注入、XSS 等）	仅在服务商 IP 段稳定且完全可信时使用

推荐第一种：比如给「全站兜底」那条规则加一个条件「URL 路径 不属于 /pay/notify、/sms/callback」， 其余请求照常受保护。

允许清单建议当台账管理：每条记录写清用途、服务商公布 IP 段的来源地址、以及下次复核的时间。 服务商换网段是常事，一份长年不复核的清单既可能挡住正常回调，也可能一直放行早已不属于对方的地址。

从旧版本升级

旧版本每个网站只能配一条 CC 配置。升级后它会被自动转换成一条等价规则，名称为「默认CC防护」，并带「兼容旧配置」标记：

• 统计口径保持 全部请求（不是排除静态）
• 封禁作用范围保持 全部站点
• 限流算法沿用原来的设置

升级不改变你现有的防护行为。 更合理的新默认值（排除静态资源、人机验证、仅本站点）只作用于之后新建的规则。

建议升级后打开看一眼转换结果，把统计口径改成「排除静态资源」、封禁作用范围改成「仅本站点」——阈值会更贴合真实情况，也不会因为一个站点触发而影响同实例的其它站点。

如果你之前用的是「平均速率模式」：本版本修正了一处缺陷——此前在界面点一次保存，实际生效的阈值会与启动时不同，重启后又变回去。修正后保存前后、重启前后一致，因此你可能会观察到实际拦截强度与之前不同，这是把阈值恢复成你配置的值。

新建网站的默认规则

新建网站时会自动生成两条开箱可用的规则：

规则	范围	阈值	动作
动态接口频次	全部请求（排除静态资源）	60 秒 / 600 次	人机验证 5 分钟
全站兜底	全部请求	60 秒 / 3000 次	封禁本站点 10 分钟

可以按自己的业务量调整或删除。单个网站最多 20 条规则。