企业官网建设流程全解析

大概在去年这个时候，我们多域名业务的线上服务就吃过一次DDoS攻击的亏。当时被打的不是主站，而是一个几乎没人管的活动老域名——流量不大，也没接入任何防护。攻击流量一路冲过来，因为这个老域名和主站共用同一套DNS解析和源站集群，结果整个业务的可用性在几分钟内全部崩掉。那次之后我才彻底想明白一件事：多域名业务的DDoS安全防护，和单域名是完全两种玩法。这篇文章就把我这两年的实战经验拆开讲一讲，希望能帮到正在为多域名体系做防护方案的同行。

1. 多域名业务在DDoS攻击下的真实困局

1.1 为什么域名一多，攻击面就失控

单域名架构下，你的防护逻辑很简单：把所有流量引到一个入口，在这个入口上做清洗，源站IP藏好，基本就稳了。但多域名业务不是这样。

首先，域名数量直接拉高了暴露面。一个业务线可能有主域名、活动域名、短链域名、CDN回源域名、内部管理域名，甚至还有几百个子域名。攻击者不需要打穿你花了最多钱保护的主站，他们只需要找一个防护薄弱的旁系域名。这个域名只要和主站共享DNS、共享源站、共享回源链路，那就是一个天然的跳板。

其次，不同域名的归属可能分散在不同部门、不同云账号下。我见过不少企业，市场部注册个域名自己接了个便宜CDN，技术部的核心业务挂了高防，两边各自为政。你以为自己在做安全防护，实际上防护是碎片化的，攻击者随便挑一个最弱的点打进来，所有域名的业务都会被影响。

还有一个容易被忽略的点：很多域名的二级、三级子域名是自动泛解析的。攻击者不用知道你有哪些子域名，直接对泛解析域名随机拼接前缀就能形成大量的请求流量。这种流量特征非常像正常用户访问，而且分散到不同子域后，任何一个子域的监控指标都看不出异常，但从整体看已经在缓慢消耗你的带宽和连接数。

1.2 被攻击时最容易出现的连锁反应

多域名最怕的不是某一个域名挂掉，而是一条链路被击穿后引发的雪崩。

以我们那次事故为例，攻击流量主要打的是老域名的DNS查询和443端口连接。因为老域名的DNS记录和主站在同一个云解析服务上，高并发的DNS请求直接拖垮了云解析商的整体响应。主站域名虽然没被攻击，但用户访问时DNS解析超时，一样进不来。这就是典型的“共享基础设施”灾难：你防住了目标，防不住目标周边的公共组件。

再往下走，如果攻击流量穿透到了源站，那就更麻烦。多域名共用的源站集群通常是一组负载均衡后面的几台机器，CPU、连接数、带宽任何一个指标被打满，所有域名全部遭殃。更恶心的是，CC攻击不会直接打爆带宽，它是慢吞吞地把你的连接池和PHP-FPM进程耗完，等你发现时，半数的机器已经进入了不可用状态。

另外，还有一个容易被忽视的连锁反应是防护策略的误伤。多域名业务里不同域名的用户群体、访问特征差异很大：有的域名是API接口，请求频率极高；有的是官网，流量平稳；还有的是下载站，瞬时流量很大。如果你把一套限速策略套到所有域名上，极大概率会把正常用户给拦了。我见过一个客户因为统一设置了IP并发数限制，导致办公网出口的所有人访问他们家API全部失败，企业客户投诉电话被打爆。

1.3 多域名防护的三大认知误区

误区一：只给主域名投入防护。攻击者不蠢，他们知道你主域名有高防，所以会挑你的子域名、活动域名、老域名下手。防护的投入必须覆盖所有互联网可达的域名，至少要把入口层统一管理起来。

误区二：把“接入CDN”等同于“接入DDoS防护”。CDN本身有缓存加速能力，对静态资源攻击有一定缓解作用，但面对大流量DDoS或者针对源站的CC攻击，CDN只靠缓存是扛不住的。CDN是防护链条里的一环，不是全部。

