CDN防攻击，3个配置先做对

被 CC 打得最狠的那一回，救命的不是 WAF 规则，是回源 IP 白名单——攻击流量在 CDN 边缘堆成小山，源站只认从节点过来的连接，页面照样能打开。cdn防攻击这件事的核心从来不是把攻击挡在门口，而是让它根本摸不到你的服务器。拉黑、人机校验、加规则当然要做，但那都是后面的事；最底下这几处配置没摆正，上面加多少条规则都是漏斗。

cdn防攻击第一件事：回源设限，别让源站裸奔

源站 IP 是怎么漏出去的？DNS 历史解析记录、证书透明度日志、邮件头里的 Received 字段、某个忘了关的子域名，随便哪个都能翻出来。所以接上 CDN 之后，源站的安全组或者本机防火墙就得把口子收起来，只放行服务商给的回源 IP 段——具体是哪些段，以服务商控制台的列表为准，各家不一样，别照抄网上那些老帖子。同时回源这一路最好带个鉴权，自定义请求头里放一个私有密钥、或者用回源鉴权，都行，让源站能确认这个请求确实是从自己的 CDN 过来的。还有一处特别容易漏：源站必须校验 Host。不校验的话，攻击者拿着 IP 直接访问 80 或 443 端口一样打得进来，CDN 等于白接一层。

限速不是越狠越好，正常用户会先被打死

CC 攻击最麻烦的地方在于它长得跟真人一样。你把单个 IP 的频率限制压到一个正常用户都碰不到的数，结果通常是自己人先遭殃：登录点半天没反应、表单提交失败、下单卡在验证环节。合理的拆法是按路径分——登录、注册、搜索、支付回调这些敏感接口单独设一条规则，静态资源和详情页放宽一些；判定维度也别只盯着 IP，企业出口和移动网络共享 IP 的情况太普遍了，IP、会话、UA 和请求特征一起看才不至于一竿子打一片。阈值定多少没有标准答案，先跑几天日志，把正常峰值的上限摸出来，再往上留一点余量。人机校验也别全站铺，挂在登录和提交这两个口子上就够，铺满了柔性很差，被卡的还是真人。

源站端口和协议，也属于防攻击的一部分

CDN 回源走哪个协议、哪个端口，最好固定下来。源站除了 80 和 443，其余测试端口、管理端口一律别对公网开着，有些站点图省事把 8080、宝塔面板的端口都留着，CDN 配得再规整也架不住从旁边绕进去。回源协议也要和服务商对齐，该全站 HTTPS 就全站 HTTPS，别一半一半的，否则个别路径会掉到明文回源上。这类事情技术上并不复杂，但它决定了前面那些配置到底算不算数。

缓存也在干活，别只当它是加速手段

攻击打静态页的时候，缓存命中率高的一方回源压力小得肉眼可见。所以静态资源的 TTL 尽量拉长，图片、CSS、JS 这类东西实在没必要几分钟就回一次源。缓存键要留神——默认把 cookie 全带进缓存键，命中率基本归零，每个请求都回源，等于花 CDN 的钱干反向代理的活，攻击一来源站先顶不住。带登录态的页面不能进公共缓存，但也不代表整个站都得排除，按业务分一下就好。另外回源带宽要单独看：总带宽没怎么涨、回源带宽却突然蹿上去，多半是缓存被穿透了，不是业务真涨了。

日志和告警，别等打穿了才回头看

带宽曲线在夜里突然竖起一根针、5xx 比例往上跳、回源带宽占比异常，这几个信号比任何告警文案都灵。至少把 CDN 的边缘带宽、回源带宽、状态码分布、单条 URL 请求次数做成一个面板，阈值到了推一条消息出来。成本不高，真出事的时候能省下一整夜。再提一句，CDN 日志的字段定义各家差异不小，X-Forwarded-For 里的取值方式先查服务商文档，不然你以为拿到了真实客户端 IP，其实拿到的是上一层节点的地址，限速规则照着这个设，很容易把自己人拦了。

几种越配越危险的反向操作

把源站 IP 写在页面的联系方式里、顺手忘记在邮件签名里；接上 CDN 就以为源站可以不打补丁；一被打就换 IP，换完又在新站上暴露一遍；只看总请求数，不看单条 URL 和单个 IP 的分布。这几样事儿我都见过，一个比一个省事，也一个比一个不顶用。反过来，源站加固那些老活儿别停——该关的服务关掉、该打的补丁打上、该改的默认密码改掉，CDN 是件外套，不是铠甲。

先分清攻击类型，配置才不会南辕北辙

流量型的 DDoS 靠的是 CDN 节点本身的带宽和清洗能力，这部分你能动的其实不多，选服务的时候看清洗能力和回源线路；应用层的 CC 靠的是限速、规则和缓存，这才是自己能动手的地方。两类混在一起谈，很容易在不该使劲的地方使劲——比如洪峰都打过来了，还在一条一条改限速规则，改到天亮也拦不住。

真要给个动手顺序：先把源站的口子收掉，再把敏感接口的频率限制摸出来，然后才是缓存和日志补齐，顺序反了力气就白花。上线前找台机器从外网直接访问你的源站 IP，还能打开，就说明这活还没干完。