高防CDN实测：小站点低成本抵御DDoS攻击的完整方案

DDoS四个字母，听起来像是大厂才配拥有的烦恼，但实际上我见过太多小站点第一次被打就已经死透了——游戏私服、电商小程序、企业官网、直播带货页，甚至某些小工具站，一旦遭遇攻击，先不说业务中断带来的直接损失，光是客户电话和服务商那边的紧急通知就能让人焦头烂额。更现实的问题是，传统高防IP动不动就几千上万一月，对大多数中小业务来说根本背不动。

所以我一直很关注“高防CDN”这条低成本路线，这次专门用了360CDN的高防服务器功能做了一轮完整的防御实测，从接入配置、策略调优，到模拟攻击、防护复盘，整个过程都记录了下来。这篇内容不吹不黑，把实际数据、配置细节和踩坑经过都摊开讲清楚，适合那些预算有限、后端服务器带宽不高、又确实担心被打的小规模业务团队参考。

1. 为什么小站点也需要认真应对DDoS攻击

1.1 被攻击的现实场景：不只是大厂的专利

很多人有个错觉，觉得自己网站没名气、没流量，攻击者凭什么打你？我早先也这么想，直到自己一个日活两三百的小工具站无缘无故被打到宕机，才把这个问题想明白。小型站点被攻击的原因远没有想象中那么“高门槛”：可能是同行业的竞争对手在促销节点雇人打你，可能是有人想勒索，也可能是某个攻击脚本在批量扫描全网IP时顺手把你的服务器当成了靶子。

另一个容易被忽略的场景是所谓“新人练手”。网上流传的各种压力测试工具门槛极低，很多人会拿任意一个公网IP做实验。如果你的业务刚好跑在一个裸奔的服务器上，带宽被瞬间打满，CPU跑满，数据库连接耗尽，整个服务在几分钟内就会无响应。等你想起来登录服务器去看，SSH都已经连不上去了。

DDoS攻击的原理其实不复杂，本质就是用大量请求或者流量塞满你某个维度的资源。流量型攻击直接打满你的带宽，比如UDP Flood、ICMP Flood；连接型攻击打满你的并发连接数，比如SYN Flood；还有更恶心的应用层攻击，俗称CC攻击，模拟真实访客不断请求动态页面，把后端服务器的CPU和数据库拖垮。对于小站点来说，哪怕攻击流量只有几百Mbps，也足够让一台10Mbps带宽的服务器彻底瘫痪，很多香港、韩国的小带宽VPS更是几秒钟就死。

1.2 传统防御方案的账单有多贵

既然知道自己可能被打，接下来就该考虑怎么防。市面上的防御方案价格差距非常大，但总体没有便宜的。我大致整理了一下这几类常见方案的月成本，你们感受一下：

从这张表可以明显看出，高防IP和云高防包的门槛相对较高，小站点很难消化。而高防CDN这类产品把“防护能力”和“CDN分发”打包在一起，按域名接入，按套餐付费，几十块钱就能有一个基础防护档位，大部分普通站点只要不是被超大流量盯上，基本够用。

这也是我选择360CDN做实测的原因：它有免费档和极低价格的入门档，同时防护能力去到了比较高的水位。如果它的实际防护效果能扛住中小规模攻击，那对预算有限的团队来说，这几乎是最平滑的DDoS防御起点。

2. 360CDN高防的选型逻辑与核心能力梳理

2.1 高防CDN和传统高防IP的本质区别

决定用什么方案之前，要先想明白高防CDN和高防IP到底有什么不同。简单说，高防IP是把你的业务IP直接换成高防节点IP，所有流量先经过清洗机房，洗掉攻击流量后再回源到你的服务器；而高防CDN是让用户访问的不是你的源站IP，而是遍布全国的CDN边缘节点，攻击者看到的只是一个又一个CDN节点IP。

