CC攻击打过来，CDN配错一步照样打穿源站

防护开起来不等于万事大吉。CC攻击打过来，CDN配错一步照样打穿源站，这话不是吓人——域名往 CDN 上一挂、后台几个开关随手点两下，就以为源站从此隐身的人太多了。真遇到攻击，边缘节点确实在扛，可源站的带宽和 CPU 也跟着一起飙，监控图上两条曲线一块冲顶。为啥？请求压根没被拦住，只是换了个入口，顺着回源通道原封不动灌进了机房。

CC攻击打过来，CDN配错一步照样打穿源站，漏的常是回源这一段

回源这词听着技术，换个说法就是：CDN 节点替你去源站取内容。取内容的那条路，恰好是攻击者最想走的路。所以源站的安全组、防火墙，第一条规则应该是只允许 CDN 的回源 IP 段访问 80/443，其余一律拒绝。麻烦在于这段 IP 不是钉死的，服务商隔段时间会调整，具体以服务商或官方页面说明为准。见过有人配完白名单就再没管过，后来业务忽然时好时坏，查半天才发现节点段早变了，自己把 CDN 挡在门外，又把全网放进了门里，两头都错。还有个细节常被漏掉：IPv6 的回源段只写了 v4，测试时一切正常，线上有 v6 用户就开始出怪事。

缓存规则点错一个选项，CC 请求全落到源站

CC 有个特点，它打的往往不是首页，而是搜索页、登录接口、带参数的列表页，这些页天生不该被缓存。缓存规则写得再漂亮，命中率也上不去，每个请求都得回源。这时候边缘节点只是搬运工，源站的 CPU 和连接数照样被打满。另一种错更隐蔽：为了省回源带宽，把“缓存全部”打开，连带 Cookie 的请求也一起缓存，不同用户的登录态互相串——这已经不是被攻击，是数据事故。稳一点的做法是静态资源给长缓存，动态接口明确排除，再单独给接口配速率限制和人机校验。判断有没有配错不用猜，看缓存命中率和回源带宽两条线就行，攻击时回源带宽贴着源站出口跑，基本就是没兜住。

源站真实 IP 藏不住，CDN 就成了一道装饰

攻击者绕过 CDN 只需要一样东西：你的源站 IP。它怎么泄的？常见几条路——早年解析记录没清理，用公开的 DNS 历史查询就能翻出老 IP；主域名接了 CDN，某个测试子域名、邮件服务、后台入口还直连源站；服务器自己发出的邮件头里带着真实地址；证书透明度日志把没接入的子域名一条条列出来；还有最土的，扫全网 IP 段找开放 80 端口、返回你站点特征的机器。自查办法很笨但管用：找一台跟源站无关的机器，直接 curl 源站 IP 并带上 Host 头，能正常返回页面，说明这条缝一直开着。发现泄露了，光改解析不够，源站 IP 该换就换，顺序是先配好白名单再切流量。

回源 HOST 和证书没对上，自己先把自己打挂

有些 5xx 跟攻击没关系，纯粹是配置。回源 HOST 填错，源站收到一个不认识的域名，给你默认站点或者 404；源站上挂多站点的话，还会内容串台。HTTPS 回源更麻烦，CDN 边缘证书正常、源站证书域名对不上，握手就过不去，表现是一片一片的 502、526 类报错。攻击高峰期这种报错最容易被当成“被打挂了”，其实是自己挖的坑。上线前把 80 和 443 两条回源链路各测一遍，别只测一条，回源端口、回源协议、源站证书校验这几个开关改完都要重新验证，缓存和配置不会自动帮你记着。

只靠缓存扛 CC，等于拿纸板挡雨

CC 的请求长得跟正常用户一模一样，只是频率不对、分布很散。纯靠缓存命中率去扛，效果完全取决于攻击打在哪；打动态接口的时候，基本没有缓冲。防护规则得单独配：单 IP 速率限制、人机校验、地区或 UA 黑名单，必要时上更高一档的防护。阈值这东西很烦人，设低了正常用户被拦，设高了等于没设，只能拿真实流量跑几天慢慢调。攻击来的时候先看几个数：回源带宽是不是逼近源站出口上限、5xx 比例、源站连接数、缓存命中率有没有突然掉。这几个一比，是 CDN 没兜住还是源站自己撑不住，基本能分清。别只盯总带宽曲线，那条线好看不代表源站没事。

上线前照着过一遍

把这几件事排一排：源站安全组只放行 CDN 回源段，v4 和 v6 都写，定期核对更新；主域名和所有子域名都走 CDN，不留直连口子；缓存规则确认动态接口不被缓存、带登录态的请求不被缓存；回源 HOST、回源协议、证书三条链路各测一次；速率限制和人机校验别留空；最后从外部机器验证源站 IP 不可直连。做完不算完，过一阵再回头看一次——配置会被人改，节点段会变，业务也会加新接口，旧的白名单不一定还认新业务。

CDN 不是一堵墙，它更像一层筛子。筛孔大小是你自己调的，调错了，攻击过来的时候水还是原样漏进机房。真出事那天再去翻配置，时间根本不够用——平时花二十分钟把回源口锁好，比事后熬夜盯监控划算得多。