企业官网建设流程全解析

干这行最怕的不是业务上线前的通宵，而是凌晨三点的告警电话。某电商平台在大促预热的一个晚上，入口带宽突然被拉满，边缘节点上的连接表瞬间膨胀，正常用户访问开始大面积超时。这不是个案，如今随便一场活动，几百Gbps的流量型DDoS已经不再稀奇。面对这种量级的攻击，单靠一台高防服务器硬扛不仅价格吓人，而且带宽总是会被打光。CDN不一样，它天生就是分布式的，几十个节点同时接收用户请求，攻击流量会被拆散到每个入口，然后在边缘把恶意报文和异常请求识别出来扔掉，只把干净流量放行回源。这个过程的专业说法就四个字：流量稀释、流量清洗。下面我把CDN究竟怎么做到这两件事拆开讲，顺便聊聊接入配置和问题排查里容易踩的坑。

1. 分布式架构如何做到流量稀释

1.1 Anycast：流量不会只敲一扇门

传统抗D思路是把业务放在一台高防机器上，所有流量都冲着这一个入口来。攻击流量到了T级别之后，单机带宽和硬件性能都扛不住，继续加带宽又是个无底洞。CDN做分布式稀释的核心机制是Anycast，也就是同一段IP地址在多个地域的节点同时被宣告出去，路由协议会按照BGP的最优路径规则，把去往这个IP的流量自动送到“最近”“最合理”的节点上。

这意味着攻击者即使把攻击目标锁定在某个域名或IP上，发出的海量数据包也不会全部落进同一个机房，而是被运营商路由天然打散到了多台边缘设备。对每一个节点来说，它看到的只是攻击总量中很小的一部分。拿我配合过的一个某电商平台举例，攻击流量到达400Gbps时，分散到华北、华南多个接入节点后，压力最大的节点也才跑到带宽上限的六成左右。其他节点虽然也在扛流量，但离被打满还有距离。这就是稀释的价值：不是让攻击凭空消失，而是让它同时面对几十个目标，而不是一个。

1.2 智能调度：把用户从过载节点挪开

除了网络层的Anycast，流量稀释还有一层DNS调度逻辑。CDN的权威DNS和全局负载均衡系统，会按用户的地理位置、运营商、实时负载情况，返回一组最合适的边缘节点。正常情况下，调度算法主要以就近和负载均衡为原则。当某个边缘节点开始过载，甚至正在承受攻击时，调度系统会把新产生的DNS解析请求导向其他健康节点，避免所有人都往同一个热点上挤。

这里有一个细节容易被忽略：DNS解析结果是有TTL的。如果TTL太长，新调度短时间内不会生效，用户会继续访问已经过载的节点。所以成熟的CDN服务商在攻击状态下会主动缩短TTL，同时要求边缘节点实时上报健康状态，一旦某个节点判定异常，调度系统能够在几十秒内完成流量切换。大促或护网期间，如果你发现业务流量集中到少数几个节点，优先检查前端调度策略和TTL设置，这往往比调清洗规则更见效。

1.3 稀释虽然关键，节点容量才是底气

有些朋友可能会问：是不是节点越多，稀释效果就越好？理论上这样讲没错，但如果单节点的带宽和清洗能力很弱，攻击被分散之后再小的一股流量也可能把一个边缘节点打瘫痪。所以CDN服务商在部署节点时，会选择运营商骨干网接入点，同时租用带防D能力的机房，配备专用的流量清洗设备和足够的带宽资源。单点容量高、节点数量多，两者叠加，才能形成真正扛得住T级攻击的地板。

这就像消防队救火，水枪再多，如果每条水管的压强都不够，照样浇不灭大火。实际做活动保障时，我会提前跟服务商确认目标峰值，并申请临时的带宽调度和容量冗余。很多厂商在活动期间是可以临时调整节点流量配比的，这部分能力平时不过问，等到攻击来了再申请，流程上会很被动。

2. 边缘清洗：从网络层到应用层的层层拦截

2.1 SYN Proxy：先替源站完成握手

