我用一套自建鉴权规则，把 CDN 盗刷流量砍掉了 65%
背景
一个月前，我发现站点的 CDN 流量异常。
不是那种一眼能看出的暴涨，而是每天稳定在 8-12 GB 的“温水煮青蛙”式消耗，持续了整整 17 天。国内某 CDN 厂商后台的 AI 分析报告写得很清楚：连续 17 天、每天固定一批 IP、请求量稳定、UA 每日轮换、Referer 全部为空。
但该厂商的“自动防盗刷”在整整 17 天里，一次都没有拦截。它拦住了一些无关紧要的图片小文件，真正的盗刷流量，它视而不见。
问客服，客服让我“自己配黑名单”。
厂商为什么解决不了
后来我想明白了，这不是某一家厂商的能力问题，而是模式问题。
第一，厂商的防护是通用的，而攻击是定向的。
CDN 厂商面对的是几百万客户，它只能做“一刀切”的通用规则：IP 信誉库、UA 黑名单、频率阈值。这些规则对大规模、低门槛的攻击有效，但面对小批量、持续性、有针对性的盗刷，它识别不了——因为一旦把阈值调低，就会误伤海量正常客户。厂商不敢这么做。
第二，特征库永远滞后于攻击。
厂商的自动防护依赖“高危 IP 特征库”，而特征库的更新逻辑是：先有人被攻击，再有特征被提取，然后才能拦截。你的站点是第一批被攻击的，你的攻击特征还没进库，厂商自然拦不住。等你被刷了 17 天，特征可能刚进库——但攻击者已经换了一批 IP。
第三，厂商和你的利益并不完全一致。
CDN 按流量计费。盗刷产生的流量，在账单上看起来和正常流量一模一样。在人工介入之前，厂商没有动力主动识别并拦截——因为每拦掉 1GB 盗刷流量，厂商就少收 1GB 的钱。这不是阴谋论，这是商业模式决定的。厂商会提供工具，但不会替你承担识别的责任。
第四，厂商不敢做“确定性判断”。
真正有效的防护，往往来自只有你知道的业务常识。比如“正常用户的 Referer 不可能是资源 URL 本身”——这个判断，你一眼就能看出，因为它违背了你对业务的理解。但厂商不知道你的业务，它不敢下这个判断，因为万一误伤了某个合法场景，就是事故。
所以，厂商的“自动防护”注定只能做到通用防护的下限。 真正的防护，必须由你自己来做。
我做了什么
我在 CDN 的远程鉴权接口上，自建了一套分层拦截规则。核心思路不是“匹配特征”，而是“识别行为”：
确定性判断优先：先拦截那些在正常业务中永远不会出现的请求特征。这类规则零误杀，且不依赖频率、不依赖 IP、不依赖 UA，攻击者无法通过伪造请求头绕过。
频率检测兜底：对同一来源、同一资源的请求做同秒和窗口限制，但只对非分段请求计数，避免误伤正常播放器的缓冲行为。
分层白名单：对微信、小程序、App、投屏、原生播放器等正常客户端放行，但白名单不前置——伪造白名单的请求仍然要经过频率检测。
IP 段封禁：对确认的攻击 IP 池，直接封禁网段，把攻击流量挡在鉴权层之外。
这套规则上线后，最核心的那条确定性规则，当天就拦下了 98% 的攻击请求，而且零误杀。
成效
| 指标 | 治理前（9 月 3 日） | 治理后（10 月 3 日） | 变化 |
|---|---|---|---|
| 总流量 | 122.75 GB | 42.77 GB | -65.2% |
| 请求数 | 90.17 万 | 77.41 万 | -14.2% |
| 命中率 | 67.58% | 57.81% | 回归正常水平 |
流量降了 65%，但请求数只降了 14%。 这个差异说明：攻击者的请求量还在，但每个请求都被拦在鉴权层，没有回源，没有产生真实流量。
单日节省流量约 80 GB，按 CDN 的阶梯单价估算，这是一笔实实在在的成本节省。更重要的是，正常业务请求量基本持平，用户体验没有受到任何影响。
这件事对机构意味着什么
CDN 盗刷不只是技术问题，更是成本问题。
对媒体机构、内容平台、电商站点来说，CDN 流量费是每月固定支出的大头。盗刷流量混在账单里，看起来和正常流量没有区别，财务上很难察觉，技术上也很难归因。等发现时，往往已经损失了几个月。
以这次治理为例：
治理前：单日 122.75 GB，其中相当一部分是盗刷流量。
治理后：单日 42.77 GB，盗刷流量被挡在鉴权层之外。
单日节省：约 80 GB。
按月估算：约 2.4 TB。
按年估算：约 29 TB。
这还只是流量费本身。 盗刷带来的隐性成本还包括：
带宽峰值被推高：盗刷流量推高了峰值带宽，导致按带宽计费的场景成本上升。
回源压力增大：盗刷请求穿透 CDN 回源到对象存储，产生额外的回源流量费。
缓存命中率被污染：盗刷流量稀释了缓存命中率，让正常内容的缓存效率看起来变差，误导容量规划。
安全风险累积：持续盗刷说明站点存在被利用的入口，如果不处理，可能演变为更严重的攻击。
自建鉴权防护的价值，不只是“省了流量费”，而是把一笔看不见的、持续流出的成本，变成了一笔可控的、一次性的技术投入。
对机构来说，这是一件投入产出比极高的事：一套自建规则，上线当天见效，长期运行零误杀，节省的成本按月累积。
攻击者后来做了什么
封了主力 IP 段后，攻击者换了一批新 IP，但手法没有本质变化。于是核心规则继续拦。他们可以换 IP、换 UA、换频率，但只要还在用同一套攻击逻辑，就会被同一套防护逻辑拦住。
一点感想
这一个月的过程，让我对“自动防护”有了新的认识。
平台给你的“一键开启”，往往只是通用防护的下限。它能挡住一些低级别的攻击，但面对有针对性的、持续性的盗刷，它力不从心。
真正有效的防护，是你自己根据日志，看清楚攻击者在做什么，然后针对性地拦掉它。 这套方法不依赖平台，不依赖特征库，也不依赖运气——它依赖的是你对业务的理解和对数据的分析。
如果你也遇到了类似的 CDN 盗刷问题，欢迎交流。