高防CDN有一个天然优势——你的源站IP藏得住。很多DDoS打不死你，是因为攻击者根本不知道你真正的服务器在哪，他能打到的只是CDN的缓存节点，而CDN节点本身就是海量带宽和防御能力堆积起来的。相比之下，如果用了高防IP但源站IP泄露了，攻击者直接绕过高防打源站，那高防IP再强也白搭。

当然，高防CDN也不是万能的。它对TCP四层协议的防护能力通常弱于专用高防IP，擅长的是Web七层业务。如果你的业务主要是网站、接口、下载站这种走HTTP/HTTPS的流量，那高防CDN的性价比就非常高；如果业务是游戏长连接、自定义TCP协议这类，那还是老老实实买高防IP更合适。

2.2 360CDN的防护链路是怎么工作的

360CDN的防护链路大体可以拆成四步。第一步，通过DNS把用户域名解析到最近的CDN节点；第二步，节点上的流量清洗模块对进来的每个包做检测，能识别的攻击流量直接被丢弃或者限速；第三步，正常请求按CDN逻辑做缓存，命中的请求直接由节点返回；第四步，未命中的请求转发到源站，同时做好源站IP的隐藏。

这套逻辑里有一个容易被忽略的点：高防CDN的节点天然是“分布式”的。攻击者就算打掉一个节点，DNS轮询和智能调度会很快把流量切换到其他节点，单点被打穿的风险比自建防御低得多。360CDN本身的防护能力在节点层面做了冗余，而且你还可以给每条规则单独设置黑名单、白名单、区域封禁、访问频率限制，这些策略组合起来就是一套非常灵活的微型WAF。

我特别喜欢它的“分钟级生效”特性。以前用某厂商的高防IP，改一次源站IP要等审批、等下发，半天过去业务可能已经被打瘫了。360CDN这边直接在控制台改防护策略或者切换回源配置，基本几分钟内就能生效，这对应急场景来说太重要了。

3. 从零接入：域名配置和防护策略落地

3.1 控制台添加域名与套餐选择

360CDN的接入流程和我用过的大多数CDN产品类似，但不熟悉的人第一次操作还是会踩一些坑。这里我按实际顺序走一遍，你照着做基本不会出大问题。

先登录控制台，在“域名管理”里点“添加域名”。这里有几个必填项：主域名、加速域名（就是你要接CDN的二级域名）、业务类型（一般选网页加速或下载加速）、源站类型（IP源站还是OSS源站）。如果是普通网站，源站IP填你服务器的公网IP就行，端口默认80或443可以单独改。

套餐选择上，免费档和付费档差异挺大。免费档适合只想要CDN缓存加速、不追求高防能力的个人站点；如果你正经担心DDoS，建议直接跳过免费档，选带防护峰值的付费档。为什么？因为我实测过免费档在攻击时会被快速“黑洞”，也就是直接用丢弃所有流量来保护节点，业务直接不可用，虽然能帮你挡住攻击，但业务也“死”了，这不叫防御。付费档才能保证攻击时正常用户仍然可以访问。

选完套餐后，我强烈建议你把“回源方式”设置成“跟随协议”。什么意思？如果用户用HTTPS访问，CDN节点回源时也用HTTPS；如果用户用HTTP，节点回源也用HTTP。这样能避免因协议不匹配导致的混合内容报错。如果你源站同时支持HTTP和HTTPS，这个配置最省心。

3.2 DNS切换与HTTPS证书处理

域名添加完成后，控制台会给你一个CNAME地址，比如 xxxx.360cdn.com 之类。这时候要去你域名的DNS服务商后台，把你原本的A记录改成一个CNAME记录，指向这个地址。

这里有两个特别注意的地方。第一，切换前最好把DNS的TTL值调小，改成600秒甚至300秒，这样等切换完成后可以快速生效，不用干等原来的缓存过期。第二，切换完成后不要马上删掉原来的A记录，保留至少一天观察期，万一需要回滚还能快速切回去。

