先聊个现象很多时候网站突然打不开CPU和数据库负载莫名其妙飙满查了服务器日志发现一堆刷不完的请求而且这些请求看起来还都有模有样不是那种明显来砸场子的洪水包。如果你经历过这种场面大概率碰上的就是CC攻击。我自己在做站点运维的时候就遇到过凌晨三点被CC打趴的情况那会儿还没上高防CDN只能临时加规则、封IP折腾一晚上第二天才慢慢恢复。后来把架构改成了高防CDN前置处理CC攻击这件事才算是真正从“被动挨打”变成了“主动防御”。这篇文章就从高防CDN怎么防CC攻击这个角度把原理、配置、参数调优和踩坑经验一次说清楚。适合自己管服务器、用过高防产品但没有系统理解CC防护逻辑的同学参考也适合正在纠结要不要上高防CDN的朋友做一个决策参考。我会尽量把“为什么这样配置”讲透而不只是告诉你“该在哪里打个勾”。1. CC攻击为什么这么难防1.1 CC和DDoS的根本区别DDoS攻击尤其是四层流量型攻击主要把带宽和连接数打满本质是“我用大水管冲垮你”。你服务器再快带宽就那么宽请求进不来服务自然就停了。CC攻击不一样它模拟的是正常用户的HTTP请求比如打开网页、提交搜索、调用接口。攻击者用很小的带宽就能发起大量合法的业务请求让服务器把资源消耗在处理这些“真实”的请求上。放大了说这类攻击玩的不是量级而是“演技”。打个比方DDoS是往你家门口倒垃圾垃圾多到你出不了门CC则是让一大批人假装排队进店人手一部手机进来后只看不买把店员、收银台、空调全部占满真正想消费的顾客进不来店内服务也瘫痪了。这个比喻基本能解释为什么CC攻击让很多站长头疼。1.2 为什么普通防火墙和高防IP搞不定CC普通防火墙无论是硬件还是软件主要工作在四层以下看的是IP、端口、协议类型。而CC攻击的特征在七层也就是HTTP协议层。如果请求本身是合法的HTTP请求四层防火墙几乎不会拦截因为从TCP连接看它和正常用户没有任何区别。高防IP主要防的是大流量DDoS它靠的是超大带宽和流量清洗来扛量。但面对CC攻击高防IP的短板就出来了攻击流量从带宽角度看不明显清洗设备很难识别哪些是恶意请求误杀率和对真实业务的流量干扰往往是两难。这里说明一下高防IP不是完全不能防CC而是它在CC防护上的效果远不如高防CDN。原因在于高防IP通常只做流量清洗不做业务层协议解析而高防CDN在前面加了一层完整的反向代理可以深入到HTTP层做行为分析。1.3 CC攻击为什么成本低、威力大CC攻击的核心成本在于“发起请求”而HTTP请求本身极其廉价。哪怕一个普通的云主机也能轻松发起每秒几千个请求用几十台机器组成的“僵尸网络”就更不用说了。加上现在很多攻击工具把代理池、指纹随机化、请求头伪装都做成了标配攻击者不需要多少技术门槛就能打出很漂亮的CC效果。更麻烦的是CC攻击经常是“慢速攻击”和“高频攻击”混着来。慢速攻击Slowloris这类会把连接占住不放让服务器的并发连接数被吃满高频攻击则是短时间大量请求打爆应用逻辑。两者混在一起单纯靠限流、封IP这类基础手段很难一次防干净。2. 高防CDN防住CC攻击的底层逻辑高防CDN和普通CDN的区别不只是多了一个“高防”标签。它最大的不同在于节点本身就是抗DDoS的硬体节点同时在每个节点上都内置了应用层防护模块而普通CDN的所有流量还是会照常回源只做内容加速。可以说高防CDN防CC的核心思路只有一句话让攻击流量根本到不了源站。这句话听起来简单但真正做到位需要一套完整的技术闭环。2.1 DNS智能调度把用户流量引到最近最干净的节点高防CDN通过DNS把用户请求解析到离用户最近的边缘节点。这个过程对用户无感知但带来了三层好处第一正常用户访问延迟更低加速效果更明显第二所有请求先经过边缘节点源站IP被隐藏第三攻击者攻击的目标变成了CDN边缘节点而高防CDN的节点本身能扛大量DDoS清洗不会轻易被打瘫。这里有一个非常核心的点源站IP一旦暴露攻击者可以直接绕过CDN把攻击流量直接打到源站IP上。后面第三节我会专门讲怎么避免这个情况这里先记住高防CDN防CC的第一个前提是“所有流量必须走CDN源站不能被发现”。2.2 边缘节点的应用层清洗七层请求分析高防CDN每个节点上都有七层防护引擎它会做下面这些事解析HTTP头部、Cookie、User-Agent、Referer等字段和正常浏览器的行为特征做比对统计每个IP在单位时间内的请求数、并发连接数、点击频率、访问路径对可疑请求执行JavaScript挑战JS Challenge验证客户端是不是真实的浏览器对命中阈值或特征异常的请求直接丢弃或返回503/403状态码整个分析过程在边缘节点本机完成不需要回源所以即使攻击流量再大也不会消耗源站的资源。这一点非常关键很多没上高防CDN的网站被CC打挂本质上是清洗和回源混在一起攻击流量进来后还得源站处理一轮才能被识别。2.3 浏览器指纹和人机识别区分真实用户和脚本脚本发起的请求和真实浏览器最大的区别不在于频率而在于行为特征。真实用户访问网页时浏览器会加载HTML、CSS、JS、图片并且有先后顺序、间隔和并发限制。而攻击脚本通常只请求目标URL不带静态资源不执行JS请求头里的顺序也和真实浏览器不同。高防CDN会在用户第一次访问时下发一段静默JS让“浏览器”计算一个签名并附带在后续请求的Cookie里。如果客户端能正确执行这段JS并返回签名就认为是真实浏览器反之则直接拦截。这个过程完全静默正常用户无感知但攻击脚本要模拟就需要额外写代码攻击成本成倍上升。2.4 回源保护和链路安全不让源站暴露是关键高防CDN具有隐藏源站的作用但也依赖配置正确。如果源站没绑定CDN的HTTPS证书、回源模式的配置不对、或者服务器上错误地开放了非CDN端口攻击者还是能通过扫描历史DNS记录、解析SSL证书、抓包等方式找到源站IP。所以在第三节里我会重点讲“高防CDN正确接入方式”这部分不是可选项是保证CC防护有效的硬前提。3. 高防CDN防CC的实战配置从接入到规则调优以我实际用过的高防CDN配置来举例一般流程都是一样的只是控制台的位置和名称可能略有不同。核心配置集中在三个地方加速域名/回源配置、CC防护策略、封禁与限速规则。3.1 第一步正确接入高防CDN在DNS服务商处把域名解析改到高防CDN提供的CNAME地址在高防CDN控制台添加域名配置源站地址源站IP或源站域名配置回源方式建议使用域名回源不要暴露源站IP段在源站服务器上仅允许来自CDN节点IP段高防CDN服务商提供IP列表的访问把其他来源请求一概拒绝这里单独强调一下回源端口。很多人在源站上用的是默认80/443端口然后安全组只放行了80/443但是攻击者也可以通过43端口的非标准回源方式做探测。更稳妥的做法是源站服务器监听非默认端口比如8080然后在CDN控制台配置回源端口为8080。这样即使源站IP暴露直接访问80/443端口的请求也进不来。3.2 第二步设置CC防护策略高防CDN控制台的CC防护一般包含以下核心参数不同服务商叫法略有区别但含义基本一致策略项推荐初始值配置说明IP访问频率限制单IP每秒5个请求适用于普通网页站API站点可适当放宽到10-20IP连接数限制单IP并发连接数不超过50防止Slowloris类慢速连接攻击全局QPS阈值根据业务峰值评估阈值不能太低否则会误伤大促等正常峰谷流量验证码触发阈值单IP每分钟超过30次请求时触发触发阈值要低于封禁阈值形成梯度封禁时长初次封禁10-30分钟后续可自动叠加比如30分钟→1小时→24小时URL白名单静态资源、公开接口避免验证码误伤图片加载、公共API等场景这些参数需要根据业务特征去调不要照抄默认值。我第一次配置的时候直接用了服务商默认的“严格模式”结果第二天业务侧就反馈说有一批用户的验证码弹个不停后来查了才知道是默认阈值对老用户不友好。任何安全策略都要减少对正常用户的打扰这是高防CDN配置的第一原则。3.3 第三步配置人机验证策略针对不同的攻击特征高防CDN通常提供了多种验证手段静默JS验证用户第一次访问时下发JS脚本自动验证成功后就正常放行全程无感。这项默认开启即可。滑块验证当风险等级较高时触发需要用户拖动滑块完成验证。适合登录、注册等高价值业务页面。无感验证/Cookie校验通过下发带签名的Cookie后续访问自动带上适合App内WebView或小程序Web页等不方便做滑块场景。实际使用下来建议把验证策略设置成“梯度”正常用户无感通过可疑用户弹滑块或验证码恶意用户直接封禁。这种机制比“一刀切全部验证”体验好很多而且对攻击者的威慑也更明显。3.4 第四步自定义封禁规则除了基础的频率限制和验证码自定义规则做精准封禁也很重要。我自己常用的几类规则地理区域封锁如果业务只面向大陆用户直接封掉海外区域。很多攻击机群在境外区域封锁可以省掉大量防护资源。IP段封锁在攻击高峰期如果发现某个IP段比如/24的恶意特征特别明显可以手动封禁一段时间。URL级限速针对登录接口、短信验证码接口、查询接口这类会被刷的URL单独限速不影响其他URL的访问速度。HTTP特征封禁针对某个特定的User-Agent、特定的请求头组合做拦截。顺带说一句不要迷信服务商提供的“AI智能防护”功能。AI模型能识别大部分攻击但面对新型变种依然有滞后性自定义规则虽然要花时间维护但胜在精准和可控。两者结合才是效率最高的打法。4. 常见问题与排查技巧实录4.1 攻击绕过CDN直接打源站怎么排查上高防CDN后如果源站还是被打第一时间不要怀疑“CDN没用”而是检查源站是不是暴露了。排查思路按顺序来在源站服务器上用netstat或ss查看当前连接的来源IP如果大量连接不是来自CDN节点IP段说明有人绕过CDN直连了源站。检查DNS历史记录用在线工具查询域名的历史解析IP如果暴露过IP建议更换源站IP并确保CDN优先接入。检查SSL证书很多站点证书直接包含了源站域名/IP信息攻击者可以通过证书透明日志反查历史IP。检查源站是否有其他子域名没有经过CDN比如mail.example.com、direct.example.com这类记录都有可能泄露源站IP。找到暴露路径后修复手段有三件套换IP、全站接入CDN、源站安全组只放行CDN回源IP段。这套做完基本能堵住90%以上的绕过风险。4.2 业务正常但有一部分用户被误杀被误杀的情况多半出在动态IP环境下。比如某些用户用的是运营商出口NAT IP同一个出口IP可能同时有几百个用户在线单IP频率限制如果设置太低会把整个小区的用户全封了。遇到这种情况我的处理经验是先看误杀IP访问的URL列表。如果集中在首页、图片这样的静态内容就说明频率限制太严如果集中在搜索、筛选、登录这类动态接口那就属于业务接口自身容易触发高频访问针对性调宽URL白名单更合理。另外对拨号用户、企业专线用户的处理可以开启“IP信誉库”白名单这类IP段一般比较固定且信用分高直接跳过频率检测也能降低误杀率。4.3 动态接口被CC后恢复缓慢很多站长的认知是“动态接口不好做CDN缓存”一遇到CC就完全交给防护策略去扛。这种做法有问题。因为动态接口确实不能缓存数据但一般都可以做“缓存空结果”或“降级响应”。比如某个查询接口被刷完全可以配置一个静态化的默认返回结果当接口负载超过阈值时直接返回默认数据而不是将压力继续打到源站。这个思路虽然不属于高防CDN默认功能但在高防CDN里可以通过规则引擎实现对特定URL配置“返回固定响应”当触发CC策略后自动生效相当于给源站加了一层熔断保护。这样做的好处是即使攻击流量直接被CDN清洗也不需要源站承担任何额外计算。4.4 WebSocket和API长连接被误杀如果站点使用了WebSocket或长轮询高频的请求方式和普通HTTP完全不同标准CC防护策略默认会把这些连接判定为异常。我遇到过两三次这类情况处理方法是到控制台单独配置协议类型白名单对WebSocket路径不启用HTTP层频率限制启用独立的“连接数限制”去控制。如果没有这项配置那就考虑把WebSocket服务单独拆到另一个域名不走高防CDN的HTTP防护策略。4.5 高防CDN节点被攻击但服务没断源站却被拖垮了出现这种情况大概率是因为“回源请求量”过大。攻击流量虽然被CDN拦截但如果正常用户的流量也很大或者攻击策略比较聪明地只打CDN的某个回源IP源站承受的回源压力依然不小。这种情况从两个方向去解决一是开启CDN的“回源限速”或“回源并发限制”让节点到源站的请求数控制在一个安全水位二是开启源站侧的并发限制和队列超时机制宁可服务降级也不让整个进程崩溃。5. 两个容易忽略的细节5.1 关于HTTPS证书的配置细节如果站点开启了HTTPS高防CDN的证书配置有一个常见陷阱回源证书与客户端证书不一致导致连接失败或者源站没有配置CDN的CA证书导致回源握手失败。处理方式是先在CDN控制台上传或申请证书然后在源站配置回源证书信任。多试几台服务器你就能感受到这类问题排查起来真的非常耗时配置前先把证书链路理清楚能省很多时间。5.2 关于防护策略生效时间的观察修改CC防护策略后不会立刻100%生效代理节点同步配置一般需要几十秒到几分钟。大促前临时调高阈值一定要提前做变更不要在流量高峰期改来改去。另外每次调整后要观察一段时间的误杀率不要盲目堆严。做CC防护这么久我个人最大的体会是高防CDN解决的是“流量进不来”和“恶意流量被识别”这两层问题但它不是万能保险。业务侧也要配合做优化比如接口缓存、异步处理、降级方案、数据库连接池限制。我见过太多人把全部希望押在不封源站IP或只靠CDN的策略上结果在复杂攻击下还是被穿了。正确的姿势是高防CDN做第一层防线源站做第二层兜底两边都配置好才能真正应对CC攻击的各种变种。上面这些配置方法和排查思路都比较直接拿你现有的高防CDN控制台对照着调一遍绝大多数问题都能在半小时内解决。