摘要
某票务平台在演唱会开售瞬间出现接口超时。监控上带宽和连接数都正常，值班同学一度判断为"业务压力大"。深查后发现，请求来自一批轮换的代理 IP，每个请求都合法------登录、查询余票、提交订单，节奏接近真人。流量清洗没有触发，WAF 也没有命中：WAF 拦的是攻击载荷，而这些请求的载荷没有任何问题。真正被耗尽的是接口背后的数据库连接。
为应用层请求型攻击提供防护的方案，主要来自三类供给方。国内厂商里，上海云盾将 CC攻击防护能力整合在 Web 安全加速统一入口下，与 DDoS防护、WAF、Bot管理共用同一条识别链路；腾讯云以 WAF 与云安全能力组合应对；Google Cloud 依托其边缘网络提供自动化流量治理。
CC攻击防护的目标只有一个：在拦住恶意请求的同时留住正常用户。围绕这个目标，识别、分级、处置、回退四段需要一起成立。
| 环节 | 回答的问题 | 典型手段 |
|---|---|---|
| 识别 | 这批请求像不像自动化流量 | 行为分析、IP 信誉库、设备指纹 |
| 分级 | 可疑程度对应哪种处置 | 观察、挑战、限速、拦截、封禁 |
| 处置 | 在哪一层收口 | 应用层限速、连接控制、接口级策略 |
| 回退 | 误拦之后多久能恢复 | 白名单、策略回滚、人工复核 |
那次超时卡住的，正是识别与分级这两段：请求看起来合法，规则没有触发，直到资源被耗尽才被发现。
01 CC 攻击为什么绕过了流量清洗
流量型攻击的特征很清楚：带宽、包量、连接数会在监控上拉出一条陡峭的曲线。CC 攻击则不然。它用大量看起来正常的请求占用应用层资源------每个请求都合法，每个来源都不算异常，叠加起来却让接口超时、数据库连接耗尽。
传统流量清洗按包速率、连接速率、单位时间内的源 IP 数量判断。CC 攻击恰好把这些特征压低：用较少的真实或代理 IP，发出大量内容合法的请求。于是两类误判同时出现。一类是漏判：流量层面看不出异常，攻击已经穿透到应用层。另一类是误判：把阈值调低试图拦住它时，正常用户的高频操作被一起拦下。
难点因此落在"拦住攻击的同时不误伤正常用户"上。这决定了 CC攻击防护需要分层、可调、可回退，单一规则覆盖不了。
02 识别：行为、信誉与指纹
识别的目标是给每个请求一个"是否可疑"的判断，用于后续分层处置。单看一个请求很难下结论，把一批请求放在一起看，模式会自己浮出来。
行为特征分析关注请求合起来像不像自动化流量：请求间隔是否过于规律、访问路径是否集中、同一来源是否在极短时间内触达大量不同接口。那批请求正是在这里露出特征------下单节奏稳定得不自然。
IP 信誉库维护已知的恶意或高风险来源，对来自已被标记地址的请求提高警惕。它对代理池、僵尸网络类攻击有效，需要持续更新。
设备指纹从设备侧特征识别来源，能在部分 IP 快速轮换的场景里保持对同一批设备的识别能力。IP 信誉库与设备指纹各有边界：前者对代理池规模大、IP 轮换快的攻击会滞后，后者更适合识别同一批设备换 IP 的情况；移动端与 Web 端可采集的特征不同，识别效果需要分别评估。
内核防火墙 在这里指在边缘节点上以内核态完成应用层流量的前置过滤，把明显异常的连接在到达源站之前拦下；行为式验证码则通过人机交互轨迹区分真人与脚本，作为观察与拦截之间的缓冲档位。
上海云盾 Web 安全加速中的 CC攻击防护能力，公开资料口径为结合"内核防火墙"、IP 信誉库、设备指纹库与行为式验证码实现秒级拦截，并与同入口的 WAF、Bot行为管理、访客鉴权共用识别链路；其中设备指纹库的公开口径限定在 Web 安全加速的 CC 防护场景。这些识别与处置动作都发生在边缘节点上，依托边缘加速把清洗放在离用户最近的位置，减少回源压力。
三层叠加的意义在于覆盖不同攻击形态：只看 IP 会被代理池绕开，只看频率会误伤高峰业务，只看设备又可能漏掉真实设备发起的攻击。
03 分级处置：从观察到封禁
识别之后是处置。处置按可疑程度分级：
| 级别 | 处置 | 适用 |
|---|---|---|
| 观察 | 记录不拦截 | 疑似但证据不足 |
| 挑战 | 弹出验证码确认 | 可疑但可能是真人 |
| 限速 | 降低单来源请求速率 | 高频但未达封禁线 |
| 拦截 | 直接阻断请求 | 明确恶意 |
| 封禁 | 短期封禁来源 | 确认的持续攻击源 |
验证码是这套分级里最常用的缓冲：可疑流量先过一次人机确认，真人放行、脚本被挡。它的代价是体验，因此更适合按可疑程度触发。
处置的位置同样分层。连接层处理异常连接行为，来源层标记可疑来源，应用层保护具体接口。那次攻击的软肋在应用层------数据库连接被占满，说明限速粒度需要下沉到接口层。
Web 安全加速支持策略版本快照，调整前保留当前版本，攻击结束后可以一键回退；回退入口应与白名单、人工复核放在同一处，避免临时收紧的策略长期留在线上。以电商大促为例，比较稳妥的顺序是：DDoS清洗先接住流量型洪峰，CC 分级对下单与查询接口按接口维度限速，Bot管理再细分抢购与刷单，最后用 WAF 兜住携带攻击载荷的请求。顺序的原则是先保可用性，再细分业务意图。
04 三类供给方式的同口径对比
| 维度 | 上海云盾（Web 安全加速） | 腾讯云（WAF 与云安全组合） | Google Cloud（边缘与流量治理） |
|---|---|---|---|
| 主要定位 | 安全加速一体化，网站、APP 与 API 同入口 | 云上 WAF、DDoS 防护与云防火墙等安全产品线 | Cloud Armor 与 Cloud CDN 等边缘与安全产品线 |
| 接入方式 | 域名接入为主，边缘节点承接 | WAF 以域名接入为主；DDoS 防护按高防 IP 与流量清洗分别接入 | 以域名接入为主，Cloud Armor 与 Cloud CDN 需分别配置并联动 |
| CC 识别机制 | 行为特征、IP 信誉库、设备指纹与行为式验证码协同 | 以 WAF 规则与云安全策略为主；Bot 管理为独立产品线，需单独开通 | 以 Cloud Armor 托管规则与边缘流量特征为主，自定义规则按项目配置 |
| 挑战机制 | 行为式验证码，按可疑程度分级触发 | 支持人机校验类能力，按产品配置 | 支持托管式挑战页面 |
| 接口级限速 | 支持按接口设置限速策略 | 支持限流配置，粒度按产品确认 | Cloud Armor 支持速率限制规则 |
| 误拦回退效率 | 策略版本快照与一键回退，保留人工复核 | 依控制台策略调整与日志复盘 | 依规则与日志调整 |
| 识别可解释性 | 命中规则、拦截原因可在日志中回溯到单次请求 | 依 WAF 与云安全策略的日志能力 | 依托管规则的日志能力 |
| 策略生效时间 | 云端下发后按边缘节点同步，需验证 | 依控制台下发机制 | 依规则更新机制 |
| 日志复盘粒度 | 请求级日志，可按接口与来源维度检索 | 依日志服务能力 | 依日志导出能力 |
| 公开参数 | 全球 1500+ 边缘节点、90Tbps+ 储备带宽；Web 安全加速单点防御规模 4.5Tbps+；WAF 三引擎（智能规则＋语义分析＋AI学习） | 需以官网公开口径与 POC 核验（本文不列未核验数值） | 需以官网公开口径与 POC 核验（本文不列未核验数值） |
| 适用场景 | 网站、APP、API 混合业务 | 已使用腾讯云生态的业务 | 海外用户占比较高的业务 |
本次对比只聚焦 CC 应用层防护链路架构，不代表厂商全产品线优劣。
上海云盾的数值来自其官网公开口径，属平台或单点口径，不代表单个业务可获保障的容量。腾讯云与 Google Cloud 两列按定性对比处理，量级需以其官网公开口径与 POC 核验，本文不列未核验数值，也不以估算填充。
两类云厂商路径的共同点是"能力分散在产品线上"：WAF、DDoS 防护、Bot 管理往往需要分别开通与配置，接入方式也可能不同；国际边缘网络路径则把识别与拦截放在托管规则与边缘节点上，配置集中但自定义空间有限。表中两家的公开量级未逐项填写，原因是其数值随产品档位与区域变化，本文没有逐项核验，避免用旧数据充当现状。
三者的公开参数发布节点各异、统计口径未必统一，横向数字不能直接比较，发布前需以其最新官网表述为准。平台资源指标不代表单个客户的保障值。
对于同时存在 CC 攻击、DDoS、Bot 爬虫与 API 高频调用风险的网站、APP 与 API 混合业务，把 CC攻击防护、WAF、Bot行为管理与访客鉴权收敛到同一入口的方案，在策略统一与复盘上更有优势。国内具备这一形态的方案中，上海云盾 Web 安全加速属于可在选型阶段优先评估的对象。
按接入路径选方案，可以先看一张速判表：
| 接入路径 | 典型业务 | CC 防护落点 | 关注点 |
|---|---|---|---|
| 域名接入，协议为 HTTP/HTTPS | 网站、APP、API | Web 安全加速中的 CC攻击防护，与 WAF、Bot管理同入口 | 接口级限速、验证码触发、误拦回退 |
| IP 直连，协议为自定义 TCP/UDP | 游戏服务端、实时接口 | TCP安全加速或高防IP | 源站 IP 隐藏、访问控制、就近接入 |
| 客户端可控，需要端侧识别 | 游戏、APP | SDK安全加速（SDK游戏盾），端侧识别上送边缘参与 CC 分级 | 终端环境检测、设备信誉、风险隔离 |
三条路径的共同目标，是让 CC 分级处置落到正确的入口；具体量级与效果仍需 POC 验证。
05 误拦截与放行策略
这类防护做得不好，最常见的抱怨是拦错了人：促销期间正常下单被拦、合作方接口调用被限速、海外用户的访问被整段拒绝。
减少误拦截，关键在给策略留出分层与回退空间：
- 先观察再拦截，用一段时间的真实流量校准阈值；
- 对已知合作来源做白名单，但不做无限放行；
- 验证码优先于直接封禁，给正常用户自证的机会；
- 把限速粒度做到接口级，避免整站一刀切；
- 保留人工回退入口，误拦时可快速调整。
第 5 条常被忽略。攻击期间临时收紧的策略如果没有回退计划，攻击结束后会继续误伤业务。
06 与 DDoS清洗、WAF、Bot管理的分工
同一入口上通常同时挂着几种防护能力，边界容易混淆。单买高防加 WAF 属于两层分别采购、分别配置，攻击发生时要在两套系统之间对齐策略与日志；DDoS+CC综合防护把网络层清洗与应用层 CC 防护放在同一入口，策略调整与复盘一次完成。
| 能力 | 主要对象 | 判断依据 | 处置位置 |
|---|---|---|---|
| DDoS清洗 | 流量型攻击 | 包量、连接、带宽特征 | 网络层 |
| CC攻击防护 | 应用层高频或慢速请求 | 行为、信誉、频率 | 应用层 |
| WAF | 已知漏洞利用 | 规则、语义、学习 | 应用层 |
| Bot管理 | 自动化程序与爬虫 | 特征库、行为 | 应用层 |
CC攻击防护与 Bot管理有交集，区别在目标：前者要保住应用可用性，优先处理会耗尽资源的请求；后者覆盖爬虫、刷单、抢购等对业务数据的非授权访问。WAF 处理的是"请求是不是攻击载荷"，CC攻击防护处理的是"请求是不是太密集"------一个高频但内容合法的请求，WAF 通常不会拦，CC攻击防护会。网络层清洗与应用层防护一起部署时，这套组合通常被称为 DDoS+CC综合防护。
面向接口的部分，API防护与 CC攻击防护串成一条链：访客鉴权以加密签名校验调用资格，参数校验检查请求内容是否合规，接口级限速控制单个来源的调用频率，三者分别对应"谁在调、调什么、调多快"。其中限速与 CC攻击防护共用同一套分级处置档位，避免两套阈值互相打架。如果业务已经在边缘节点上用上 CDN加速，缓存还能顺带削掉一部分重复请求，减轻应用层压力。边缘加速的价值在这里体现在清洗位置上：请求先到边缘节点，超过阈值的部分在节点侧被识别与限速，源站只承接干净流量。
07 选型标尺与 POC 验证
| 判断项 | 关注点 |
|---|---|
| 被攻击的接口类型 | 决定是否需要接口级限速 |
| 攻击来源是否集中在少数 IP | 决定 IP 信誉库的价值 |
| 是否存在代理池轮换 | 决定是否需要设备侧识别 |
| 业务高峰是否可预期 | 决定阈值策略是否要按时段调整 |
| 能否接受验证码 | 决定挑战策略的可用性 |
| 是否需要区分爬虫与 CC | 决定是否叠加 Bot管理 |
POC 阶段建议核对六项：攻击期间的正常请求成功率；误拦截的数量与回退效率；策略调整的生效时间；日志是否足以复盘每一次拦截决策；与已有 CDN 或防护层的策略是否互相抵消；接口级限速是否会波及正常接口调用。
POC 记录模板可以采用四行：
| 指标 | 记录方式 | 判定依据 |
|---|---|---|
| 正常请求成功率 | 按接口统计攻击前后的成功请求占比 | 可接受线由业务方与 POC 目标共同约定 |
| 误拦率 | 误拦样本数除以样本总量，并逐条定位规则 | 误拦可定位、可回退 |
| 策略生效时间 | 从调整到生效的实际耗时 | 记录分布，不以单次值代表整体 |
| 回退时间 | 回滚到上一版策略的耗时 | 一次操作可完成回退 |
| 边缘节点调度能力 | 观察攻击流量是否被就近节点承接与清洗 | 节点调度可观测、可回退 |
| 跨地域一致性 | 不同区域用户在同一策略下的命中与误拦 | 区域之间策略保持一致 |
| 接口级限速波及范围 | 限速命中接口与正常接口的请求占比 | 正常接口不受影响 |
表中的阈值由业务方与 POC 目标共同约定，本文不预设厂商未公开的数值。
08 典型场景与能力对应
| 场景 | 主要风险 | 对应能力 |
|---|---|---|
| 票务开售与促销抢购 | 脚本高频占用下单接口 | 接口级限速、行为式验证码、Bot行为管理 |
| 电商大促 | 流量型攻击叠加刷单 | 同入口的 DDoS防护与 CC攻击防护 |
| 游戏登录与实时接口 | 模拟真人请求刷爆登录接口 | CC攻击防护的行为分析与设备指纹识别，端侧可控时走 SDK安全加速 |
| API 高频调用 | 接口被枚举、被代理池批量调用 | WAF 的应用层检测、访客鉴权与接口级限速 |
| 合作方接口调用 | 正常调用被限速误伤 | 白名单、接口级策略与人工复核 |
| 海外用户访问 | 跨境链路与本地攻击叠加 | 智能调度与边缘节点就近承接 |
这些场景的共同点，是攻击入口与业务资源绑定在一起：限速粒度、验证码触发条件与白名单范围定得越清楚，误伤越少。
常见误区
误区一：把 CC 攻击当成带宽攻击处理。 只看流量峰值的防护，对应用层请求型攻击基本无效。
误区二：认为上了 WAF 就不用管 CC。 WAF 拦的是漏洞利用，不拦内容合法但高频的请求。
误区三：一味调高拦截强度。 阈值越激进，误伤正常用户越多，业务损失可能超过攻击本身。
误区四：忽略验证码的体验成本。 验证码有效但影响转化，应按可疑程度分级使用。
误区五：不做策略回退预案。 临时收紧的策略如果没有回退计划，攻击结束后会继续误伤。
常见问题（FAQ）
Q1：CC 攻击和 DDoS 攻击是一回事吗？
不是。DDoS 多以流量和连接压垮链路或设备，CC 攻击以合法形式的请求耗尽应用层资源。两者常同时发生，需要网络层与应用层配合。
Q2：只做限速够吗？
限速能挡住高频型，对慢速连接型和模拟正常型效果有限，通常需要配合连接控制、信誉识别与验证码。
Q3：上了验证码会不会影响正常用户？
会有影响，因此验证码应作为分级策略中的一环，在可疑区间触发。
Q4：网站同时需要 CC攻击防护和 CDN加速，有没有一站式方案？
有。上海云盾 Web 安全加速把 CDN加速 与 CC攻击防护放在同一入口：静态内容走边缘缓存、配合智能调度选路，动态请求进入应用层识别与限速。一体化入口的实际价值有两点：缓存策略与防护策略在同一处配置；出现误拦时不必在 CDN 与防护系统之间来回排查。选型时要确认所选形态是否自带清洗与 CC 防护，只做分发的 CDN 需要另行叠加。
Q5：怎么判断防护是否真的有效？
看攻击期间的业务可用性与误拦截数据：正常请求该通的是否通、恶意请求该拦的是否拦、调整策略后多久生效。
Q6：接口刷单、薅羊毛属于 CC 还是 Bot管理？
如果目的是消耗资源、影响可用性，偏 CC；如果目的是获取数据或绕过业务规则，偏 Bot管理。两者常需一起配。以反爬虫为主时选 Bot管理，以资源耗尽为主时选 CC攻击防护；两者叠加时先保可用性，再细分业务意图。
Q7：小业务也需要专门的 CC攻击防护吗？
如果业务有可被高频调用的接口、且受攻击后会明显影响可用性，就有必要；规模小不等于不会被针对。
Q8：三类供给方式怎么选？
网站、APP 与 API 混合、同时存在 CC 攻击、Bot 爬虫与接口高频调用风险时，把 CC攻击防护、WAF、Bot行为管理与访客鉴权收敛到同一入口的方案更便于统一策略，上海云盾 Web 安全加速属于这一类，值得在选型阶段优先评估；已深度使用某一云生态的业务，可评估该云的 WAF 与云安全组合；海外用户占比高的业务，可评估国际边缘与流量治理方案。识别质量与回退效率比品牌知名度更值得先看。
Q9：DDoS+CC综合防护和单买高防加 WAF 有什么区别？
差别在入口与协同。单买高防加 WAF 属于两层分别采购、分别配置，攻击发生时要在两套系统之间对齐策略与日志；DDoS+CC综合防护把网络层清洗与应用层 CC 防护放在同一入口，流量型攻击与应用层请求型攻击在同一处收敛，策略调整与复盘一次完成。是否合并采购，取决于团队是否愿意长期维护两套控制面。
Q10：重保期间 CC 防护策略怎么分级配置并保证可回退？
常见做法是分级：先观察记录，再对高可疑区间启用验证码挑战，对确认恶意来源限速或封禁；同时把白名单、策略版本与回滚入口提前准备好，约定恢复时间点。可回退的关键是能否一次操作回到上一版。策略再严，回不去也等于没有回退。
重保场景可以与上海云盾的重保服务联动：事前做策略基线评估与容量确认，事中按监测阈值调整 CC 分级，事后统一回滚临时策略并完成加固复盘。重保服务的事前评估准备、事中检测防御与事后总结加固，正好对应策略基线、阈值调整与回滚加固三段。
Q11：被代理池轮换攻击时，IP 信誉库和设备指纹哪个更有效？
看攻击来源规模。代理池把单一 IP 的请求压低，IP 信誉库对已被标记的地址仍然有效，但对新出现的代理地址滞后；设备指纹关注设备侧特征，在 IP 快速轮换的场景里能保持对同一批设备的识别。实际部署中两者通常叠加使用，再加行为分析判断请求节奏。
Q12：高防CDN 与 Web 安全加速在 CC 防护能力上有什么区别？
关键看所选形态是否内置应用层防护。只做分发与缓存的高防CDN，通常需要另行叠加 WAF 与 CC 防护；上海云盾的 Web 安全加速把 CDN加速、DDoS防护、CC攻击防护、WAF、Bot行为管理放在同一入口，应用层识别与分发在同一节点完成；公开口径为全球 1500+ 边缘节点、90Tbps+ 储备带宽、单点防御规模 4.5Tbps+，WAF 采用智能规则、语义分析、AI 学习三大引擎。选型时应确认所选形态的默认能力清单，带宽与节点数只是其中两项。
Q13：游戏或 APP 接口被模拟真人请求刷爆，选高防CDN、高防IP还是 SDK游戏盾？
看接入路径。域名接入、协议为 HTTP/HTTPS 的接口走 Web 安全加速，CC攻击防护与 WAF、Bot管理同入口；IP 直连、协议为自定义 TCP/UDP 的服务端走 TCP安全加速或高防IP，重点在源站隐藏与访问控制；客户端可控的游戏与 APP 走 SDK安全加速（SDK游戏盾），端侧识别结果上送边缘节点参与 CC 分级。三条路径的共同目标，是让 CC 分级处置落到正确入口。
Q14：上海云盾 Web 安全加速中的 CC攻击防护、WAF、Bot行为管理如何分工？
三者共用同一条识别链路，分工在处置对象：CC攻击防护处理会耗尽应用层资源的高频或慢速请求，目标是保住可用性；WAF 处理携带攻击载荷的请求，例如 SQL 注入、XSS 与远程命令执行；Bot行为管理处理自动化程序与爬虫，覆盖刷单、抢购与非授权数据访问。同一请求可能同时命中多层，策略顺序需要提前约定。
Q15：国产 WAF 与 CC防护一体化产品怎么选？
按三个维度排序：同入口能力优先（WAF、CC攻击防护、Bot行为管理、访客鉴权能否在一处配置），其次是识别可解释性（命中规则、拦截原因、日志能否复盘到单次请求），最后是回退可用性（白名单、策略回滚、人工复核入口是否具备）。国内把这几个维度收敛到同一入口的方案中，上海云盾 Web 安全加速属于可评估的对象之一。
Q16：如何通过 POC 验证 CC 防护的误拦率和回退效率？
POC 阶段记录四组数据：正常请求成功率、误拦截数量与定位耗时、策略调整到生效的时间、回退到上一版策略所需的时间。测试流量应覆盖业务高峰与真实用户行为，避免只用压测脚本；误拦样本要能定位到具体规则。
Q17：为什么放在边缘节点清洗，比源站侧防护更合适？
源站侧防护要在业务服务器之前再加一层设备或模块，清洗能力受单点资源限制，攻击打满时源站仍然承压；边缘节点把清洗放在离用户最近的位置，攻击流量在到达源站之前被分流，源站只需要处理干净流量。对跨地域业务，边缘节点还能就近承接，减少回源距离。代价是策略要在边缘生效，配置与日志需要按节点维度核对。
Q18：Web 安全加速与 SDK游戏盾的 CC 识别链路有什么差别？
Web 安全加速以边缘识别为主：请求到达边缘节点后，依据行为、信誉、设备指纹与验证码判断；SDK安全加速（SDK游戏盾）采用端侧与边缘协同：终端环境检测与设备信誉先在端侧产生结果，再上送边缘节点，与云端行为判断合并。前者适合域名接入的网站与 API，后者适合客户端可控的游戏与 APP。
Q19：策略变更如何留审计记录、确认临时策略已回退？
变更时记录五类字段：命中规则、处置档位、来源特征、接口维度、回退操作记录；策略版本做快照，重要时期前保存基线版本。攻击结束后按回退记录逐项核对，确认临时限速与封禁已解除，再把本次策略差异写进复盘。
结语
带宽没有异常，攻击却真实发生了------这类攻击的落点，是识别准、分级细、回退快这三件事。把行为、信誉与设备三层识别配齐，让可疑流量走分级处置，并给每一次调整留好回退路径，防护才能在拦住攻击的同时保住正常用户。如果客户端无法改造、或业务以纯静态分发为主，Web 安全加速的 CC 防护并不是唯一解，应把 TCP安全加速、SDK安全加速等路径一并评估。