你架好了一台网站，准备迎接用户，结果某天凌晨流量突然暴涨 100 倍——这不是喜讯，而是 DDoS 攻击来了。面对海量的恶意请求，你的服务器瞬间崩溃。这时，防御体系里的清洗中心开始动作：它先把所有流向你网站的流量“引”到自己那里，过滤掉坏人，再把好人送回你的服务器。这个过程叫引流与回注。听起来简单，但背后涉及路由协议、隧道封装、带宽调度等一堆概念。别慌，这篇就用大白话拆解给你看。
DDoS 攻击为什么需要“引流”？
先想一个问题：攻击流量直接冲到你的服务器上，你的服务器扛得住吗？大部分网站服务器带宽只有几十 Mbps 到几 Gbps，而 DDoS 攻击动辄几百 Gbps 甚至 Tbps 级。硬扛就等于拿水杯接洪水。所以防御的第一件事不是过滤，而是把流量“引到别处去”——这个“别处”就是清洗中心。清洗中心有海量带宽和专用设备，能扛住攻击，再从中找出干净流量。
引流：让所有流量先来找我
引流的核心是让原本发往你源站 IP 或域名的网络流量，先经过清洗中心。实现方式主要有两种：
- DNS 引流：把网站的域名解析记录改成清洗中心的 IP。用户请求域名时，DNS 返回清洗中心的地址。这样所有流量都先到清洗中心。这种方式适合 HTTP/HTTPS 业务，但对依赖固定 IP 的 TCP/UDP 应用不太友好。
- BGP 引流：通过边界网关协议（BGP）让清洗中心“代播”你的源站 IP 段。即清洗中心向上游路由器宣告它拥有你的 IP 地址，于是原本发往你源站的流量被路由到了清洗中心。这种方式对业务完全透明，IP 不变，常用于四层防护。
打个比方：你家门口的路被挤爆了，警察在主干道设了一个检查站（清洗中心），所有车先开到检查站，验明正身再放行——这就是引流。
清洗中心里发生了什么？
我的处理经验
流量到了清洗中心后，它要区分“坏人”和“好人”。常用手段包括：
- 源 IP 信誉与黑白名单：对已知的攻击源 IP 直接丢弃。误伤好 IP 怎么办？清洗中心会维护动态信誉库。
- 指纹识别：检测数据包特征，比如 TCP 头中的 SYN 标志异常、请求速率异常、User-Agent 不合理等。
- 行为分析：对同一 IP 的请求频率、会话建立情况做统计，超过阈值则限速或丢弃。
- 协议完整性校验：比如只允许符合 RFC 标准的 HTTP 请求通过，畸形包直接过滤。
清洗中心通常部署在骨干网边缘的大数据中心，接入带宽几百 G 起步，设备包括专用硬件防火墙、负载均衡器、流量分析引擎等。过滤后的干净流量只剩下正常用户请求，接下来就要把它送回你的源站。
想继续深入：此处可内链到“DDoS优化清单”文章。
补充参考：此处可内链到“DDoS故障排查实例”。
回注：把干净流量安全送回家——DDoS
回注的技术难点在于：引流已经把流量拉到了清洗中心，但清洗中心和你的源站不在同一个网络位置。怎么把经过筛选后的“好流量”准确地送到你的真实服务器上？常见回注方式有三种：
直接转发（L3 转发）
最简单的方式：清洗中心直接把收到的干净数据包的目的 IP 改成你源站的真实 IP，然后通过互联网发出去。但这样做会暴露源站 IP，而且流量在公网传输又可能被攻击者观测到。所以这种方式一般只用于 DDoS 防护的演示环境，生产环境很少用。
GRE 隧道 / IPIP 隧道
更安全的做法：在清洗中心和你的源站之间建立一条隧道（比如 GRE 隧道或 IP-IP 隧道）。清洗中心把干净数据包封装到新的 IP 包中，外层目的地址是你的源站真实 IP，内层保留原始数据包。源站收到后解封装，拿到原始请求。隧道的好处是：公网上看到的只是两个点之间的加密隧道流量，攻击者无法直接知道你在处理什么业务。缺点是需要源站侧支持隧道协议，并且隧道带宽可能成为瓶颈。
策略路由回注
如果清洗中心和源站之间有专线或 MPLS VPN，也可以通过策略路由将干净流量直接送到源站的上行路由器。这种方式效率高、延迟低，但需要网络架构配合。
回注过程中还要注意几个问题：
- 回注带宽必须大于业务正常流量峰值：如果清洗后剩下 10 Gbps 的正常流量，但回注链路只有 1 Gbps，就会堵死，正常用户也进不来。
- 回注路径不能成为新的攻击目标：如果攻击者知道你的回注 IP 或隧道端点，就可以直接攻击回注链路，防了等于没防。所以回注链路通常要隐藏，比如和公网隔离。
- 延迟增加：流量多绕一圈到清洗中心，再回注，必然增加 RTT。对于时延敏感的业务（如在线游戏、语音通话），需要选择离用户近的清洗节点或采用 Anycast 方案降低影响。
实际部署中的“引流-回注”组合
容易忽略的细节
生产环境常见的搭配是：用 BGP 引流 + GRE 隧道回注。运营商侧的清洗中心通过 BGP 宣告你的 IP 段，把你所有的流量接管；清洗完成后，通过提前建立的 GRE 隧道，将干净数据包送回你的机房。这种方式对源站几乎无改动，只需在出口路由器上配置隧道解封装，并在防火墙上做好策略允许清洗中心的流量进入。
如果是 CDN 厂商提供的 DDoS 防护，流程又不一样：CDN 节点本身就是清洗节点，用户请求先到 CDN，CDN 发现攻击流量后就在边缘直接丢弃，干净流量通过缓存命中或回源请求发送给源站。这种情况下没有明显的“引流-回注”区分，因为所有流量本来就在 CDN 节点上。
关联教程：此处可内链到“DDoS部署与验证”内容。
一个小白的理解路线图
我的处理经验
你不需要记住所有技术术语，只要记住这个框架：
- 攻击流量像洪水涌向你家——你家（源站）扛不住。
- 消防队（清洗中心）在路口筑起大坝（引流），把洪水引到自己的蓄水池（清洗设备）。
- 蓄水池里泥沙（攻击流量）沉淀过滤掉，清水（正常流量）通过管道（回注）送回你家。
选择哪种引流和回注方式，取决于你的业务类型、网络架构和预算。小网站可能直接用 DNS 引流 + 回注到源站 IP，大企业往往用 BGP+隧道+专线的组合。无论哪种，理解清楚整个链条的瓶颈（回注带宽、延迟、隐藏性）才能避免陷阱。
相关阅读：此处可内链到“DDoS常见问题”专题。
总结
先看关键判断
DDoS 清洗中心的引流与回注，本质上是一次“迂回防御”。它把战场从你的服务器转移到防御设施完备的清洗中心，再“护送”干净流量回家。这个概念理解后，再看各大云厂商的 DDoS 高防产品文档，就会清晰很多。下次运维群里有人喊“被 DDoS 了”，你也能胸有成竹地分析：需要引流还是回注？带宽够不够？隧道建了没？——至少，你不会再以为清洗中心就是你服务器上装的一个软件了。
延伸阅读