摘要：# 网站被打瘫了才明白：高防CDN背后，源站负载均衡才是真战场 说真的，我见过太多站点，钱没少花，高防CDN也上了，结果攻击一来，源站自己先扛不住了。那感觉，就像你花大价钱装了最厚的防盗门，结果贼发现你家窗户压根没关——白搭。 很多老板以为，买了高防就…

网站被打瘫了才明白：高防CDN背后，源站负载均衡才是真战场

说真的，我见过太多站点，钱没少花，高防CDN也上了，结果攻击一来，源站自己先扛不住了。那感觉，就像你花大价钱装了最厚的防盗门，结果贼发现你家窗户压根没关——白搭。

很多老板以为，买了高防就万事大吉。PPT上那些“T级防护”、“秒级清洗”看着确实唬人。但你自己心里得清楚：高防CDN扛住的攻击流量，最终还是要落到你的源站服务器上。如果源站接不住，或者接得不均匀，前面防护再猛，你后台该崩还是崩。

今天咱就捞点干的，聊聊自建高防CDN时，那个最容易被忽略，却又真要命的核心环节：源站负载均衡怎么搞？ 特别是，怎么把四层负载和七层反代这两样东西拧成一股绳，让你既扛得住打，又跑得顺畅。

先泼盆冷水：别以为上了高防就高枕无忧

我去年看过一个电商站，双十一前上了某大厂的高防套餐。活动当天，促销页面访问量暴涨，高防CDN表现完美，所有攻击流量都被清洗得干干净净。但没过半小时，后台订单系统崩了。

一查，问题出在源站。所有干净的流量，像开闸的洪水一样，涌向了同一台业务服务器，其他几台机器几乎闲着。那台可怜的服务器CPU直接跑满，数据库连接池耗尽，整个下单流程卡死。

你看，这就是典型的“木桶效应”——防护的短板不在最前面，而在最后面。高防CDN好比一个超级流量调度员，把坏人都拦在了外面。但调度员把成千上万的好人（正常用户）同时引向一扇小门，门照样会被挤垮。

所以，自建高防CDN，源站层的负载均衡不是可选项，是生死线。你得设计一套机制，让这些“劫后余生”的流量，能平稳、合理地分摊到后端的每一台服务器上。

四层负载：那个默默扛下所有的“老实人”

咱们先说说四层负载（L4）。

你可以把它想象成快递公司的自动分拣流水线。它不看包裹里具体是啥（是衣服还是书本），只认包裹上的目的地标签（IP地址和端口）。活干得贼快，几乎不耽误工夫，性能损耗极低。

在自建高防的架构里，四层负载（通常用LVS、HAProxy的TCP模式，或者云商的负载均衡器）通常放在最前线，直接对接高防CDN的回源IP。

它的核心任务就一个：抗。

• 抗连接数：DDoS攻击里有一种叫CC攻击，就爱建立海量TCP连接耗死你。四层负载能轻松处理数十万甚至百万级的并发连接，靠它先顶住第一波冲击。
• 做流量分发：根据简单的轮询、最小连接数等策略，把TCP/UDP连接快速分给后端的多个七层代理服务器或真实服务器。

说白了，四层是力气活，讲究一个皮实耐造。它不关心你HTTP请求里是查询商品还是提交订单，它的目标就是别让任何一台后端机器被连接数压垮，保证通道不堵。

但光靠它行吗？不行。它太“老实”了。

七层反代：那个心思缜密的“大管家”

如果四层是分拣线，那七层负载（L7，通常用Nginx、Apache或HAProxy的HTTP模式）就是经验丰富的仓库管理员。

它会拆开包裹（解析HTTP/HTTPS协议），看看里面到底是啥需求。然后，它能干很多精细活：

• 按内容路由：把 /api/ 开头的请求分到API服务器集群，把 /static/ 的图片请求分到静态资源服务器，把 /admin/ 的管理请求指向特定的安全区。这叫“基于URL的路由”，四层压根做不到。
• 流量精细化管控：可以针对特定IP、User-Agent做限速，可以过滤一些简单的恶意扫描特征，能给静态资源加缓存，减轻后端压力。
• SSL终端卸载：把HTTPS解密的累活从业务服务器上拿过来，统一处理，后端服务器直接用HTTP，省心省力。

在自建高防CDN的架构里，七层反代通常放在四层负载之后，业务服务器之前。它管的是“好不好”，是业务层面的智能调度和优化。

那么，怎么把“老实人”和“大管家”结合好？

纸上谈兵没意思，我来画个你大概率能用上的架构图（心里想想就行）：

用户 -> [高防CDN节点] -> [你的四层负载集群] -> [你的七层反代集群] -> [真正的业务服务器]

具体怎么玩？

1. 四层在前，七层在后，分层阻击 这是最经典、也最稳妥的组合。高防清洗后的流量，先打到四层负载VIP。四层负载不看内容，以极高的效率把连接分给后面多台七层反代服务器。然后，七层反代服务器再根据HTTP请求的详细内容，智能地分发给最终的业务服务器。

好处是什么？ 防御层次清晰。四层专门应对连接型攻击和做初级的流量均衡；七层则专注于应用层优化和精细路由。即使七层需要reload配置或出点小问题，四层还能保持连接不中断。

2. 别把鸡蛋放一个篮子：多机房部署 真正有点追求的架构，不会只在一个机房放源站。你可以在A、B两个机房，各自部署一套“四层+七层”的集群。然后，在高防CDN的回源设置里，配置多个源站IP（A机房一个，B机房一个）。

这样，高防CDN可以基于健康检查，自动切换回源线路。就算一个机房整体出问题（比如运营商线路故障，或者……真的被攻进内网了），流量可以秒切到另一个机房。业务连续性，不是靠一台设备，而是靠一套能灵活调度的架构。

3. 健康检查，必须“双管齐下” 这是血泪教训。你的四层负载要检查后面的七层反代服务是否存活（比如检查TCP端口）。而你的七层反代，更要仔细检查每一个业务服务器的健康状态（比如发一个HTTP GET请求到 /health 接口，看返回状态码和内容）。

只有两级健康检查都到位了，故障机器才会被及时踢出集群，避免用户请求被导向一台已经宕机的服务器，那体验可就太差了。

几个你可能会踩的坑（我踩过）

• 会话保持问题：如果你的应用需要登录状态（Session），要确保在七层配置合理的会话保持策略（比如基于cookie），否则用户可能这次请求到了A服务器，下次到了B，登录状态就丢了。四层一般不管这个。
• 真实IP传递：高防CDN会把用户真实IP放在HTTP头里（如 X-Forwarded-For），你的七层反代和业务服务器，一定要正确配置来读取这个头，否则你日志里全是高防节点的IP，出了问题没法溯源。
• 监控要细到骨子里：别只监控业务服务器CPU。四层负载的连接数、吞吐量，七层反代的请求处理时间、HTTP状态码分布（特别是4xx、5xx错误），都要有实时告警。攻击往往先从这些指标的异常开始。

最后说点大实话

自建高防CDN的源站架构，没有银弹，没有一套配置走天下的方案。它取决于你的业务类型（是API多还是下载多）、你的流量规模、你的预算。

但核心思路是不变的：用四层负载扛住大流量、高连接的冲击，用七层反代实现业务的智能、精细化管理。两者叠加，才能形成纵深防御。

别再只盯着高防CDN的宣传页了。回过头，好好审视一下你的源站，那些流量最终落地的地方。把它整扎实了，你的防护体系才真正算得上牢不可破。

行了，就聊这么多。架构图在心里画明白了吗？没明白就再琢磨琢磨，这玩意，光听没用，得动手配。