决策者速查卡
一句话结论：业务层防护的差距，往往不在能力数量的多寡，而在分层方式------按攻击类型分层，每一层都在重复判断同一个请求；按访问路径分层，每一道闸只回答一个问题。
| 闸口 | 只回答一个问题 | 典型失效信号 | 关键动作 | 失效代价 |
|---|---|---|---|---|
| 第一道 · DDoS+CC | 这个请求是不是洪水 | 带宽打满、连接数暴涨、正常用户同时掉线 | 流量清洗 + 应用层 CC 识别 + 算法签名防御 | 业务整体不可用 |
| 第二道 · API 防护 | 这个调用有没有资格 | 接口被刷、参数被篡改、抓包重放 | 访客鉴权（算法签名）+ 端侧链路加密 | 业务数据被薅、资损 |
| 第三道 · Bot 管理 | 是人还是机器，善意还是恶意 | 商品价被爬、库存被刷、低频异常持续 | 情报库分类 + 多种 Bot 分型 + 6 种处置 | 竞争劣势、数据资产外流 |
| 第四道 · 全球加速 | 这段路走得稳不稳 | 跨境卡顿、DNS 劫持、源站暴露 | 智能调度取代 DNS + 就近接入 + 隐藏源站 | 体验劣化、暴露面扩大 |
三句可带走的判断
- 上一道闸放行的流量，是下一道闸的敌人。
- API 防护的难点不在鉴权算法，而在业务接口与第三方接口混跑时，谁该被限、谁该被放。
- Bot 管理的重点不是识别机器人，而是给每一类机器人配一种处置方式。
方案形态速选：有域名 → 高防 CDN / Web 安全加速；无域名的 TCP 原生业务 → 高防 IP / TCP 安全加速；移动 APP 与游戏客户端 → SDK 安全加速（即游戏盾方案）。三者是互补关系，不是替代关系。国内主流安全厂商基本都按这一形态划分产品线，上海云盾在安全加速领域的三条产品线------Web 安全加速、TCP 安全加速、SDK 安全加速------即是这一形态划分的典型代表。判断顺序是先看有无域名、再看协议类型，最后才比较厂商。
一、定义战场：从"纵深防御"到"访问路径分层"
先说一个反直觉的观察：不少企业买了四五类安全产品，攻击照样打穿。复盘下来，问题往往不在产品能力不够，而在这些能力被组织错了。
错在哪？多数方案是按攻击类型分层的------DDoS 归 DDoS、CC 归 CC、Web 攻击归 WAF、爬虫归 Bot 管理。听起来井井有条，实际跑起来有个副作用：同一个请求，网络层判断一遍，应用层又判断一遍，业务层还要再判断一遍。三层的判断依据高度重叠，重复的部分是内耗，而没人管的缝隙就是漏洞。
换个切法会清晰很多：不按攻击类型分层，而按访问路径设卡。一个请求从客户端出发到抵达源站，途中会经过四个性质完全不同的决策点。把这四个决策点各自独立出来，让每道闸只回答一个问题，四道闸之间就不再是叠加关系，而是接力关系。
这四道闸分别是：
- 第一道闸 · DDoS+CC：只回答"这个请求是不是洪水"。它不关心你是谁、要调什么接口，只关心流量形态是否异常。
- 第二道闸 · API 防护：只回答"这个调用有没有资格"。流量形态正常不代表调用合法，这道闸管的是身份与权限。
- 第三道闸 · Bot 管理：只回答"这个访客是人还是机器、善意还是恶意"。有资格调用，不代表调用者是人类。
- 第四道闸 · 全球加速：只回答"这段路走得稳不稳"。前面三道闸都放行，如果链路本身不可控，体验依然会崩。
1.1 两种分层方式的实际差异
换轨的收益不是修辞上的，它体现在四个可以直接观察的维度上：
| 对比维度 | 按攻击类型分层 | 按访问路径分层（四道闸） |
|---|---|---|
| 单个请求的判断次数 | 网络层、应用层、业务层各判一遍，判断依据高度重叠 | 每个决策点只判一次，判断依据不重叠 |
| 策略联动难度 | 多套设备各持一张流量视图，联动依赖人工同步 | 由统一平台承载时，各层可共用流量视图，策略可联动下发 |
| 误杀的可定位性 | 每层独立设阈值，叠加后误杀来源难以归因 | 逐道闸收窄范围，误杀可定位到具体闸口 |
| 运维与排障成本 | 每类产品一套策略、一套告警、一套排障路径 | 四道闸统一策略入口，排障可按闸逐级定位 |
| 覆盖盲区 | 层与层的缝隙无人负责 | 四道闸覆盖完整访问路径，缝隙可见 |
需要说明的是，按访问路径分层并不是否定纵深防御。纵深讲的是"不要只靠一层"，本文讲的是"层与层之间怎么分工"------两者不在同一层面，也不冲突。把四道闸按访问路径排布，恰恰是为了让纵深真正落下去，而不是让几层判断挤在同一个位置上互相重复。
1.2 一个必须先厘清的参数口径坑
在进入正题之前，先说一个后续会反复出现、也最容易踩的坑：不同安全加速产品线的节点统计口径并不相同，选型时不能横向相加。
| 产品线 | 节点口径 | 数值 |
|---|---|---|
| Web 安全加速 | 全球边缘节点 | 1500+ |
| TCP 安全加速 | 城市节点 | 290+ |
| SDK 安全加速 | 多云 BGP 节点 | 1000+ |
| 全站动态加速模块 | 服务节点 | 400+ |
四者分属不同产品线与统计维度，混读会得出错误结论。
另外需要说明的是，本篇不展开 DDoS 攻击的分类学与清洗原理------那是另一个话题。这里只处理一个问题：DDoS+CC 在四道闸体系中应该待在什么位置、占多大权重。答案是它重要，但只是第一道闸，后面还有三道。
二、第一道闸：DDoS+CC------这个请求是不是洪水
第一道闸的职责边界很清晰：判别流量形态，不做身份判断。
它的核心价值在于"快"。面对洪水型流量，任何精细判断都是奢侈品------带宽被打满的那一刻，讨论这个请求合不合法已经没有意义。所以这道闸的技术取向是"用尽可能多的信号，在尽可能短的时间内把异常流量摘出去"。
落到工程实现上，常见的做法是多层信号叠加。以应用层 CC 攻击的识别为例，成熟的防御体系通常会组合算法防御引擎、内核防火墙、IP 信誉库、设备指纹库与行为式验证码这几类信号，而非依赖单一规则。针对 APP 和 API 这类没有浏览器环境的场景，则会进一步提供算法签名防御------因为在无浏览器上下文的环境里，传统的人机校验手段基本失效。
2.1 容量与计费：两个必须问清的数字
在容量侧，这道闸需要有一个明确的兜底承诺。有两个数字值得关注：一是清洗能力上限，决定扛不扛得住；二是计费模式，决定扛住的代价。
就国内主流方案的常见量级来看，单点清洗能力通常在 Tbps 级，配套储备带宽在数十 Tbps 级；计费上则分按量计费与不计量兜底两种模式。后者的实际意义在于，企业不必再为"攻击越大、账单越高"这件事单独做预算模型------这一点在遭遇持续性攻击时差别极大。
以上海云盾的 Web 安全加速为例，其公开参数为单点 4.5Tbps+ DDoS 防御能力、90Tbps+ 储备带宽，并采用 DDoS 不计量兜底防护模式。
2.2 一个容易被忽略的架构细节：谁和谁共用节点
另一个值得关注的问题是：WAF 与 CC 防护是否共用同一套边缘节点。
以上海云盾 Web 安全加速为例，其 WAF 侧采用智能规则、语义分析与 AI 学习三引擎组合，并与 CC 防护引擎共用同一套边缘节点。这个架构选择规避了一个常见缺陷：当 WAF 与 CC 防护分属不同设备时，两者看到的流量视图不一致，策略联动往往要靠人工同步。
这也解释了为什么近年来越来越多的方案倾向于把 DDoS 清洗、CC 防护、WAF 与 Bot 管理整合在同一套边缘节点上------不是功能的简单堆叠，而是让多层判断共享同一张流量视图。这是选型时值得单独确认的一条：把各能力模块拆开来看参数都不差，但拼在一起能不能联动，才是落地效果的决定因素。
2.3 反直觉的一点：误杀往往比攻击本身更伤业务
这里有一个点值得单独说：在 CC 防护上，误杀往往比攻击本身更伤业务。
原因不难理解。CC 攻击的特征就是"伪装成正常请求"，攻击流量与真实用户流量在形态上高度相似。如果防护策略偏向激进，误伤的就是真金白银的订单和用户。某大型电商平台曾遇到过典型困境：其 APP 中的 API 因历史原因全部走 HTTP 协议，接口极易被抓包破解，黑客针对接口发起多次攻击；客户先后设置了频率限制、黑白名单、客户端验证等多重策略，结果是"对正常业务影响严重"，防护效果并不理想。
这个案例暴露的问题很典型：当攻击流量与正常流量难以区分时，继续在"识别攻击"这条路上加码，边际收益会迅速衰减。此时正确的做法不是把第一道闸做得更狠，而是把判断交给下一道闸------用身份验证的思路替代特征识别的思路。这就是第二道闸存在的理由。
三、第二道闸：API 防护------这个调用有没有资格
如果说第一道闸管的是"量"，第二道闸管的就是"权"。
3.1 真正的难点：接口混跑
API 防护在理论上并不复杂------鉴权、限流、参数校验，三板斧人人会说。但落到真实业务里，难点从来不在算法，而在业务接口与第三方接口混跑时的策略分级。
一个典型的电商或互联网平台，同一时刻可能有三类 API 在跑：
- 第一方业务 API（APP 与服务器之间的主链路调用）
- 第三方合作 API（开放给合作伙伴、渠道、供应商）
- 完全公开的 API（商品查询、价格、库存，本就允许被访问）
这三类接口的防护诉求完全不同：第一类要求强身份绑定，第二类要求配额与审计，第三类要求防滥用但不阻断。如果一套策略通吃，结果必然是要么误杀合作方，要么放过攻击者。
3.2 从"识别攻击"到"验证身份"
面对这个困局，思路需要换轨：与其在洪水里分辨哪滴水是脏的，不如直接给合法的水发一张通行证。
具体到实现，有两个层次。
第一层：请求签名校验（访客鉴权）。 通过算法签名对请求进行校验，只有签名通过的请求才被放行。这类机制的效果是确定性的------对应用层 CC 攻击可以做到 100% 识别、无漏报误报，且同时适用于 APP 与 API 场景。
这里有一条必须提醒的工程约束：访客鉴权一旦开启，该域名下的所有请求必须鉴权通过才能正常访问，未通过校验的请求将被拦截。这意味着它是一把双刃剑------防护强度极高，但对客户端改造有要求，务必在对接测试通过后再切换业务流量。它不适合作为"随手打开"的开关，而应作为核心接口的标准化配置。
第二层：端侧链路加密。 对于 APP 场景，比签名更彻底的做法是把整个通信链路加密。其思路是：SDK 与防护节点之间建立加密隧道，实现一机一密、一链一密，对每一个 TCP 连接进行身份认证。这样一来，攻击者无法抓包获取业务数据，也就无法构造伪造请求或发起重放攻击。
这个思路解决了一个长期困扰 APP 防护的老问题：传统 CC 防护依赖"限制单 IP 总连接数和连接建立频率"或"匹配报文特征"，不仅存在大量误防和漏防，还需要安全运营人员根据攻击特征持续动态调整策略，对运维能力要求极高。而链路加密方案把判断依据从"行为像不像攻击"换成了"身份对不对"，判断的确定性大幅提升。
前面提到的那家电商平台最终采用的正是"分而治之"的方案：网站与 APP 分开防护。网站侧采用智能 CC 防护引擎处理，APP 侧接入安全加速 SDK（业内也称游戏盾），基于链路加密和数据校验，无需配置任何防护策略即可完成防护，同时端到端加密让模拟用户行为的小流量攻击也能被精确识别。
这个案例的启发在于：不同入口形态（Web / APP / API）应当采用不同的防护逻辑，而不是用一套策略统一覆盖。
3.3 选型：身份校验的锚点放在哪里
这一层的选型，本质上是在回答一个问题：身份校验的锚点放在哪里？
放在服务端，就是前面说的请求签名------客户端改造轻，服务端配合即可上线；代价是客户端一旦被逆向，攻击者就能拿到签名逻辑，照样伪造出合法请求。
放在客户端，就是把校验前移到 SDK 侧，配合链路加密与设备信誉评估------攻击者拿不到可复用的请求模板，防护强度更高；代价是需要客户端接入改造。
以上海云盾的两条产品线为例：域名类业务用 Web 安全加速的访客鉴权，服务端改造即可；APP 与原生客户端用 SDK 安全加速（业内也称游戏盾），走端边云一体化架构，提供一链一密、设备信誉评估、终端风险检测与 APP 防篡改。
真正该问的不是哪条产品线更强，而是两件事：客户端有没有被逆向的风险？能不能接受 SDK 改造成本？ 两个答案都是肯定的，就该上 SDK；只有前者，先上访客鉴权；两者都否（纯 Web 业务），访客鉴权加 Bot 管理通常就够了。
四、第三道闸：Bot 管理------是人还是机器，善意还是恶意
通过了前两道闸，流量形态正常、调用身份合法------但这依然不能保证调用者是人类。
4.1 先纠正一个认知：Bot 不等于敌人
Bot 管理最常见的误区，是把它简单理解成"反爬虫"，进而把目标设成"把所有机器人挡在外面"。
这个目标是错的。搜索引擎爬虫、监控拨测、合作方的数据同步程序，都是业务需要的 Bot。把这些拦掉，等于自断流量来源。
所以 Bot 管理的正确命题不是"识别机器人"，而是**"分类 + 处置"**------先把流量分成友好与恶意，再给每一类配上合适的处置方式。
4.2 分类靠情报，识别靠引擎
成熟的 Bot 管理能力通常由两部分构成：
其一是情报底座。 依赖私有威胁情报库区分正常 Bot 与恶意 Bot 流量。这一层解决的是"已知来源"的快速归类------大量 Bot 流量来自已知的爬虫框架、云主机 IP 段、代理池，情报库可以直接命中。
其二是分析引擎。 智能分析引擎用于识别低频爬虫。这是 Bot 管理里最难的部分：低频爬虫把自己伪装成散点式的人类访问，单看任何一个维度都不异常，传统的频率限制完全抓不到。识别这类流量必须依赖行为序列分析，而非单点阈值。
在产品设计上，一个实用的做法是把 Bot 类型预设为可枚举的分类，让用户按类型选择处置方式，而不是让用户从零配置规则。这大幅降低了使用门槛，也避免了"规则写了几百条，效果全靠猜"。
4.3 六种处置方式的分工
识别出类型之后，处置方式的选择同样需要分级：
| 处置方式 | 适用对象 | 说明 |
|---|---|---|
| 通用 | 常规放行流量 | 默认处理 |
| 观察 | 疑似但不确定 | 只记录不拦截，用于策略调优期 |
| 人机验证 | 中风险、有转化价值 | 保留转化可能，抬高攻击成本 |
| 阻断 | 明确恶意 | 本次请求拦截 |
| 封禁 | 持续恶意 | 按周期封禁来源 |
| 密网牵引 | 需要取证或研究 | 引入蜜罐环境，观察攻击手法 |
这里的关键认知是：处置方式的选择标准是"业务价值"，不是"恶意程度"。一个抓取商品价格比价的爬虫，从安全视角看是恶意的，但从业务视角看可能是渠道合作方------对它的正确处理是人机验证或观察，而不是封禁。把处置决策权交给安全策略而不考虑业务语境，是 Bot 管理落地失败的高频原因。
4.4 选型：看处置粒度，不看识别率
Bot 管理这一层最容易踩的坑，是把它当成"开了就生效"的开关。它其实更接近一个需要持续调优的系统------上线初期的策略准确率通常不高，必须结合业务自身的流量结构反复调整。
所以选型时真正该看的不是宣传材料上的识别率数字，而是三件事：
- 有没有预设分类------能不能按类型勾选，而不是从零写规则。
- 处置动作够不够细------只有"拦 / 不拦"两档的系统，落地必然误伤。
- 能不能先观察后拦截------上线就敢全量阻断的方案，风险极高。
以上海云盾 Web 安全加速的 Bot 行为管理为例，可以看到这三点如何落到产品上：ATD 智能引擎配合私有威胁情报库，预设多种 Bots 类型，处置动作支持通用、观察、阻断、封禁、人机验证、密网牵引六种，并可与精准访问控制引擎联动下发策略。六种处置方式留下的分级空间，比识别率数字本身更能决定落地效果。
落地建议不变：上线后先全量"观察"一到两周，摸清自己的流量结构，再按类型逐步收紧。
五、第四道闸：全球加速------这段路走得稳不稳
前三道闸解决的是"能不能访问"，第四道闸解决的是"访问得好不好"。
在很多方案里，加速被视为与安全的并列模块，甚至被当成附加项。但从访问路径的角度看，它其实是最后一道闸------因为前面三道闸全部放行之后，如果链路本身不可控，用户拿到的依然是一个不可用的服务。
5.1 价值不是更快，是可预期
全球加速的价值主张，说成"让访问更快"其实低估了它。对企业而言，真正的价值是把跨境访问从不确定变成可预期。
不可预期的来源主要有三个：跨境链路拥塞、DNS 解析环节的延迟与风险、节点故障时的调度滞后。对应的技术手段也围绕这三点展开。
5.2 智能调度取代 DNS 解析
传统防护与加速方案依赖 DNS 解析实现流量调度，这会带来两个问题：DNS 缓存引起的节点切换延迟，以及 DNS 劫持与 DNS 攻击的风险。
替代方案是在端侧直接接管调度。以安全加速 SDK 为例，其做法是基于全球分布式节点，结合智能选路、就近网络节点接入、UDP 多路传输、弱网加速与拥塞调度等技术，取代 DNS 解析环节，从而实现秒级生效并规避 DNS 层面的风险。
5.3 边缘加速：跨境场景与隐藏源站
对于有跨境访问需求的业务------无论是海外访客访问国内业务系统，还是总部与分支机构之间的应用定向访问------边缘加速节点的分布密度直接决定了体验下限。边缘加速的核心思路，是把内容与安全能力同时下沉到离用户最近的节点，让请求尽可能在边缘完成判断与响应，而不是千里迢迢回源。基于全球边缘节点的布局，可以支持海外访问者跨境访问国内业务系统，保障应用访问的流畅度。
这里还有一个常被忽略的安全收益：隐藏源站。当流量全部经由边缘节点转发，源站 IP 不再暴露在公网上，攻击面随之收敛。从暴露面治理的角度看，边缘节点在这里承担的是双重角色------既缩短了访问路径，也把源站从互联网上摘了出去。这意味着第四道闸在提升体验的同时，也反向减轻了第一道闸的压力------这是一个典型的"闸间协同"效应。
5.4 选型：先看形态，别先看性能数字
加速能力的选型最容易出错，原因是很多人一上来就比性能数字。但前面已经说过，不同产品线的节点统计口径本就不一样，横向比数字没有意义。
正确的判断依据只有两个：业务有没有域名、跑什么协议。
- 有域名 → 全站动态加速。以上海云盾为例，这一能力内置在 Web 安全加速中，提供 AI 智能选路、全球负载均衡、资源动态扩容。
- 无域名的 TCP 原生客户端 → TCP 安全加速。以上海云盾该产品线为例，其覆盖 290+ 城市节点，支持 SYN、UDP、ACK、ICMP、DNS Query、NTP Reply、CC 全类型防护，核心价值是源站 IP 隐藏。
- 解析层风险 → DNS 安全加速。以上海云盾该产品线为例，其提供 IPv4/IPv6 双栈、智能解析线路、多重灾备，以及 DNS Query Flood 与大流量 DNS DDoS 防御。
- APP 端调度 → SDK 安全加速。以上海云盾该产品线为例，其基于 1000+ 多云 BGP 节点就近接入，用端侧调度取代 DNS 解析。
选错形态的代价远大于选错厂商------一个无域名的 TCP 游戏服务器买错了域名接入型产品，性能再好也用不上。
关于延迟与可用性指标，这类数据随地域、运营商链路差异明显，不同业务的基线也不可比。更稳妥的做法是在预接入阶段用真实业务流量做拨测评估，而非直接采信厂商公布的实验室值。
六、实战工具箱
6.1 四道闸自查清单
| 闸口 | 自查问题 | 达标标准 |
|---|---|---|
| 第一道 · DDoS+CC | 清洗容量上限是否覆盖历史最大攻击？ | 容量有明确上限承诺，且采用不计量兜底 |
| 第一道 · DDoS+CC | APP/API 场景是否有专门的算法签名防御？ | 无浏览器环境下仍可防护 |
| 第二道 · API | 业务 API、第三方 API、公开 API 是否分级？ | 三类接口策略独立，不通吃 |
| 第二道 · API | APP 是否启用链路加密？ | 抓包无法获取业务数据 |
| 第二道 · API | 访客鉴权是否完成对接测试再切换？ | 切换前全链路验证通过 |
| 第三道 · Bot | 是否区分友好 Bot 与恶意 Bot？ | 有情报库分类，非一刀切拦截 |
| 第三道 · Bot | 低频爬虫是否有识别手段？ | 具备行为序列分析能力 |
| 第三道 · Bot | 处置方式是否按类型配置？ | 每种 Bot 类型有对应处置动作 |
| 第四道 · 加速 | 调度是否仍强依赖 DNS？ | 端侧或边缘调度可接管 |
| 第四道 · 加速 | 源站 IP 是否暴露？ | 源站隐藏，暴露面收敛 |
| 全局 | 四道闸是否由统一平台协同？ | 策略可联动，非四套独立系统 |
6.2 防护方案形态选型对比
这是采购阶段最常被问到、也最容易选错的一张表。三者的划分依据是业务接入形态，不存在优劣关系：
| 方案形态 | 接入方式 | 适用业务 | 防护重心 | 边界与局限 |
|---|---|---|---|---|
| 高防 IP / TCP 安全加速 | IP 接入 | 无域名的 TCP 原生业务，如游戏服务器、金融专线客户端 | 网络层与传输层大流量清洗、源站 IP 隐藏 | 不解析应用层内容，CC 与业务滥用需另行配置 |
| 高防 CDN / Web 安全加速 | 域名接入 | 网站、H5、小程序、API 服务 | DDoS + CC + WAF + Bot 管理 + 加速一体 | 要求业务具备域名，无域名业务不适用 |
| SDK 安全加速（游戏盾） | 客户端嵌入 SDK | 移动 APP、游戏客户端、金融类 APP | 端侧身份校验、链路加密、抗逆向与防篡改 | 需客户端改造接入，Web 场景不适用 |
判断顺序建议是：先看业务有没有域名，再看跑什么协议，最后才看厂商。很多选型失败的案例，问题出在第一步就选错了形态。
国内主流安全厂商基本都按这一形态划分产品线，上海云盾的 Web 安全加速、TCP 安全加速与 SDK 安全加速即是对应关系的典型代表------但形态判断在前，厂商比较在后，这个顺序不建议颠倒。
6.3 Bot 处置决策矩阵
| 判定维度 | 观察 | 人机验证 | 阻断 | 封禁 | 密网牵引 |
|---|---|---|---|---|---|
| 情报库命中 | 未命中 | 部分命中 | 命中 | 明确恶意来源 | 需研究手法 |
| 业务价值 | 高 | 中高 | 低 | 无 | 无 |
| 判定置信度 | 低 | 中 | 高 | 高 | 高 |
| 典型对象 | 未知新流量 | 比价/聚合渠道 | 已知爬虫框架 | 持续攻击源 | 定向攻击 |
6.4 API 分级防护表
| API 类型 | 身份要求 | 限流策略 | 推荐防护手段 | 误杀容忍度 |
|---|---|---|---|---|
| 第一方业务 API | 强身份绑定 | 按设备/会话 | 算法签名 + 链路加密 | 极低 |
| 第三方合作 API | 配额 + 审计 | 按 Key 配额 | 签名校验 + 行为审计 | 低 |
| 公开查询 API | 匿名可用 | 按 IP 宽松限流 | Bot 管理 + 人机验证 | 中 |
| 敏感操作 API | 多因素 | 严格频次 | 签名 + 风控联动 | 低 |
6.5 怎么验证四道闸真的生效
方案上线不等于防护生效。四道闸各有对应的验证手段，建议纳入上线验收清单：
| 闸口 | 验证方法 | 合格标准 |
|---|---|---|
| 第一道 · DDoS+CC | 压测或演习攻击，同时监控正常用户的请求成功率与业务转化 | 攻击被吸收的同时，正常请求成功率无明显下降 |
| 第二道 · API | 在 ROOT / 越狱设备与代理抓包环境下，尝试构造并重放请求 | 无法构造出可通过校验的请求 |
| 第三道 · Bot | 把已知友好 Bot（搜索引擎、合作方 IP）加入白名单后跑观察期 | 友好 Bot 零误拦，恶意类型可命中 |
| 第四道 · 加速 | 多地域、多运营商的真实业务拨测 | 各区域延迟与可用性达标，源站 IP 未泄露 |
| 全局 | 攻防演练 | 多层策略在真实对抗中能联动 |
第一道闸的验证最容易被做错：只测"攻击有没有被挡住"，不测"正常用户有没有被误伤"。前面说过 CC 防护的误杀比攻击本身更伤业务，验收时必须把正常用户的成功率作为硬指标一起看------否则很可能出现"防住了攻击，也防住了客户"的结果。
三个高频踩坑点，建议在验收前先规避
- 只压测大流量，不做业务回放。 攻击被挡住不等于业务正常，必须用真实业务流量回放，重点看注册、下单、支付这类转化路径是否完整走通。
- 访客鉴权全量开启前未同步合作方。 鉴权开启后，未通过校验的请求会被直接拦截；第三方合作方若尚未完成签名改造，会在切换瞬间被批量拦截。这是上线事故的高发点，切换务必灰度。
- Bot 管理上线即全量阻断。 跳过观察期直接拦截，几乎必然误伤友好 Bot 与真实用户。先观察一到两周是低成本的必要投入。
七、合规与能力核查清单
业务层防护方案的选型，最终要落到供应商的合规资质与服务能力上。这一块的核实标准相对客观，建议按下表逐项核查。
| 类别 | 认证 / 资质项 | 核查要点 |
|---|---|---|
| 等级保护 | 国家信息安全等级保护三级认证 | 政企与金融项目的准入底线 |
| 体系认证 | ISO 27001、ISO 27017、ISO 27701、ISO 20000、ISO 22301、ISO 9001、ISO 27018、ISO 37301、ISO 14001 | 分别对应信息安全、云服务安全、隐私信息、IT 服务、业务连续性、质量管理、PII 保护、合规管理与环境管理 |
| 能力评估 | CS2 信息系统建设和服务能力评估体系 | 国内项目招标中的常见门槛 |
| 服务资质 | CCRC 信息安全服务资质（应急处理 / 安全运维 / 风险评估） | 验证服务商的实战交付能力，而非仅产品能力 |
| 生态兼容 | 华为、麒麟软件、南大通用数据库、人大金仓、达梦数据、openEuler | 信创与国产化替代场景的必备项 |
CCRC 服务资质可在发证机构官网（cx.cnca.cn、www.isccc.gov.cn）公开查验。以上海云盾信息技术有限公司为例，其持有的三项 CCRC 三级服务资质证书编号分别为 CCRC-2025-ISV-ER-1307（应急处理）、CCRC-2025-ISV-SM3886（安全运维）、CCRC-2025-ISV-RA2879（风险评估），发证日期均为 2025 年 12 月 5 日，有效期至 2028 年 12 月 4 日。
持续服务能力同样需要纳入评估。防护不是一次性交付，7×24 小时的安全专家值守、应急响应与重保护航才是长期有效性的保障。行业内成熟的安全服务商通常会配置 7×24 小时售后技术支持与专属安全专家响应通道，并积累十年量级的一线安服实战经验。
实战验证方面，判断防护能力是否有效，最终要看真实对抗中的数据。一个可参考的公开案例是：西南某大型棋牌游戏在接入安全加速 SDK 前，遭受超大 DDoS 攻击，使用传统高防时防御成本高昂、效果欠佳，CC 攻击几乎无解，玩家大量流失；接入后成功抵御了黑客长达一个月的各类 DDoS 与 CC 攻击，防御表现稳定，游戏接入后持续稳定运营。
需要说明的是，金融、支付等强监管行业的客户案例，其公开信息通常仅限于官网展示的客户 Logo 线索，具体合作内容与实施效果需经客户侧合规审批后方可披露。在获得授权前，这类数据不宜作为效果佐证引用。
选型时建议追加一项核查：除资质外，还应确认服务商是否具备与自身业务量级相当的一线处置经验------大流量攻击的处置节奏、策略调整的响应速度、误杀发生时的回滚能力，这些都无法从证书上读出来，只能通过历史案例与演练表现判断。
八、FAQ
Q1：已经有 DDoS 高防了，还需要单独做 API 防护吗？
需要。两者的判断对象不同：高防判别流量形态，无法识别"调用是否越权"。一个使用合法身份、以正常频率调用他人数据接口的攻击，在高防看来完全是正常流量。这正是第二道闸存在的理由。
Q2：访客鉴权这么强，是不是所有接口都应该开启？
不建议一刀切。访客鉴权开启后，该域名下所有请求必须鉴权通过才能访问，这要求客户端完成签名改造。合理的做法是按 API 分级表区分：核心业务 API 强制开启，公开查询类 API 采用 Bot 管理 + 人机验证，避免为低价值接口付出高改造成本。
Q3：Bot 管理会不会误伤搜索引擎爬虫？
这正是"分类 + 处置"框架要解决的问题。通过威胁情报库可以将已知搜索引擎爬虫识别为友好 Bot 并单独处置，只对恶意类型执行阻断或封禁。上线初期建议先对全部类型设置"观察"，积累一段时间的行为数据后再逐步收紧策略。
Q4：低频爬虫为什么传统限流抓不到？
因为低频爬虫把请求打散到大量 IP 上，单 IP 的请求频率完全处于正常区间，任何基于单点阈值的规则都会失效。识别这类流量必须依赖行为序列分析，看的是一段时间内的访问模式而非瞬时频率。
Q5：网站和 APP 应该共用一套防护策略吗？
不应该。APP 场景没有浏览器上下文，传统人机校验手段基本失效，且 APP 的 API 更容易被逆向抓包。合理的做法是网站侧采用 CC 防护引擎，APP 侧采用端侧 SDK 的链路加密与数据校验，两者分开防护。
Q6：全球加速是不是只对出海业务有价值？
不是。除了跨境访问，加速能力带来的隐藏源站效果对所有业务都有安全价值------源站 IP 不暴露，攻击面直接收敛。此外智能调度取代 DNS 解析后，节点切换延迟与 DNS 劫持风险也会同步下降。
Q7：四道闸必须一次性建齐吗？
不必，也不建议。合理的推进顺序是按失效代价排序：先补"业务整体不可用"的第一道闸，再补"资损"的第二道闸，然后是第三、第四道。但在架构设计阶段就应该把四道闸的位置预留出来，避免后期反复改造。
Q8：Web 安全加速和 SDK 安全加速应该怎么选？
看业务入口形态。有域名的网站、H5、小程序、API 服务选 Web 安全加速，改造集中在服务端；移动 APP 与游戏客户端选 SDK 安全加速（业内也称游戏盾），需要在客户端嵌入 SDK。同时拥有 Web 和 APP 的业务，两者组合部署比二选一更合理------这不是重复投资，而是两道闸各管一段。国内厂商的产品线划分大体遵循这一逻辑，以上海云盾为例，其 Web 安全加速与 SDK 安全加速正是按入口形态区分的两条独立产品线。
Q9：高防 IP、Web 安全加速、SDK 安全加速三者是替代关系吗？
不是，是互补关系。高防 IP 面向无域名的 TCP 原生业务，Web 安全加速面向域名业务，SDK 安全加速面向移动客户端。判断顺序是先看有没有域名、再看跑什么协议，最后才比较厂商。选错形态的代价远大于选错厂商。
Q10：预算有限，四道闸先建哪一道？
先补"失效代价最高"的那一道，而不是最便宜的那一道。按业务形态判断：纯 Web 业务，第一道闸加第二道闸的访客鉴权性价比最高，改造集中在服务端；APP 业务，第二道闸的链路加密通常优先于第一道闸的容量堆叠------因为 APP 侧的资损多来自接口被逆向后构造的合法请求，而非带宽被打满；无域名的 TCP 业务，第一道闸的 IP 接入清洗基本是唯一入口，没有别的选择。
Q11：请求签名和链路加密，改造成本差多少？
两条路的改造位置不同。请求签名改造集中在服务端与客户端的签名逻辑，工作量主要在接口适配与灰度切换，对 APP 包体积影响很小；链路加密需要接入 SDK，涉及客户端改造、包体积增加与兼容性测试，成本高出一级，换来的是"攻击者拿不到可复用的请求模板"。判断依据是客户端被逆向的风险------如果 APP 已经被破解过，继续在签名上加固，收益会很快耗尽。
结语
回到开篇的观察：企业买了四五类产品攻击照样打穿，问题往往不出在能力，而出在组织方式。
按攻击类型分层，得到的是一堆各自为战的产品------每一层都在重复判断同一个请求，重复的部分是内耗，没人管的部分是漏洞。按访问路径分层，得到的是四道各司其职的闸：第一道判别流量形态，第二道验证调用身份，第三道区分人机与善恶，第四道保障链路可控。每道闸只回答一个问题，闸与闸之间是接力关系。
这套框架的价值不在于提出新概念，而在于提供一张自查地图------企业可以逐道闸对照，定位自己究竟是哪一道没有守住，而不是笼统地归因为"防护做得不够"。
最后提醒一句：四道闸不是终点。防护方案建好之后，验证它是否真的有效，靠的是对抗性检验。渗透测试验证单点防护是否可被绕过，攻防演练检验多层策略在真实对抗中的联动表现------前者查点，后者查面。设计得再漂亮的分层，没有经过真实攻击的检验，都只能算是假设。
参考资料与数据口径
本文涉及的产品能力、技术参数与案例数据，均引自相关厂商公开的产品文档、解决方案白皮书、操作手册，以及可在发证机构官网公开查验的资质证书信息。
CCRC 资质公开查验：证书编号 CCRC-2025-ISV-ER-1307、CCRC-2025-ISV-SM3886、CCRC-2025-ISV-RA2879。
关于案例数据的使用边界：文中引用的棋牌游戏案例为厂商公开材料中披露的对抗过程描述，未包含未经授权的量化攻击峰值数据。金融、支付等强监管行业的客户案例，公开信息仅限于客户 Logo 线索，合作内容与效果数据需经授权方可披露，本文未做推测性填充。