HTTPS证书是另一个高频翻车点。如果你源站用了自签名证书，那CDN节点回源时默认会校验失败。最稳妥的方法是直接在360CDN控制台上传你域名的SSL证书，让CDN节点对外提供HTTPS服务，回源到源站时再走HTTP，这样可以减少源站证书配置的麻烦。如果没有现成证书，控制台通常也支持自动申请免费证书，我实测下来申请和部署的速度都很快，基本几分钟搞定。

3.3 防护规则与安全策略设置

域名接入完成、网站能正常访问后，真正决定防御效果的是安全策略配置。很多人以为接入CDN就等于万事大吉，结果被打的时候发现没有什么防护效果，十有八九是默认策略太宽松。

我这次在360CDN上重点调了四类策略。第一是 CC攻击防护，也就是频率限制。先观察正常访客的平均请求频率，然后把单IP的访问频率阈值设置成比正常值稍高一点，比如60次/分钟，超过就触发验证码或直接拦截。这个阈值别拍脑袋定，定得太低会误伤正常用户，定得太高又等于没防护。

第二是 区域封禁。如果你的业务根本不面向海外用户，那直接把海外区域都封了，能过滤掉相当一部分来自境外IP的攻击流量。实测下来这一个策略就能让攻击量级小一大截，毕竟很多打流量的傀儡机都在海外。

第三是 黑白名单。把自己常用办公网段的IP加入白名单，把发现的恶意IP加入黑名单，属于基本功。黑名单我一般是攻击发生过程中实时添加的，看到某个IP在攻击日志里频繁出现，直接封掉。

第四是 源站IP保护。这是最关键的一步，却最容易被忽略。CDN节点回源时需要知道你的源站IP，于是有人就会想办法扫这个IP。我习惯把源站服务器的安全组或防火墙设置成“只允许CDN回源IP段访问80/443端口”，其他IP全部拒绝。这样就算攻击者扫描全网IP，也无法直接访问到你的源站，DDoS防护才有意义。

4. 实测过程：从模拟攻击到防护效果复盘

4.1 测试环境与压测工具的合法前提

实战之前先明确一点：DDoS攻击测试是有法律风险的，随便拿别人的站点做压测属于违法行为。我这里做的实验全部是在 自己的测试服务器、自己控制的域名 上进行的，并且明确告知了服务器提供商相关测试计划。你在复现这个实验的时候，也一定要在完全属于自己的环境里操作，不要对任何第三方IP做压力测试。

我准备的测试环境是这样的：源站是一台位于香港的2核4G VPS，带宽10Mbps；域名已经接入360CDN付费档，防护阈值配置为2Gbps；测试机是一台在同一机房的独立服务器，带宽充足。这样能保证攻击流量从测试机打出来，经由公网到达CDN节点，完整走过真实的攻击链路。

工具方面，我分别准备了流量型攻击工具（用于模拟UDP Flood、ICMP Flood）和应用层攻击工具（用于模拟HTTP Flood，也就是CC攻击）。命令行下使用hping3做流量型模拟，配合ab和wrk做七层压力测试。这些工具都非常经典，网上有大量使用教程，我这里就不贴具体攻击命令了，防护测试的重点本来也不在攻击手法上。

4.2 第一轮：流量型DDoS攻击的实测数据

第一轮测试模拟的是最常见的流量型攻击，目标是把CDN节点的入向带宽打满。我从测试机持续向CDN节点的IP发送大流量UDP包，攻击流量从100Mbps逐步提升到500Mbps，每一档持续10分钟。同时，我从另一台测试机持续向目标域名发起正常的HTTPS请求，以此监控业务的可用性。

结果让我比较意外：在攻击流量达到200Mbps时，业务完全无感知，页面打开速度和攻击前基本一致。这是CDN节点做了流量清洗的结果，正常的HTTP请求被放行，UDP洪水流量在清洗设备上被直接丢掉，根本不会影响到上层业务。

