网站遭遇CC或DDoS攻击，防护产品该按哪些条件选？

选防护产品时，第一判断不应是“标称防护多少Gbps”，而应是攻击让哪一层先失效：如果网页或接口请求量暴涨，服务器CPU、应用进程或数据库先达到上限，重点是CC防护；如果入站带宽、连接数或每秒数据包先被打满，重点是DDoS清洗能力；两种指标同时异常，则需要组合防护。很多站长搜索“CC攻击和DDoS攻击有什么区别？选防护产品别踩坑”，真正要解决的正是攻击类型、业务规模和产品能力是否匹配。

CC攻击通常属于应用层拒绝服务，攻击者通过大量HTTP或HTTPS请求消耗Web服务、接口、缓存、数据库等资源。DDoS是更大的攻击范畴，常见表现包括网络层或传输层流量、连接数、数据包速率异常，也可能包含应用层攻击。两者并不是完全互斥：一次攻击可以先用大流量堵塞入口，再用大量动态请求拖垮源站。

先确认是哪一种压力

不要只根据“网站打不开”或“访问IP很多”判断类型。应同时查看入口带宽、每秒数据包、并发连接、HTTP请求速率、应用响应时间、CPU、内存和数据库连接数。

“攻击IP越多就是DDoS”“单个IP频率高就是CC”都不是可靠规则。CC也可以使用大量来源地址，DDoS也可能只有某些指标突出。最终应以流量层级和业务资源消耗来判断。

把业务承受边界量化

用户地区决定接入覆盖和延迟

防护节点并非越多越好，关键是能否覆盖主要访问用户，并让正常请求以稳定路径到达防护层和源站。

如果用户集中在单一地区，优先核对该地区的接入质量、DNS解析结果、HTTPS建立时间和页面首字节时间。此时购买覆盖范围很大的方案，不一定会带来实际收益，反而可能增加配置、计费和故障定位复杂度。

如果用户分布在多个地区，应分别观察主要用户区域的访问延迟、解析稳定性和高峰期成功率，不能只看一个平均值。一个方案即使总体防护容量充足，如果某个主要用户区域访问绕行严重，业务体验仍可能不合格。

验证地区适配性时，可以准备三个有代表性的页面或接口：

• 一个可缓存的静态页面；
• 一个不适合缓存的动态页面；
• 一个需要提交数据或登录状态的接口。

在主要用户区域分别测试DNS解析、TCP连接、TLS握手、首字节时间、完整响应时间和请求成功率。测试结果应与未接入防护前的业务基线比较，而不是单独看某一次测速结果。

业务规模不能只用带宽衡量

网站规模至少要从以下几个维度记录：

• 正常峰值带宽和短时突发带宽；
• 每秒HTTP请求数；
• 并发连接数和新建连接速率；
• 动态请求占比；
• CPU、内存、数据库连接和队列长度；
• 主要接口的成功率、延迟和错误码。

同样是每秒几百个请求，静态页面和需要查询数据库的接口，对源站的压力可能完全不同。一个访问量不大的后台系统，如果每次请求都会触发复杂查询，也可能比高缓存命中的内容站更容易被CC拖垮。

数据单位也要统一。比如，某段时间内收到1GB数据，持续8秒，按十进制换算，平均速率为：

1GB × 8 × 1000 ÷ 8秒 = 1000Mbps

其中GB是字节单位，换算为比特需要乘以8；Mbps是每秒百万比特。带宽容量、流量计费、请求数和数据包速率不能混在一个指标里比较。

可用最近一段正常业务数据建立基线，再为短时突发预留空间。比如正常峰值为80Mbps、动态请求为每秒2000次，评估时应分别询问产品在更高带宽、更高请求速率和更高并发连接下的处理方式，而不是简单地用“80Mbps乘以某个倍数”替代完整容量评估。倍数只能作为估算，不能代替实际的业务模型。

关键约束要在购买前写清楚

以下条件会直接改变产品选择：