流量型DDoS里最常见的就是SYN Flood，攻击者发送大量伪造源地址的SYN包，让服务器忙于维护半连接队列，最终耗尽连接资源。CDN边缘节点对付这类攻击，普遍采用SYN Proxy机制。客户端发来的SYN包先由边缘节点接收，边缘节点代替源站回SYN-ACK，如果客户端没有继续完成TCP三次握手，这个连接直接丢弃，根本不会到达源站。

只有完整通过握手的连接，边缘节点才会作为透明代理去和源站建立真正的TCP连接。这样做的好处是，攻击者伪造的半连接全部由边缘节点消化，源站看到的都是已经验证过的真实连接。边缘节点上的数据面通常基于DPDK或专用网络处理器实现，收包、校验、转发都在用户态完成，性能远高于传统内核协议栈。实际调优时，可以关注SYN Proxy的超时参数，太短会让弱网用户频繁断连，太长又会给边缘节点增加无谓的半连接消耗。

2.2 UDP反射放大：靠协议特征和限速过滤

UDP协议无连接且容易伪造源IP，攻击者常年用它发起反射放大攻击，比如向开放DNS、NTP、SSDP等服务发送小请求，伪造受害者IP作源地址，让这些服务把大流量响应打到受害者头上。CDN边缘节点对这些流量，通常会做几件事：校验源端口，原因是常见反射服务基本都是固定端口，来自非标准端口的异常大流量可以直接限速；检查UDP报文长度，放大攻击的响应包往往有明显特征；按包量或带宽做源IP限速，短时间内超过阈值就丢包或黑洞。

这一类清洗规则相对粗暴，误杀概率也高。比如有些游戏业务本身就大量使用UDP，如果限速策略设置不当，正常玩家的数据包也会被丢。建议先把业务常见的UDP端口、包大小分布整理清楚，再让服务商基于这些特征配置白名单或精细化限速，而不是默认执行全局限速。

2.3 连接型攻击：限制并发与识别慢速拖拽

除了打带宽，攻击者还喜欢消耗服务器的并发连接数，或者用慢速请求把连接占住不放。典型的慢速攻击是建立连接后，以极小的速率持续发送请求头，让服务器因为等待完整请求而一直占用连接。边缘节点在处理这类攻击时有天然优势，因为它本身承担客户端连接，源站不直接面对慢速客户端。

清洗设备通常会设置半连接超时、请求头超时和连接空闲超时，一旦发现某个连接长时间没有完整数据，直接断开。同时，边缘节点可以做单IP并发连接数限制，一个来源IP最多允许同时保持多少条连接。这个值不能拍脑袋，要结合业务类型。比如普通电商站点可能200条就足够了，但某些办公系统或API服务，办公网出口IP汇聚了大量用户，并发数设置太低会把正常用户误杀。

2.4 应用层攻击：识别HTTP Flood与浏览器挑战

应用层攻击的目标不是带宽，而是服务器计算资源。攻击者用真实或代理IP发起大量HTTP GET/POST请求，每个请求看起来都像正常用户，但QPS极高，能把源站CPU和数据库连接池打满。CDN边缘节点在Web层做防护时，通常结合几类手段。

第一是频率控制，按IP、按会话、按URL维度分别限制单位时间内的请求次数，超过阈值后触发告警或人机校验。第二是协议特征检测，检查User-Agent是否合法、HTTP方法是否合理、请求头顺序是否与正常浏览器一致，很多攻击脚本在这些细节上会露出马脚。第三是浏览器挑战机制，通过自动加载JavaScript、设置Cookie或弹出滑块验证，让真实浏览器自动通过，而脚本工具无法完成挑战。

这种应用层清洗是有代价的，挑战过程会多一次RTT，用户体验会有轻微下降。所以一般只在攻击触发时才开启严格模式，平时保持宽松模式。

2.5 清洗决策：不是所有流量都无脑丢

边缘清洗看起来是“见招拆招”，实际上背后有一个完整的决策链路。CDN节点会持续把流量特征上报给防护大脑，防护大脑结合全网攻击态势、基线数据、封禁情报，生成清洗规则下发给边缘节点。这里的核心不是把“像攻击”的全丢，而是尽量只丢确定恶意的流量。