误区三：不做容量规划，等攻击来了再说。多域名业务的特点就是流量分散、特征复杂，如果没有平时的容量基数和流量画像，攻击发生时你连“现在的流量是正常值的几倍”都判断不出来，更谈不上判断是否已经进入攻击状态。

2. 防护架构选型：自建、云清洗还是混合方案

2.1 三条主流路线分别适合什么场景

目前多域名业务做DDoS防护，主流方案无非是三种：自建防护、云清洗（DDoS高防IP/高防包）、混合方案。

自建防护是买硬件清洗设备（比如流量清洗器、防火墙）部署在机房入口，骨干线路出现攻击流量时，通过BGP引流把流量导向清洗设备，过滤后再回注。这条路线的最大优势是可控性强：策略、调度、数据全在自己手里，不依赖第三方。但缺点也很现实——成本极高。一台像样的清洗设备动辄几十万起步，还要养专门的网络团队去维护BGP调度、路由策略、设备版本升级。除非你的业务体量已经大到每月带宽成本百万级，否则自建很难回本。

云清洗是目前中小型多域名业务的主流选择。本质上是把流量调度到安全厂商的清洗机房，由对方的Anycast网络帮你把攻击流量分散到多个节点，清洗完再把干净流量回源。你不需要自购设备，按防御峰值或者按实际清洗流量付费，弹性很好。缺点在于回源链路和配置黑盒，出了问题你得依赖厂商的响应速度。

混合方案则是“自建+云清洗”的组合，通常是大企业的选择。平时流量走本地机房，只有检测到攻击流量达到阈值时才自动把流量切到云端清洗。这样可以兼顾成本与防护能力，但对团队水平要求很高：你要懂BGP、懂策略路由、懂自动化调度，还要能接受切换时的短暂抖动。

2.2 我的选型判断框架

我自己的选型逻辑，比较看重四个方面：清洗能力、调度延迟、协议兼容性、运维成本。

清洗能力看两个数字：带宽清洗能力（bps）和包清洗能力（pps）。很多厂商宣传口径是“T级别防护”，但你要问清楚T是带宽的T还是包速率的T。对小包攻击来说，pps比bps更重要，很多设备带宽没打满，但每秒上亿个包就把设备的CPU打死机了。选型时至少要保证云清洗节点的pps能力是你日常峰值的几十倍以上。

调度延迟决定了你遇到攻击时多长时间能开始清洗。DNS引流几秒钟到几十秒，BGP引流大流量时可能需要几十秒。这个延迟不适合在攻击发生后做决策，所以调度最好是自动的：厂商的检测系统发现流量超过阈值，自动把域名切到清洗节点。尽量选能做到秒级切换的。

协议兼容性主要看你对TCP/UDP/WebSocket/QUIC的支持要求。很多老牌高防对TCP协议支持很稳，但对UDP和WebSocket的清洗策略比较弱，甚至误杀正常的长连接流量。如果你的业务有实时音视频、游戏对战类场景，这些一定要在选型时问清楚，不能只看宣传材料标称的“全协议支持”。

运维成本不只是钱，还有人力。多域名业务的常态是：域名新上线、域名下线、流量模型变化、加白名单、调策略。如果防护平台没有开放的API，你没法把域名接入、策略调整这些动作自动化，每个操作都要去后台点半天，那这个方案再便宜我都不推荐。

2.3 多域名统一接入的设计思路

选型确定之后，接下来要做的是把多个域名统一到一个防护入口上，而不是每个域名各接一套。

常规做法是设计一张“域名-防护策略”映射表，由统一的接入层网关接收所有域名的DNS解析，再根据域名把流量分发到对应的防护策略组。具体到云高防产品里，通常体现为“高防IP+域名绑定+防护策略集”的组合。你可以把一个高防IP绑定多个域名，每个域名关联独立的防护策略。这样有几个非常实际的好处：第一，源站只需要对这一个高防IP做白名单回源，源站入口管理成本大幅下降；第二，攻击者无论打哪个域名，流量都会被汇聚到同一个清洗节点，清洗效果更集中；第三，日常策略变更只需要在接入层批量配置，不需要逐个域名改源站。