• 是否必须保留真实客户端IP，以及应用如何读取该信息；
• 是否使用HTTPS，证书由谁配置、续期和托管；
• 网站是否包含登录、支付、后台、API或长连接；
• 动态接口是否允许缓存，哪些路径必须直达源站；
• 是否可以修改DNS和源站访问策略；
• 是否可以隐藏或更换源站IP；
• 对额外延迟、验证码、挑战页面和误拦截的容忍度；
• 能否接受临时切换、人工介入或应急规则；
• 用户数据、日志和处理位置是否存在合规要求；
• 预算是按防护IP、带宽、清洗流量、请求量还是其他维度计算。

这些条件没有优先级时，容易出现“防护能力很大，但业务无法正常接入”的情况。例如，必须识别客户端来源的接口，如果接入后真实IP没有正确传递，原有风控和审计可能失效；必须保持长连接的业务，如果产品只适合普通短连接网页，也不应直接套用。

按攻击层选择防护能力

以CC攻击为主：先看应用层处理能力

CC防护通常位于网站请求进入源站之前，重点不是单纯吸收流量，而是区分正常访问与异常请求。需要重点确认：

• 是否支持按URL、请求方法、请求头、会话、客户端特征设置规则；
• 是否能对单IP、单账号、单接口或异常会话进行限频；
• 是否能区分静态内容和动态接口；
• 是否有缓存、挑战、验证码或延迟响应等处理方式；
• 规则误拦截后能否快速查看日志并回滚；
• 触发规则时，正常登录、支付和API请求是否会被一并拦截。

只按照IP限速通常不够。共享出口、移动网络和企业网络可能让多个正常用户使用同一个公网IP；反过来，攻击者也可能频繁更换来源地址。对于登录、搜索、提交订单等动态接口，更应关注请求频率、会话行为和接口成本。

CC防护不适合单独解决入口带宽已经被打满的场景。请求还没到达应用层就被丢弃时，WAF规则无法发挥作用。

以DDoS为主：看清洗容量和处理维度

如果主要问题是入口带宽、连接数或数据包速率异常，应重点核对网络层和传输层能力：

• 支持哪些协议和端口；
• 标称防护容量和实际可交付的清洗后业务容量分别是多少；
• 是否有每秒数据包数量、连接数或新建连接速率限制；
• 清洗后是否仍能稳定回源；
• 业务使用的端口是否在防护范围内；
• 超过约定阈值后如何通知、切换和计费；
• 攻击期间是否提供流量、协议、来源和丢弃原因等日志。

“具备很大的防护容量”不等于“源站在任何攻击下都能正常工作”。还要确认清洗后的正常流量能否承载源站、回源路径是否稳定，以及源站IP是否已经被攻击者掌握。

CC和DDoS同时出现：要求两层能力互相配合

混合攻击不能简单地把两个产品名称相加。需要确认网络层拦截和应用层规则是否处于同一接入路径，事件告警是否能关联，源站是否只接受防护层回源，以及紧急规则是否可以快速下发。

比较稳妥的判断方式是把攻击分成两个问题：

1. 大流量、异常连接或高PPS是否会在入口处被处理；
2. 仍然到达网站的请求，是否会被应用层识别、限速或隔离。

只解决第一个问题，合法格式的高频请求仍可能拖垮数据库；只解决第二个问题，入口带宽又可能先被占满。

不要把宣传参数当成验收标准

防护容量、清洗能力和业务承载不是一回事

产品页面上的“防护容量”通常用于说明能够处理的攻击规模，但选型时至少要追问三个不同指标：

• 能识别和丢弃多少攻击流量；
• 清洗后能够稳定转发多少正常业务；
• 在攻击状态下，网站的延迟、成功率和源站资源是否仍在可接受范围内。

如果只比较最大Gbps或Tbps，容易忽略PPS、并发连接、HTTP请求数和动态接口成本。对于CC攻击，几百Mbps的请求也可能造成明显影响；对于DDoS，流量不大但每秒数据包极高，同样可能消耗设备和连接资源。

计费口径必须与业务峰值对应

询价或签约前，应要求对方明确以下内容：

• 按防护IP、峰值带宽、清洗流量还是请求量计费；
• 正常流量和攻击流量是否使用同一计费口径；
• 超出约定范围后是否自动产生额外费用；
• DNS、证书、日志、规则和应急服务是否另计；
• 临时提高防护级别是否需要人工审批；
• 合同中的容量、响应时间和故障处理是否有明确边界。

