高防架构怎么搭：本地清洗、云清洗、高防 IP 与高防 CDN 的分工

高防架构怎么搭：本地清洗、云清洗、高防 IP 与高防 CDN 的分工

高防架构要解决的问题只有一个：攻击流量能不能到达源站。所有方案的本质差别，不在于"防护能力谁更强"，而在于清洗动作发生在链路的哪个环节、以及源站在整个链路里是否可被直接寻址。理解这一层，四种形态的分工就清楚了。

本地清洗把设备放在机房里，流量先到机房再筛；云清洗把流量先引到清洗中心，筛完再回源；高防 IP 让外部只能看到一个代理地址，真实源站被藏在后面；高防 CDN 把清洗与加速合并，源站只接受 CDN 回源。四者不是互相替代的关系，而是针对不同攻击形态与不同架构约束的组合件。

本文只讨论机制与选型判据，不涉及具体防护峰值与价格档位——那部分属于采购参数，可以对照 高防服务器选购指南 中的参数清单。本文要回答的是更靠前的问题：你的业务适合把清洗放在哪一层。

一、先明确高防要解决的是哪一段

1.1 攻击面与清洗能力落在哪个环节

任何一个对外服务的链路都可以拆成：用户 → 公网 → 接入层（IP 或 CDN）→ 源站。攻击可以打在任何一段上，但最终目的都是把源站打瘫或者把带宽打满。因此防御的位置决定了防御的效果。

如果清洗发生在接入层之前，源站本身不受流量冲击，但接入层必须扛得住；如果清洗发生在源站所在的机房，攻击流量已经消耗掉机房的入口带宽，能不能扛住取决于机房的上联容量；如果源站可被直接寻址绕过，那么所有接入层的防护都形同虚设。这三种情况是理解后面所有方案的基础。

因此判断一个方案是否成立，可以按顺序提三个问题：源站能不能被绕过？清洗容量在哪一层、由谁承担？清洗之后的回源路径是否稳定？三个问题里任何一个答不上来，方案的可靠性都要打折。这也是为什么“防护多少 G”这种单一参数几乎没有决策价值——同样标称容量的两个方案，一个能隐藏源站、一个不能，实际效果可能完全相反。

1.2 先分清流量型、连接型与应用层

流量型攻击（UDP 洪泛、DNS 反射、NTP 反射等）的目标是占满带宽，特征是入向流量远超正常业务；连接型攻击（SYN 洪泛、连接耗尽）的目标是占满连接表，流量可能并不大；应用层攻击（HTTP 洪泛、慢速请求、高频抓取）的目标是占满应用处理能力，单看带宽几乎无感。

三类攻击对应的防御手段完全不同：流量型靠大容量清洗与就近牵引，连接型靠 SYN 代理与连接数限制，应用层靠行为分析、速率限制与人机校验。选型前先明确"我可能被打的是哪一类"，比笼统地问"防护多少 G"更有意义。防护资源与攻击类型的匹配关系，也可以结合 安全加固 分类中的基础内容一起看。

二、本地清洗：设备在机房

2.1 优点：不改架构、延迟不变

本地清洗指机房侧部署清洗设备，流量先进入机房，经过设备识别与过滤后再转给源站。对业务来说，这种方案最大的优点是"无感"：不需要改 DNS、不需要改证书、不需要业务侧配合改造，源站 IP 与访问路径完全不变，延迟也不增加。

对延迟极其敏感的业务（游戏、实时音视频、交易类接口），这一点很关键。任何牵引型方案都会引入额外的网络跳数与转发延迟，本地清洗不会。

2.2 致命短板：机房上行被打满

本地清洗的边界非常清晰：它只能在流量已经进入机房之后才起作用。如果攻击流量超过了机房的上联带宽，那么在清洗设备开始筛选之前，机房的出口就已经拥塞，正常用户的请求也会一起被拖死。

更麻烦的是"共享上联"的情形：同一机房的其他用户被攻击，可能连带影响你的连通性。所以本地清洗适合的是"有一定防护能力、并且确有富余上联"的机房，而不是把普通机房包装成"自带高防"的产品。判断标准很简单：问清机房的清洗容量与上联总带宽的比例，以及超出后如何处理。

三、云清洗与牵引

3.1 牵引触发条件