统一接入之后，别忘了一个细节：域名和证书的关系。多域名业务最常见的证书方案是泛域名证书或者SAN证书。高防节点在终止SSL时，需要支持导入这些证书，否则你的HTTPS流量会在清洗节点被断开。我当时在选型清单里专门加了一条：是否支持泛域名证书和多证书绑定。有些厂商表面说支持，实际操作时只允许一对一绑定，多域名一多就非常痛苦。

3. 流量调度与源站隔离：把主动权握在自己手里

3.1 用DNS智能解析做第一道分流

安全防护的前提是不影响正常业务。DNS智能解析在这里的作用，就是让不同来源、不同状态的用户走到不同的路径上。

我当时的设计是分三个流量池：默认池走高防IP，静态资源池走CDN，内网管理池只允许白名单IP访问。域名解析在DNS层按来源地域、运营商、访问类型做策略分发。比如：境外用户统一解析到CDN节点，境内用户解析到高防IP；API域名直接解析到高防IP但开启更严格的WAF规则；静态资源域名解析到CDN，由CDN回源时再走高防IP。

这样做的价值在于：攻击流量虽然也会解析到高防IP，但经过清洗后进入源站的比例就低了很多；而正常的静态资源请求根本不会打到源站，直接CDN就缓存返回了，源站的负载压力会小很多。多域名业务里至少40%的流量是静态资源，这个分流做得好，你的源站规模可以比单域名业务小很多还不容易挂。

DNS调度还有一个隐藏好处：你可以通过修改TTL来加速切换。平时把TTL设成300秒甚至600秒，遇到攻击切换解析时，把TTL临时调低到30秒，能在几分钟内让大部分客户端重新解析到新的防护节点。这个技巧在应急时非常管用。

3.2 源站IP隐藏的关键细节

源站IP一旦暴露，清洗得再干净也没用。攻击者会绕过高防直接打你的源站IP，这时候你的高防IP形同虚设。

多域名业务的源站IP隐藏比单域名要多做几步。单域名你只需要保证回源地址是高防IP段。多域名呢？你有多个域名的回源请求会打到同一组源站，其中一个域名配置失误，源站IP就可能泄露。

我踩过一次实实在在的坑：某个域名回源时，WAF把真实的客户端IP放在了X-Forwarded-For头里，源站收到请求后记录日志，日志平台恰好又是公网可达的，结果攻击者通过日志接口反查到了源站IP。这件事之后我们做了三条整改：

第一，回源链路上所有代理节点（高防、CDN、WAF）都必须把源IP头替换成清洗节点自身的IP，不允许透传真实源IP给源站。第二，源站安全组只放行高防回源IP段和办公网运维IP，其余IP一律拒绝。第三，对公网可访问的日志、监控、管理后台做强制内网访问。

还有一个很容易漏掉的点：SSL证书的证书透明度日志（CT Log）不会暴露源站IP，但如果你在证书里绑定了源站域名或者IP的SAN，那就等于把源站信息写在证书里供人查询。发证书时建议只绑定被防护的域名，不要顺手绑定源站的内部域名。

3.3 跨可用区冗余与自动切换

单点的高防IP在极端情况下也可能被打到上限。多域名业务因为域名众多，流量分布广，更容易同时遭遇多路攻击。这决定了防护架构必须做冗余。

我之前给一个电商客户做方案时，要求至少选两个不同城市的高防节点，分别对应不同运营商。DNS层面做两个A记录，配合健康检查实现自动切换：某个高防节点IP的可用性探针连续失败三次，就自动把解析流量切到另一个节点。这个机制看起来简单，但有个关键参数要调好——健康检查的目标不能是源站本身，而应该是清洗节点。因为清洗节点挂了不代表源站挂，反之亦然。如果健康检查直接探源站，会出现源站正常但清洗节点异常时，DNS错误地把流量切走的情况，反而把“可用”变成“不可用”。