没有当前价格和具体产品资料时，不宜用固定金额判断贵不贵。更合理的方式是先算出业务需要的能力，再比较单位容量、接入复杂度、额外功能和应急成本。

源站暴露会削弱前面的投入

如果攻击者可以直接访问源站IP，可能绕过域名接入的防护层。验收时应确认：

• 公网DNS、历史解析、邮件服务或其他公开信息中是否泄露源站地址；
• 源站是否只允许防护层回源；
• 直连源站时是否会暴露真实页面或接口；
• 切换前后的源站访问控制是否一致；
• 防护层传递真实客户端IP后，日志、风控和审计是否仍然正确。

隐藏源站不是一次配置完成的事项。源站地址变更、旧解析记录、测试域名和临时接口都可能重新暴露入口。

用一轮小范围验证替代纸面比较

第一步：记录业务基线

至少记录一个正常高峰周期内的带宽、请求数、连接数、接口延迟、错误率和源站资源。静态页面、动态页面、登录接口和高成本接口要分开统计。

不要用攻击期间的数据直接作为正常容量，也不要只记录平均值。短时峰值和P95、P99延迟通常比平均延迟更能反映用户体验。

第二步：核对接入后的请求链路

使用测试域名或可控业务入口进行接入验证，依次检查：

1. DNS是否解析到预期防护入口；
2. HTTPS证书和域名是否匹配；
3. 防护层是否能正确回源；
4. 源站日志中的客户端IP、请求协议和Host是否正确；
5. 静态页面、动态页面、登录和提交接口是否都能完成；
6. 源站直连是否已经被限制；
7. 防护规则命中时，日志能否定位原因。

如果只是页面能打开，但真实客户端IP丢失、接口提交失败或源站仍可直连，不能算接入成功。

第三步：验证地区和业务类型

从主要用户区域分别访问静态、动态和接口请求，记录连接时间、TLS时间、首字节时间、完整响应时间和成功率。对需要登录的页面，还要检查Cookie、跳转、验证码和会话是否正常。

如果业务存在长连接、持续请求或特殊接口，应单独确认产品是否支持，而不是以普通网页测试结果代替。

第四步：把应急流程写进验收

验收不只看“能否接入”，还要确认出现异常时谁来处理：

• 谁能添加或撤销CC规则；
• 谁能确认攻击是否达到DDoS清洗阈值；
• 告警通过什么方式发送；
• DNS或接入切换需要多久；
• 规则误拦截时如何回滚；
• 攻击结束后如何恢复正常策略；
• 日志保留多久，是否能够导出。

如需进行压力或攻击模拟，必须在明确授权、隔离环境和约定时间内完成，不能对生产网站或第三方地址自行发起测试。没有条件做攻击模拟时，可以先做链路切换、规则命中、源站限制和业务功能回归，并将攻击处理能力写入合同和验收条款。

按条件形成选择路径

如果网站用户集中在单一地区、以内容展示为主、带宽规模不大，但动态请求可能拖垮应用，应优先选择接入简单、应用层规则清晰、支持缓存和限频的防护方案，同时确认基础的流量清洗能力和源站隐藏能力。

如果网站包含登录、搜索、订单或API，重点应从“能否挡住多少流量”转向“能否保护高成本接口”。需要分别配置静态内容、普通动态页面和敏感接口的策略，并验证限频、会话识别和误拦截处理。

如果用户分布在多个地区，应按主要用户区域测试延迟和成功率，再比较防护覆盖，不要只根据总容量做决定。对于跨区域访问明显的业务，还要提前确认日志和数据处理是否满足自身要求。

如果已经出现带宽打满、连接耗尽或高PPS现象，应优先核对网络层清洗、端口范围、连接处理和超限机制；如果带宽正常但CPU、数据库和接口延迟异常，则应优先加强应用层CC防护。两类指标都异常时，选择能够同时覆盖入口流量和应用请求的组合方案，并把两层规则、回源限制和应急切换作为一个整体验收。

最后，任何防护产品都不能替代源站容量规划、接口限频和应用安全修复。产品能力应与用户地区、业务规模、攻击层级、源站改造空间和预算口径逐项对应；能先用数据确认“哪里先失效”，再按该层能力、接入路径和验收指标比较，通常比单看防护数字更不容易踩坑。