云清洗的主流形态是"平时直连、攻击时牵引"：正常流量直连源站，检测系统发现异常后，把域名解析或路由切换到清洗中心，清洗后再回源到源站。这条链路省掉了平时的额外延迟，代价是切换本身需要时间。

因此"牵引触发条件"是这套方案的核心参数：是按入向流量阈值触发，还是按包速率、连接数、协议特征触发；检测是秒级还是分钟级；切换是自动还是需要人工确认；切换后多久生效（取决于 DNS 的 TTL 与各地递归缓存的刷新速度）。这些参数直接决定了攻击初期的几分钟你会不会被打穿。

TTL 设置在这里有个真实的权衡：TTL 短，切换生效快，但解析请求量大、递归缓存命中率低；TTL 长，平时解析更稳，但攻击时要等更久才能完成牵引。解析层面的机制细节可以对照 DNS 智能解析。

3.2 回源线路决定实际体验

牵引之后，用户不再直连源站，而是先到清洗中心再由清洗中心回源。这条回源线路的质量，直接决定用户的实际体验——清洗中心离源站远、或者回源走公网绕行，延迟会明显上升，有时甚至高过攻击本身带来的损失。

所以评估云清洗方案时要问三个问题：清洗中心在哪里（是否有就近节点）、回源是走专线还是公网、回源带宽是否单独计费。第三个问题常被忽略——大多数清洗服务的计费基于"清洗后的干净流量回源"，回源带宽是成本项，大流量业务在这里会多出一笔不小数目的费用。

四、高防 IP：隐藏源站

4.1 关键在于源站 IP 是否真的没泄露

高防 IP 的模型很直观：对外只公布一个高防 IP，所有流量先到高防节点，清洗后转发到真实源站。攻击者打的是高防 IP，源站被藏在后面。

这个模型的全部有效性都建立在一个前提上：源站 IP 从未泄露。一旦真实 IP 被找到，攻击者直接绕过高防 IP 打源站，防护等于不存在。而高防 IP 方案通常不会限制源站只接受来自高防节点的流量（或者需要额外配置白名单），所以泄露的后果往往是灾难性的。

4.2 暴露源站的常见途径

源站 IP 的泄露路径比想象中多：历史 DNS 记录（换高防前的 A 记录被第三方 DNS 历史库完整保留）、子域名解析到源站、邮件服务头部的发信 IP、源站自己发起的对外请求（如 webhook 回调、第三方统计上报）、SSL 证书的签发记录与证书透明度日志、以及源站直接对外提供的其他端口（SSH、面板、数据库端口）。

对应的收尾动作是可以穷举的：换高防时同步更换源站 IP；把源站防火墙配置成只允许高防节点回源；检查所有子域名与历史解析；把发信服务与源站分离；清理源站上不必要的对外端口。这些检查项的完整清单可以参考 服务器加固基础清单。

五、高防 CDN：清洗与加速合一

5.1 回源鉴权是命门

高防 CDN 把清洗能力放在边缘节点上，同时承担静态加速。它的接入方式是 CNAME 到服务商域名，源站不再对外暴露 IP，只接受来自 CDN 节点的回源请求。

这种架构的最大风险同样明确：如果回源请求没有鉴权，攻击者只要知道源站 IP，就可以伪造回源请求直接打源站，或者绕过 CDN 拿到未经过滤的内容。因此回源鉴权（签名 URL、回源鉴权头、源站 IP 白名单、mTLS）不是可选项，而是这套方案能否成立的前提。

5.2 绕过 CDN 直连源站的路径

与高防 IP 类似，绕过 CDN 的路径也需要逐一封堵：源站是否还能被公网直接访问（应只允许 CDN 节点段）、是否存在未接入 CDN 的子域名或旧域名、源站邮件头是否暴露真实 IP、CDN 配置里是否遗漏了某些端口或协议。

一个实操建议：配置完成后，从外部网络直接访问源站 IP，确认所有端口的响应都是超时或被拒绝；再对比"通过 CDN 访问"和"直连源站"的响应差异，确认没有出现"直连也能拿到内容"的情况。CDN 的缓存与回源机制本身，可以继续读 CDN 工作原理。
还要接受一个现实：高防 CDN 的效果与缓存命中率强相关。攻击打到的如果是缓存命中的静态请求，边缘节点直接返回，源站几乎无感；如果打的是不可缓存的动态接口，每个请求都要回源，边缘节点起到的只是“过滤与限速”作用，源站压力仍有上限。因此把可缓存的部分尽量缓存、把动态接口的鉴权与限速做在边缘，往往比继续加防护容量更有效。