另外，高防IP背后的源站最好也做跨可用区部署。源站至少分布在两个机房，当某个机房的网络被大流量冲击到拥塞时，负载均衡能通过健康检查自动把流量切到另一机房。这里有一个容易被忽略的点：切换时不要忘了重新触发各域名的DNS解析缓存。很多客户端和运营商Local DNS会缓存旧的解析结果，你源站切了，但用户可能还在访问旧源站地址，结果一样是打不开。我的做法是切换源站IP时，同时把域名TTL临时调到最低，并尽可能提前一天发布公告，引导用户关掉本地DNS缓存重试。

4. 缓存层与访问控制的纵深防御设计

4.1 CDN/WAF在防护链路中扮演的角色

很多人的理解是“上了高防就不需要CDN了”，这不对。高防解决的是网络层和传输层的大流量清洗，CDN解决的是应用层的流量卸载和加速，WAF解决的是七层攻击的语义过滤。三者是叠加关系，不是替代关系。

以我们的架构为例，流量入口经过高防清洗后，按域名规则分流：静态资源和图片走CDN节点，由CDN缓存直接返回；动态API请求进WAF做协议合规检查；只有确实需要回源的请求才打到源站。这样的好处极其明显——源站收到的请求量可能是攻击流量的几十分之一，防护压力大减。

具体数据上，我们的官网域名曾经被打过一次七层CC攻击。攻击特征很明显：固定User-Agent、固定请求路径、高频滚动刷新。WAF在入口直接拦截了95%的请求序列，剩余的5%因为共享来源IP或特征不典型，进入了源站，但源站的限速模块也把它们挡在了业务逻辑之外。整个攻击过程源站的最大QPS只比平时高了一倍，完全在承受范围内。

4.2 多维度的流量特征过滤

七层防护的精髓在于：别看单条请求，要看请求集合的模式。多域名业务用户行为复杂，单IP限速很容易误伤，所以更靠谱的做法是多维度组合过滤。

我总结了一套比较实用的过滤优先级：

• 地域维度：如果业务本身只服务国内用户，可以直接在高防策略里把境外IP段的请求降权或拒绝。大部分攻击肉鸡分布全球，境外IP请求占比异常高本身就是攻击信号。
• 协议栈指纹：合法浏览器的TLS握手指纹（JA3/JA4）和HTTP头部顺序相对固定。攻击工具通常不具备浏览器特征，可以利用这个指纹库做动态封禁。
• 频率维度：不要只看请求次数，要看“单位时间内新建连接数与活跃连接数的比值”。正常用户的浏览器会复用连接（Keep-Alive），而攻击脚本常常是每请求新建一个连接。这个比值一高，基本可以断定是CC攻击。
• 行为路径：正常用户访问网站时有页面引用链、停留时长、滚动行为，攻击者通常是固定路径直刷。WAF可以配置“三步校验”：首次请求返回JS挑战，通过后种Cookie；带Cookie的请求才能访问业务接口；业务接口对Cookie时效做强制校验。

这套组合下来，我们几乎没有出现过一次因为防护策略误杀正常用户的事故。唯一需要注意的就是在初始配置阶段要开启“观察模式”，把告警日志打开跑一周，观察有多少正常流量被标记为风险。如果没有明显的误杀，再切换到拦截模式。

4.3 限速与挑战机制的最终兜底

就算前面全被绕过，源站侧也一定要有兜底策略。这个兜底不是追求拦截所有攻击流量，而是保证源站在极端流量下不死。

推荐在源站前置的负载均衡上做三层限速：

1. 单IP连接速率限制：默认按业务特性定阈值，比如普通官网50次/分钟，API网关300次/分钟。
2. 单IP并发连接数限制：通常设置为100左右，超过直接丢弃新连接。
3. 源站整体并发限制：给源站设置一个最大并发连接数，超过后新请求排队或快速失败返回503。

三层限速的意义在于：即使高防清洗漏进来一部分流量，也不会直接打垮源站。排队机制还可以保证正常用户的请求在攻击期间依然能被处理，只是响应慢一些，而不是整个服务不可用。