为了让决策更准确，建议业务在正常时期保持流量基线，明确正常PV、UV、带宽、回源QPS是多少。这样攻击到来时，清洗系统可以动态调整阈值。我见过不少团队，平时不关注基线数据，攻击来了才临时把防护等级调到最高，结果正常用户也跟着遭殃。所以每次大促或活动前，把基线报表拉出来看一遍，比临时抱佛脚靠谱得多。

3. 回源保护：前端扛住了，源站不能掉链子

3.1 源站永远是不可替代的最后底线

CDN的分布式架构和清洗能力再强，最终业务数据还是存放在源站上。如果源站IP暴露，攻击者只需要绕过CDN，直接打源站，那前端所有稀释和清洗就全部白做了。流量型DDoS打不掉CDN，但打掉一个源站实例还是很容易的。所以真正的防护思路，是把源站当成最后一道需要重点保护的底线，而不是把所有希望都寄托在边缘节点上。

3.2 隐藏源站IP与加固回源链路

回到实际落地，源站防护可以分四步做。

1. 源站域名不要对外解析，业务访问统一指向CDN分配的CNAME域名，源站只作为回源目标存在。
2. 源站网络安全组或防火墙只放行CDN服务商的回源IP段，其他来源IP一律拒绝。这样可以屏蔽大量绕过CDN的直连流量。
3. 对回源请求增加自定义鉴权信息，比如要求携带特定的回源Header，源站校验不通过就直接拒绝。
4. 条件允许时启用双向TLS认证回源，也就是源站和CDN之间互相校验证书，确保回源链路可靠。

这些配置看起来简单，但实际运维里最常出现的问题是源站IP泄露。排查泄露源的时候，优先检查DNS历史解析记录、代码仓库里的服务器配置、证书透明度日志、第三方扫描平台等，这些地方往往藏着源站真实IP。发现泄露后，最快的办法是更换源站IP，同时在防火墙层全面加白CDN回源网段。

3.3 缓存策略：让回源量一降再降

源站的压力不只来自攻击流量，也来自正常业务的大规模回源。如果CDN命中率太低，每个用户请求都会穿透到源站，一旦流量峰值上来，源站照样扛不住。合理配置缓存策略，是让回源量下降最有效的手段之一。

静态资源比如图片、CSS、JavaScript，可以设置较长的缓存过期时间，直接在浏览器或CDN边缘命中。动态接口可以按参数维度设置缓存，也可以利用CDN的边缘合并回源能力，将相同资源的多个用户请求合并成一次回源。大文件下载还能通过分片回源，让CDN节点分段拉取源站数据，而不是整个文件反复回源。配置示例，只需要在源站响应头里加上合适的Cache-Control字段，比如：

Cache-Control: max-age=3600

这条响应头会告诉CDN和浏览器，内容可以缓存一小时。但动态业务不能盲目加缓存，建议先按页面模块拆开，只对非个性化内容做缓存，避免缓存了用户私有数据。

4. 配置与落地：从接入到复盘的关键步骤

4.1 接入CDN前的检查清单

接入CDN不是把域名CNAME解析过去就完事了，前置准备决定了攻击来临时能不能稳住。

• 确认源站是否稳定。如果源站本身经常5xx，CDN会把错误状态缓存下来，影响比不接入还大。
• 梳理业务动静态资源。哪些可以缓存，哪些必须回源，提前分类。
• 确认回源鉴权方式。特别是HTTPS业务，证书不要过期，回源SNI要正确。
• 测试CNAME切换后的访问质量。切之前找一个低峰窗口，把解析记录修改后的回源、缓存、跳转链路全部测一遍。

我见过很多团队，因为上线前没有检查源站的404状态码策略，活动期间大量不存在商品的URL被CDN缓存成404，用户看到的全是错误页。这类问题非常低级，但确实会在大流量期间被放大。

4.2 控制台上如何设置防护参数

CDN服务商控制台里的防护参数名可能不同，但核心逻辑大同小异。开启DDoS基础防护后，重点配置三个层面的内容。

第一是网络层清洗阈值。这个阈值表示触发清洗的最小流量或包速率数值。设置太接近正常峰值容易误伤，设置太高又会让小流量攻击透传到源站。建议以日常峰值两倍作为初始值，再结合观察调整。