攻击流量继续加码到500Mbps时，页面打开速度稍微出现了一点延迟，大概从原来的200毫秒增加到350毫秒左右，但页面仍然能正常打开，没有出现超时或502错误。这说明在这个量级下，360CDN的节点处理能力还有很大余量。我又尝试把流量加到了1Gbps以上，终于开始出现少量请求超时，但整体可用性仍然维持在95%以上，没有被彻底打瘫。

这个结果印证了我的判断：对于大多数小站点遭遇的几百Mbps级别的流量型攻击，高防CDN完全可以扛住，前提是你的套餐防护峰值没有被打穿。而且要注意，如果攻击真的超过套餐峰值，CDN会触发黑洞策略来保护自身节点，这时候业务会中断，属于“保命”机制，等攻击结束会自动恢复。

4.3 第二轮：CC攻击测试与频率限制策略调整

流量型攻击扛住了，更麻烦的CC攻击才是分水岭。CC攻击模拟真实访客请求，每个请求看起来都很正常，如果防护规则不够智能，很难区分正常流量和攻击流量。

这一轮我直接用wrk构造了大量并发HTTP请求去请求源站的一个动态页面，试图把后端服务器CPU打满。为了模拟“不同IP”的分布式攻击效果，我在测试机上轮换使用了多个出口IP进行压测，尽量贴近真实的攻击形态。

在默认防护策略下，CC攻击的效果相当明显。当并发请求数超过2000时，源站服务器CPU瞬间飙到90%以上，页面响应时间从几百毫秒恶化到十几秒，部分请求直接超时。这说明如果不开防护规则，单纯靠高防CDN的快缓存，防不了针对动态路径的CC攻击。

随后我在控制台开启了CC攻击防护，将单IP频率限制设置为每分钟60次，并开启了“人机验证”模式。再次发动同样的攻击，效果截然不同：节点层就将高频请求拦截在源站之外，源站CPU直接从90%以上回落到15%左右，页面响应时间恢复到了500毫秒以内。

这里要额外说一句，CC防护阈值不是设得越低越好。我一开始把频率限制设置成每分钟10次，结果我自己测试的时候都被节点拦截了，更别说正常访客。后来调整到60次/分钟，再配合人机验证，才算既挡住了攻击又不误伤用户。这个阈值跟业务类型强相关，比如API接口类业务可能单IP每分钟请求几百次都算正常，但普通浏览网页60次已经非常够用，实际调优时一定要根据自己的访问日志来确定。

4.4 实时观测与攻击识别方法

测试过程中，我一直在用360CDN控制台的实时监控看流量曲线和安全事件日志。这里分享几个判断“是否正在被攻击”的实用方法，比等用户投诉要快得多。

第一，看CDN控制台的监控图表。正常情况下流量曲线是平滑的，一旦出现陡峭的尖峰，特别是入向带宽在几分钟内翻了十几倍，基本可以断定正在被流量型攻击。第二，看源站服务器的入向流量。即使CDN帮你在边缘清洗了大部分流量，如果攻击量级特别大，仍然会有一部分异常流量渗透到源站层面，此时源站带宽监控会有明显异常。第三，看访问日志的IP分布。如果同一时间点有大量不同IP在疯狂请求同一个URL，或者User-Agent高度相似，极大概率是CC攻击。

我在攻击测试过程中就发现，攻击开始时360CDN的安全事件页面会实时弹出攻击告警，包含攻击类型、攻击流量峰值、被攻击的域名等信息，响应速度比我预期的快很多。这个功能在真实业务场景里非常关键——第一时间确认攻击来源，才能快速做出应对决策。

5. 常见问题与排查技巧实录

5.1 误封正常访客怎么办

这是开启CC防护之后最容易被骂的场景。明明攻击没来，但有些地区用户反馈“网站打不开，出现验证码，输了还是打不开”。我的经验是：先看被拦的IP是不是集中在某个区域，如果是某些地区运营商出口IP集中被误拦，大概率是频率阈值设置过低导致公共出口IP被整体封禁。