另外，在“快速失败”的响应里，建议返回带有Retry-After头的状态码，这样正常用户的客户端会主动等待重试，而不是反复刷新加重压力。

5. 监控告警与应急响应的实操链路

5.1 多域名场景下的告警指标配置

单域名业务的告警很简单：带宽、QPS、CPU、连接数，差不多够了。多域名业务必须要按域名的维度拆分监控和告警。

我建议至少给每个域名建立四类指标视图：

第一类是网络层指标：入向带宽、出向带宽、PPS。这是判断是否遭遇大流量攻击的首要依据。注意这里不能只看“总带宽”，要看重点域名和整体流量的分布。多域名业务有个问题：某个冷门域名被打的时候，总带宽可能还没达到告警阈值。所以一定要给每个域名设置独立的带宽环比告警，比如5分钟内的带宽如果达到了过去7天同时段的5倍，就触发告警。

第二类是四层指标：SYN报文比例、TCP新建连接数、UDP流量占比。SYN比例超过70%且新建连接数突增，基本就是SYN Flood。UDP流量占比异常升高，则要考虑UDP反射放大攻击。这些指标要比带宽指标敏感得多，通常攻击开始后30秒内就能发现。

第三类是七层指标：HTTP请求错误率、请求延迟P95、WAF拦截量。请求延迟P95突然翻倍，可能说明源站已经被边缘流量拖累；WAF拦截量骤增，说明正在被扫描或探测。

第四类是业务指标：登录成功率、订单创建成功率、核心API调用量。这些指标最能反映“用户体感”，也是我判断要不要提前切走流量、调配资源的核心依据。

5.2 攻击发现后的灰度封禁流程

很多人喜欢“发现问题就全面封禁”，这是最省事也最容易出事的方式。正确的流程应该是灰度收紧。

我们的标准响应流程是这样的：

第一步，先确认攻击目标的集中度。看被攻击的域名占总请求量的比例、攻击来源IP是否集中在少数几段，如果目标明确，直接对目标域名做高防清洗级别提升，同时开启WAF严格模式。

第二步，封禁来源。先封境外可疑IP段，再封已知IDC机房IP段（肉鸡大多在IDC），最后封“高频异常IP”（单IP请求速率超过正常用户均值100倍的）。每一步封禁后观察5-10分钟，确认误伤情况再决定是否继续加码。

第三步，如果攻击还没停，结合业务情况考虑启用验证码或JS挑战机制，对所有访问到业务核心路径的用户强制做验证。这个方法对真人几乎无感，但对自动化攻击是毁灭性打击。

第四步，最后的兜底仍然是提升到“快速失败”模式：当源站并发连接数达到危险阈值时，对新请求直接返回503。虽然这会影响部分用户访问，但能保住源站不被打死，为后续恢复争取时间。

5.3 攻击结束后的复盘清单

攻击结束不等于安全响应结束，复盘才是真正提升防护水平的关键。

复盘时至少要回答这几个问题：攻击从哪个域名进来的？为什么这个域名没有更早触发告警？攻击流量与正常情况下需要分得的资源差距是多少？攻击持续期间，我们的调度和清洗策略哪个环节出现了延迟？下次如何把延迟降到最低？

我会把每次攻击的样本流量抓包保存下来，整理成“攻击特征库”，配置到WAF和高防策略里。同时更新每个域名的流量基线和告警阈值——因为每次攻击后正常流量也会增加，基线不更新，下次告警就会更迟钝。

这里还有一个团队协作层面的经验：多域名业务的响应不是安全团队一个人的事。必须有业务运维在场，因为封禁策略可能误伤业务；必须有网络工程师在场，因为可能要协调运营商做黑洞或流量调度；必须有客服值班人员，因为可能会有用户集中反馈访问异常。响应流程里提前约定好这些岗位的对接人，攻击发生时才不会乱。

6. 多域名防护里最容易忽略的暗坑

6.1 证书更新引发的高防回源断连

很多人不知道，大部分高防的清洗节点在转发HTTPS流量时会做“单向认证”或“双向认证”。如果你的证书更新了，但高防节点上还是旧证书，那攻击流量会被清洗，正常请求却也会因为TLS握手失败全被断开。