第二是CC防护规则，也就是应用层防护。一般会提供“宽松、标准、严格”等模式。大促期间可以调到标准或严格，但要配套观察误杀率。如果出现正常用户被拦截，第一时间把防护模式降级，再根据攻击特征添加自定义规则。

第三是地区级封禁。如果业务明确不服务某些地区，可以提前封禁，减少攻击面。不过要注意，CDN的IP库可能不准，封禁地区会误伤部分使用跨境代理的正常用户，需要权衡。

4.3 监控、告警与复盘

防护参数调完，监控不能省。至少要把五类指标加到告警里：攻击峰值流量、WAF拦截量、CDN命中率、回源QPS、回源错误率。命中率一旦连续下跌，说明缓存策略可能失效，或者有大量不可缓存的动态请求在穿透源站；回源错误率上升，往往意味着源站已经被压到临界点。

每次攻击结束后，一定要做复盘。攻击源分布、攻击类型、持续时间、清洗前和清洗后的流量对比、正常服务是否受影响，这些数据都值得留档。下次再遇到同类型攻击，能参考的只有自己积累的基线数据。我习惯把每次攻击的核心截图和处置过程记录在一个文档里，虽然不一定会再遇到一模一样的攻击，但对判断防护策略的有效性非常有帮助。

5. 常见问题与排查技巧实录

5.1 正常用户被误杀

应用层清洗最容易出现误杀。比如某个员工集中办公出口的IP，因为NAT导致几百个用户共用一个出口IP，被频率限制规则一次性封掉。又比如老版本浏览器的TLS指纹不符合当前规则，被当成攻击拦截。

处置思路是先把误杀范围确认清楚，是某个地区、某个运营商，还是某种设备。确认方向后，可以临时调整对应规则或加白名单。但在攻击还持续的阶段，加白名单要克制，否则攻击者如果也使用相似路径，白名单就会变成大漏洞。正确做法是先用宽松模式恢复业务，同时观察攻击流量是否回落，再决定是否重新启用严格规则。

5.2 回源爆炸但CDN命中没有问题

有一种情况让人头疼：攻击流量不大，CDN节点也没有异常，但源站突然扛不住了。排查方向要回到回源链路。常见原因是动态请求全部回源，或者某些接口因为URL参数不固定导致缓存命中率极低。打开CDN访问日志，看一下回源QPS的分布，如果大量集中在少数动态接口，就需要给这些接口定制缓存策略或回源合并策略。

还有一种可能是回源链路走了公网，攻击者虽然没有直接打源站，但通过对CDN发起大量回源请求，让源站的公网出口带宽被耗尽。这个场景下，优先考虑把回源链路切到专线或内网，同时配置源站的单IP带宽限制。

5.3 攻击者绕过CDN直连源站

攻击者拿到源站真实IP后，会直接把攻击IP指向源站。表面现象是CDN侧攻击流量不高，但源站已经被打满。排查方法是看源站网络入口的流量监控，如果入方向带宽异常，而CDN上的日志和攻击报表都很平静，基本可以断定源站IP已经暴露。

应急处理分两步。第一步先通过防火墙封禁异常攻击源，恢复源站可用性。第二步立即更换源站IP，并重新加固防火墙规则，只放行CDN回源网段。事后一定要检查代码仓库、测试环境和第三方协作工具，找到泄露源，避免换完IP再泄露一次。

5.4 常见问题对照速查

这几点基本覆盖了我平时处理的大部分问题。但攻击是活的，规则和策略也需要跟着业务一起迭代。不要指望一套配置用一年，每次活动前做一次防护策略复核，比临时救火高效得多。

最后分享一点个人体会。见过不少团队在接入CDN后，把所有希望都押在“分布式架构能抗D”这一句话上，忽略了源站加固、缓存策略、基线监控这些基础工作。实际上CDN更像一个巨大的缓冲池，它能把攻击摊薄、能把异常挡在门外，但业务能不能撑住，最终还要看源站那根弦绷得紧不紧。把分布式稀释当成第一道防线，把清洗规则当成筛子，把源站防护当成最后底线，三层都守住，才算真正把CDN的防D能力用到位。