处理思路是，把正常业务动态路径从频率限制中排除，只对高风险路径做严格限制。比如登录接口、搜索接口这类容易被刷的路径，可以设置更严的阈值；而首页、文章详情页这种静态或半静态路径，可以放宽限制甚至直接放行。另外，人机验证模式比直接拦截友好一些，误杀情况会少很多，但需要访客多一次交互，看业务接受度。

5.2 回源失败和502错误

接入CDN后如果出现大面积502，首先要排查的是回源链路。我踩过的一个坑是：源站服务器安全组只允许CDN回源IP段访问HTTP端口，但因为CDN回源IP段不止一个来源，有些回源请求走了IPv6而不是IPv4，我忘记放行IPv6地址，结果导致部分节点回源失败，表现为时好时坏的502。

如果你的源站也在CDN控制台配置了白名单策略，一定要同时放行IPv4和IPv6的回源IP段。还有一个常见原因是源站SSL证书和CDN回源协议不匹配。比如CDN设置为HTTPS回源，但源站证书已经过期，回源时证书校验失败，节点就无法获取内容，也会表现成502。这种情况下最简单的办法是改回源方式为HTTP，或者在源站更新并部署有效证书。

5.3 缓存和动态内容冲突

高防CDN本质上有CDN缓存功能，这就会带来一个不可避免的问题——动态内容被错误缓存，导致用户看到的数据不一致。比如登录状态、购物车数量、验证码这些动态接口，如果被节点缓存，就会出现用户明明登录了却显示未登录的诡异情况。

解决办法很直接：在加速配置中设置动态资源不缓存，或者在源站返回的HTTP响应头中增加Cache-Control: no-cache和Set-Cookie标识，CDN节点会依据这些响应头判断是否应该缓存。实测下来，360CDN对这类响应头是能识别的，不需要额外做复杂配置。但一定要记得，不要为了“加速”把所有路径都强制缓存，动态接口的实时性比那一点点加速收益重要得多。

5.4 攻击峰值超过套餐怎么办

最担心的情况还是发生了——攻击流量超过了套餐防护峰值，CDN直接触发黑洞，业务全站不可用。发生这种情况时我的建议是：不要慌着去升级套餐，而是先在控制台确认黑洞解除时间，同时判断攻击是否还在持续。

如果攻击已经结束，黑洞会自动解除，业务几分钟内就会恢复。如果攻击还在持续并已经超过当前套餐峰值，那只能临时升级套餐，或者在DNS层面临时把业务切到备用源站，配合其他防护手段过渡。对于小站点来说，平时就要准备一个低配的备用源站，攻击峰值超过防护能力时至少还有个退路，不至于完全裸奔。

5.5 常见问题速查表

写在最后的几点体会

测试完整套方案，我个人最大的感受是：高防CDN并不是万能的，但它确实是中小业务抵御DDoS最务实的性价比方案。流量型攻击在节点层就能被稀释和清洗，CC攻击靠频率限制和智能验证也能有效拦截，整体配置门槛比自建高防低太多，成本更是比直接买高防IP便宜了一个量级。

但有几个边界要认清。高防CDN擅长的是Web业务，游戏、邮箱、API长连接这类非HTTP业务并不适合；源站IP的保密是所有防护的基础，一旦源站泄露，防护效果直接打对折；CC防护规则需要根据自己业务的流量特征做精细调优，不能一套默认配置走天下。

最后再分享一个小技巧：接好CDN之后，一定要定期做一次“攻击演练”。和平时期挑一个低峰时段，自己制造一次小规模攻击，把CDN监控、告警、回源保护、黑洞恢复这些环节全部走一遍。我这次实测最大的收获不是最终数据多好看，而是对整个防御链路有了底，知道什么时候该看什么数据、出了故障从哪里排查。真要等攻击来了才第一次操作，大概率会手忙脚乱。现在的互联网环境谁都无法保证自己永远不会被打，提前跑通这套流程，至少被打的时候心里不慌，知道怎么做才能把损失降到最低。