六、两个必须分清的概念

6.1 清洗不等于黑洞

很多人把"高防"理解成"被打时自动过滤"，但现实中相当一部分机房在流量超过其防护能力时，采取的动作是黑洞路由：直接把被攻击的 IP 从路由表里摘掉，所有流量（包括正常用户的）一律丢弃，直到攻击结束。

这两者的差别是业务连续性的差别。清洗意味着业务继续可用，只是部分恶意请求被丢弃；黑洞意味着业务整体不可用，时长取决于攻击持续多久。所以在采购或评估时必须问一句：超出防护能力后的行为是什么——是继续尽力清洗并限速、还是直接封禁 IP、封禁多久、能不能手动解除、解封后是否会自动再次封禁。

同样值得问的是"封禁的粒度"：只封被攻击的端口，还是整 IP 全端口；是否影响同机其他 IP。这些细节在平时看不出来，攻击当天就是全部。

6.2 高防不等于 WAF

高防处理的是流量层（L3/L4）的问题，以及一部分 L7 洪水（HTTP 洪泛）。它不解决注入、越权、失效的访问控制、敏感信息泄露、爬虫抓取、账号撞库这类应用层问题。这些恰恰是 OWASP Top 10 覆盖的范围，属于 WAF 与应用自身代码的职责，可以对照 Web 安全基础与 OWASP Top 10。

一条常见的误判是：买了高防之后认为"安全做完了"。实际上高防只是让服务"打得死不掉"，而 WAF 与代码加固才是让数据"拿不走"。两层要分开建设，也要分开验收：高防验收看攻击期间可用性，WAF 验收看拦截率与误拦率。

七、选型判据与组合

7.1 四个维度构成的判断框架

第一个维度是攻击类型。纯流量型且峰值极大，需要大容量清洗与就近牵引；连接型为主，重点是 SYN 代理与连接表容量；应用层为主，重点是 WAF 与速率限制，此时堆清洗带宽基本无效。

第二个维度是业务能否改架构。能不能接受 CNAME 接入？能不能把源站 IP 换掉并只允许代理回源？能不能接受少量额外延迟？三个都"能"，高防 CDN 通常性价比最高；只能接受"不改解析、不加延迟"，本地清洗或 BGP 高防 IP 更合适。

第三个维度是源站能否隐藏。如果源站 IP 已经广泛泄露（历史记录、第三方系统、邮件头），先做清理再谈防护；清理之前上高防，效果会大打折扣。

第四个维度是预算按什么计费。按带宽计费（保底带宽 + 弹性）适合流量相对稳定的业务；按 QPS 或请求数计费适合应用层攻击为主的 API 业务。计费维度选错，要么平时浪费，要么攻击时账单失控。

7.2 组合架构与演练

真实生产环境很少只用一种形态。常见的组合是：前置高防 CDN 承担公网入口与 L7 过滤，源站只接受 CDN 回源并配置 IP 白名单，重要业务再叠加云清洗作为大流量兜底，同时在源站所在机房保留本地清洗作为最后一道。这套组合的成本不低，但对营收敏感的业务是合理投入。

无论选哪种组合，都要做演练：在低峰期模拟一次牵引切换，记录生效时间、解析扩散时间、业务可用性变化；模拟一次"源站被直连"，确认白名单是否生效；模拟一次超量，确认黑洞触发条件与解封流程。没有演练过的防护架构，在真正被攻击时大概率会暴露出配置遗漏。

做横向了解时，可以参照几家在清洗与国际网络上有长期积累的服务商：Cloudflare 安全产品 以 Anycast 网络与 L3-L7 一体化防护见长，Akamai 安全产品 在边缘容量与清洗经验上积累很深，Imperva 侧重应用层防护与数据安全，Radware 则以清洗中心与行为分析方案为主。选哪一家之前，先把上面四个维度填一遍，需求清晰了再去比方案。

来源：16IDC 原创，具体规格、价格与服务条款以各服务商官网文档及合同为准。