我曾经在一次统一的泛域名证书轮换中，漏掉了一个商城域名的旧证书在高防节点上的部署，结果商城域名静默故障了整整两天，直到有用户反馈下单失败才发现。后来我把证书更新做成了强制流程：证书更新前，在所有高防、CDN、WAF节点同步新证书；更新后，自动跑一遍各域名的HTTPS探测，确认握手正常才算完成。

6.2 泛解析带来的防护漂移

泛解析域名在方便运维的同时，也直接让“按域名配置防护策略”这件事变得尴尬。攻击者可以对泛解析下的任意子域名发起请求，每个子域名的请求量都不算高，但如果几千个子域名同时被扫，总流量就非常可观。

对这种情况，只靠单域名策略是防不过来的。我们选择在WAF层级做兜底：所有泛解析子域名的请求必须经过严格的主机头校验，只放行在业务白名单里的具体子域名，其他一律拒绝。对于“主机头不存在”的请求直接返回403，极大减少了泛解析漂移带来的无效流量。

6.3 回源透传真实源IP的坑

前面讲源站隐藏时提过，这里再展开多说一句。很多WAF/CDN产品在默认配置下会把客户端IP放在X-Forwarded-For或者CF-Connecting-IP头里，这本来是为了让源站做业务分析。但在多域名体系里，一旦某个域名的日志平台接入公网访问入口，攻击者就能顺着这些头信息找到源站的真实IP。

所以我的建议是两套方案二选一：要么在回源节点强制把所有自定义请求头剥离，源站只看到清洗节点的IP；要么在源站的日志平台前面加一层严格的内网访问控制，并且日志平台不要绑定公网IP，只做内网解析。千万别觉得自己“业务量小没人会盯上”，被盯上往往就是一瞬间的事。

6.4 预算有限时的优先级排序

不是所有团队都有充足的预算做全套防护。如果你就三五个人，服务器只有几台，该怎么排序？

我的建议是“保主链路，降暴露面”。优先给核心业务域名接入DDoS高防和WAF，源站只对高防回源IP开放；把泛解析关闭，非必需的DNS记录全部下线，减小暴露面；静态资源全部切到CDN，别让静态请求打源站。等业务有盈利空间了，再逐步把边缘域名纳入统一防护。

还有一个省钱的小技巧：很多云厂商的高防是按“域名+保底带宽”来计费的。你可以把多个域名共享一个高防IP和保底套餐，虽然清洗能力共用，但总价比单独买要低30%-40%。前提是你的源站和DNS都做了统一接入设计，否则共享IP也管理不起来。

6.5 与运营商、安全厂商的协同机制

DDoS防护里最被动的一种情况是：攻击流量大到运营商为了保住大局，直接把你整个IP段做了黑洞路由——流量全部丢掉，你的服务彻底不可用。这个级别的事故，只靠云厂商的清洗是不够的。

所以，如果你的业务达到了一定规模，一定要提前和IDC、运营商建立联系，确认攻击流量超过多少时，他们会采取什么动作。同时，把你自己的云清洗厂商的应急联系方式做成置顶卡片分发给团队。遇事不要指望在线工单、也不要把任何希望寄托在“自动升级到专家团队”上，直接电话联系安全值班工程师，告诉他们攻击特征和需要调整的接口，是最快的止血路径。

我在多域名防护这条路上踩过的坑，远比写出来的多。每次遇到问题，我都会重新审视一遍“接入层-调度层-清洗层-源站层”这条链路，看看还有哪个环节不够自动、不够快、不够稳。防护这件事没有一劳永逸，攻击手法会变、业务形态会变、流量画像也会变，只有把“监控-响应-复盘-更新”这套循环跑起来，才能真正护住这一堆域名背后的生意。

如果你也在做多域名业务的防护，建议先别急着买最贵的高防套餐，先把你的域名清单、流量基线和源站暴露面梳理清楚。防护的起点，从来不是设备，而是你知道自己的家底到底有什么、在哪里。