200G级DDoS攻击下香港服务器如何设计三层防护？从流量清洗到业务切换的落地流程

在200G级DDoS攻击下，香港服务器想维持业务连续性，不能只给单台服务器增加带宽，也不能把“接入清洗服务”当成完整方案。可落地的三层设计应当同时覆盖：上游流量清洗、清洗后的网络与源站接入、应用与数据副本。每一层都要有备用资源、明确的切换入口和可验证的回滚路径。

工程上的“业务零中断”应先定义清楚：攻击期间用户访问入口尽量保持不变，核心页面和交易接口持续可用，新增请求能够自动转移，已建立连接按照业务特性重连，数据损失不超过预设的RPO。它不等同于任何TCP连接永远不重置，也不意味着单台源站在硬件故障后仍能无感运行。若只有一台香港服务器、一个公网入口和一份数据副本，就无法通过流量清洗解决全部单点故障。

一、先确认三层防护分别解决什么问题

三层防护并不是把同一条规则重复配置三次，而是针对不同故障范围建立隔离。

第一层决定攻击流量能否在到达香港服务器前被拦截或清洗；第二层决定干净流量能否绕开故障节点；第三层决定攻击穿透到应用层后，核心业务是否仍有可用路径。

200G级攻击不只看带宽数字

200Gbps持续攻击10分钟，按十进制单位计算：

• 200Gbps × 600秒 ÷ 8 = 15,000GB；
• 也就是约15TB的攻击流量；
• 若攻击以大量小包为主，还会同时消耗包转发能力、连接跟踪表和防火墙状态资源。

因此，清洗能力不能只看“峰值带宽”，还要确认以下口径：

• 200G是单个受保护IP的能力，还是多个客户、多个资源池的聚合值；
• 清洗能力是突发上限还是可持续能力；
• 是否覆盖SYN、UDP、ICMP、分片包等攻击类型；
• 小包攻击下的包速率能力是否单独核算；
• 清洗后的可用带宽有多少，是否会被回源链路限制；
• 清洗节点、回源链路和路由入口是否存在单点；
• 从检测到开始清洗、从主路径切换到备用路径分别需要多长时间。

例如，业务正常峰值为5Gbps，攻击峰值按200Gbps估算，若预留约30%的规划余量，则参考容量为：

（200Gbps + 5Gbps）× 1.3 = 266.5Gbps

这不是固定采购标准，只用于说明为什么实际规划通常不能只按200G刚好配置。若攻击存在明显突发，或多个受保护IP可能同时被攻击，应进一步提高余量，并按照单IP、单清洗资源和单回源链路分别验算。

二、现状核对：先找出真正的单点故障

变更前不要直接修改DNS、路由或防火墙规则。先绘制一张从用户到数据存储的流量路径，至少记录以下对象：

用户 → 域名解析 → 清洗入口 → 清洗出口 → 负载均衡 → 应用节点 → 数据库或缓存

每个箭头都要能回答“如果这一段中断，流量会去哪里”。

1. 核对公网入口和源站暴露情况

重点检查：

• 域名当前解析到的是清洗入口、负载均衡地址，还是香港服务器真实公网IP；
• 历史解析记录、应用错误页、回源头信息中是否泄露过源站地址；
• 源站是否允许来自任意公网地址的访问；
• 清洗出口地址变更后，源站访问控制是否能够及时更新；
• IPv4、IPv6、管理入口和业务入口是否存在防护范围不一致；
• API、静态资源、上传入口、WebSocket等是否全部经过同一套保护路径。

如果攻击者仍能直接访问源站IP，第一层清洗即使正常工作，也只能保护通过清洗入口到达的流量。源站地址一旦被绕过，业务仍可能因为链路、连接表或端口资源耗尽而不可用。

2. 核对应用和网络节点是否只有一份

建立一张故障清单，区分“攻击防护单点”和“业务运行单点”。

3. 核对可用性目标，而不是笼统写“高可用”

每类业务应分别定义RTO、RPO和降级方式。

• RTO：故障后允许多长时间恢复；
• RPO：故障时允许丢失多长时间的数据；
• 降级方式：哪些功能可以暂时只读、延迟处理或关闭；
• 切换范围：只切换应用节点，还是同时切换数据主节点；
• 用户影响：是否允许重新建立连接、重新登录或重试。

例如，商品查询、公告和静态内容可以在攻击期间优先使用缓存或只读副本；订单创建、支付回调和库存扣减则需要保证幂等、顺序和数据一致性，不能简单地通过“多开一台服务器”解决。

三、变更准备：把备用资源从“存在”变成“可接管”

1. 先备份，再进行任何路径调整

变更前应保存并验证以下内容：

• 域名解析记录和TTL；
• 清洗策略、源站白名单、端口放行范围；
• 负载均衡监听器、后端池和健康检查配置；
• 应用版本、环境变量、证书和密钥引用关系；
• 数据库备份、复制状态和恢复步骤；
• 监控阈值、告警联系人和变更时间线。

只保留备份文件不算完成。至少要验证一次关键配置能否恢复，数据库备份要进行可读性或抽样恢复检查，应用副本要确认能否正常启动并连接到正确的数据服务。

涉及路由、DNS、防火墙和数据库主副本的变更，应提前记录原值、修改值、执行人、执行时间和回滚动作。这样出现异常时，回滚不是重新临场判断，而是按照已确认的步骤恢复。

2. 准备备用应用资源

备用应用节点不应只安装操作系统后闲置。至少要完成以下准备：

• 与主节点使用同一应用版本和依赖版本；
• 配置文件、证书、密钥引用保持一致；
• 健康检查接口不依赖不必要的外部服务；
• 静态文件、模板和规则文件已同步；
• 会话状态不依赖主节点本地内存；
• 后台任务具备去重或幂等机制；
• 备用节点不会绕过清洗入口直接暴露公网。

健康检查不能只检查端口是否打开。更有效的检查通常分为三层：

1. TCP或HTTP端口是否可连接；
2. 应用进程是否能返回正确状态；
3. 应用是否能访问必要的数据依赖。

如果只检查第一层，进程虽然存活，但数据库连接池耗尽、缓存不可用或关键配置失效时，负载均衡仍可能继续向故障节点分发请求。

3. 准备数据副本和接管规则

数据副本需要明确“能否读”“能否写”“何时提升为主库”。

建议至少记录：

• 当前主库和副本的复制延迟；
• 副本是否具备完整数据和必要索引；
• 主库与副本的切换方式；
• 切换过程中如何避免双主写入；
• 业务写入暂停时长；
• 副本提升后的回切方法；
• RPO和RTO的验收值。

如果业务允许最多丢失30秒数据，副本延迟就不能长期超过30秒；如果要求接近零数据丢失，则需要更严格的同步或事务设计。发现主库异常时，不应只看服务器是否能Ping通，还要核对复制状态、最后提交位置和未完成事务。没有完成隔离就直接提升副本，可能形成双主写入，导致回滚成本远高于短时间只读。

4. 准备两种切换方式

不同层级的切换入口应分开设计：

• 清洗层：路由切换、受保护IP切换或主备清洗路径切换；
• 网络层：负载均衡后端摘除、备用节点接管；
• 应用层：限流、缓存、只读模式、关闭非核心接口；
• 数据层：主副本切换或暂时冻结写入。

如果必须使用DNS切换，要注意TTL只是解析缓存建议值，并不能保证所有客户端在TTL到期后立即更新。长连接、运营商缓存、应用内DNS缓存也可能延长生效时间。因此，DNS更适合用于提前准备和备用入口，不应被当作唯一的秒级无感切换手段。

四、分步实施：按三层逐步接入，不要一次性大改

第一层：先把200G级攻击挡在源站之外

第一层的目标是让大流量攻击在到达香港服务器前被识别、分流和清洗。

落地时按以下顺序进行：

1. 为业务建立受保护入口，先确认业务域名、IP、端口和协议范围；
2. 将清洗策略设置为观察或低风险测试状态，确认正常业务不会被误拦；
3. 准备主、备用清洗资源或等效的冗余清洗路径；
4. 配置回源地址和回源端口，只允许清洗出口访问源站；
5. 使用测试域名或低风险业务入口验证清洗后的回源；
6. 确认源站直连已经被限制，避免攻击者绕过清洗；
7. 再将正式业务逐步导入受保护入口。

清洗策略要区分网络层攻击和应用层攻击。SYN洪泛、UDP洪泛等攻击主要消耗连接和链路资源；而HTTP请求洪泛即使带宽不大，也可能通过高成本接口拖垮应用。前者需要清洗和协议识别，后者还需要第二层和第三层的连接限制、请求频率控制以及接口级保护。

源站白名单配置时要留意两个问题：

• 清洗出口地址可能有多个网段，且可能发生调整；
• 监控探针、运维入口和业务回源来源不能混为一谈。

如果白名单只写入当前看到的一个地址，清洗路径切换后可能出现“攻击被挡住了，但正常请求也回不了源站”的情况。

第二层：让干净流量能够绕开故障节点

第一层清洗成功后，干净流量仍可能造成以下压力：

• 大量正常TCP连接占满单台节点；
• 连接复用配置不合理，导致文件描述符耗尽；
• 某个接口响应慢，拖住工作线程；
• 单台应用服务器故障；
• 清洗出口到源站之间的回源链路拥塞。

因此，第二层至少应具备两个可接管的应用节点，并通过负载均衡进行健康检查。若业务规模较大，还需要准备备用负载均衡入口或第二条回源路径。

切换逻辑应遵循：

1. 先从后端池摘除异常节点；
2. 观察新请求是否稳定进入健康节点；
3. 确认会话、认证和数据请求没有大面积失败；
4. 再决定是否将备用节点扩容到承载主要流量；
5. 不要在应用节点、清洗路径和DNS入口同时变更。

如果应用依赖本地Session，切换节点后可能出现登录失效或反复跳转。生产环境应将会话放到可共享的会话存储中，或者采用能够容忍节点变化的无状态认证机制。对于WebSocket、长轮询等长连接业务，要单独验证连接重建和订阅恢复，不能用普通短请求的成功率代替验证。

第三层：限制攻击对应用和数据的影响

当攻击流量已经经过网络清洗，仍有可能以“看起来合法”的请求进入应用层。此时应按照业务成本划分接口：

• 静态内容和低成本查询：优先缓存；
• 高频查询接口：设置单用户、单IP或单会话的合理频率限制；
• 登录、搜索、报表等高成本接口：增加并发控制和超时；
• 订单、支付、库存等核心写入：保持幂等键、状态校验和重复提交保护；
• 非核心任务：转入队列或暂时暂停；
• 允许降级的页面：切换到只读数据或预生成内容。

限流不能简单地“一刀切封锁所有来源”。清洗层可能会对源地址进行转换，应用看到的客户端IP不一定是用户原始地址。应先确认真实来源字段、可信代理范围和日志记录方式，再设置限流维度，否则可能因为错误识别导致大量正常用户被一起限制。

数据库切换应放在应用切换之后或按照经过验证的顺序执行。若只是应用节点故障，不要为了追求“全链路切换”而随意提升数据库副本。只有在主库明确不可用、复制状态可接受、旧主库已隔离且业务方确认写入策略后，才执行数据主副本切换。

五、攻击发生时的实际切换流程

下面是一套适用于生产环境的顺序，具体入口取决于实际清洗服务和网络架构。

第一步：确认是攻击还是普通流量峰值

先查看带宽、包速率、连接数、SYN状态、UDP协议分布、HTTP状态码和应用延迟。判断重点包括：

• 带宽是否突然远高于历史峰值；
• 包速率是否异常，但带宽并不高；
• 单个协议、端口或来源分布是否集中；
• 应用请求是否明显增加但业务转化没有同步增长；
• 只有某个接口变慢，还是所有端口都受到影响。

不要因为带宽升高就直接切换数据库，也不要因为HTTP错误增加就立刻修改路由。先确定故障处于哪一层，才能减少无效变更。

第二步：启用或扩大第一层清洗

将受攻击入口导入主清洗路径，确认清洗状态已经生效。此时不要马上把所有业务入口都改掉，先选择测试域名、低风险子域名或可控业务路径进行验证。

需要观察：

• 清洗后回源流量是否回到业务可承受范围；
• 源站公网入口是否仍然收到大量攻击包；
• 正常请求的状态码和延迟是否恢复；
• 清洗出口到源站的链路是否出现新的瓶颈；
• 管理和监控访问是否被误拦。

如果主清洗资源达到容量上限，或清洗出口无法回源，不应把流量直接退回裸源站，而应切换备用清洗路径或进入业务降级模式。

第三步：切换第二层的应用承载

当清洗路径稳定后，根据健康检查结果处理应用节点：

1. 摘除已经出现连接耗尽或响应超时的节点；
2. 将新增请求导向备用节点；
3. 保留少量低风险流量验证会话和数据访问；
4. 确认备用节点错误率、延迟和资源使用率；
5. 再逐步提升备用节点的承载比例。

如果使用DNS切换，只能把它视为较慢的备用方案。对于需要较快切换的业务，应优先使用稳定的受保护入口、负载均衡或路由级接管方式，避免用户持续访问旧的裸源站地址。

第四步：启用第三层限流和业务降级

若清洗后带宽正常，但应用仍然被拖慢，说明攻击可能已经转为七层请求或高成本接口消耗。此时按照业务优先级处理：

• 保留首页、登录状态检查、订单查询等必要功能；
• 暂停非核心报表、批量导出和高消耗搜索；
• 降低单用户并发；
• 对重复请求启用缓存或短时间合并；
• 将可延迟任务放入队列；
• 必要时切换只读模式，避免数据库写入继续扩大压力。

降级开关应在攻击前就准备，并且每个开关都要有恢复条件。临时手工修改大量接口规则，容易造成误封、漏限和回滚困难。

六、验证方法：用可量化指标判断是否真的接管成功

不建议通过自行发起攻击来验证防护能力。可以使用服务方认可的流量演练、路由切换演练、健康检查故障模拟和受控业务压测，分别验证不同层级。

验收指标参考

例如，业务可以把“RTO不超过60秒、核心接口错误率低于1%、副本延迟不超过30秒”作为内部验收参考值。但这些数字必须根据业务实际确定，不能将示例阈值直接当作所有香港服务器方案的通用标准。

不同结果分别意味着什么

• 清洗后源站入口流量仍接近攻击峰值：可能存在源站IP泄露、IPv6入口遗漏、清洗规则未覆盖端口，或攻击者绕过了保护入口。
• 源站流量下降，但用户错误率不降：重点检查回源链路、负载均衡健康检查和应用依赖。
• 应用节点资源下降，但数据库延迟继续升高：说明瓶颈已经转移到数据层，应减少高成本写入或进入只读模式。
• 主节点恢复，但备用节点大量报错：可能是配置、证书、会话或数据副本不同步，不能继续扩大流量。
• 网络监控显示正常，订单仍重复或丢失：需要检查幂等设计、消息队列和数据库事务，不应继续调整网络路由。
• 只有部分用户失败：可能与DNS缓存、IPv6路径、长连接、地区运营商缓存或客户端重试策略有关，不能只看单个监控探针。

七、按可用性目标选择方案，不要只比较防护峰值

不同方案的成本差异，通常不只来自清洗带宽，还来自备用节点数量、冗余链路、数据副本类型、自动化切换和日常演练频率。

选择时至少核对以下内容：

1. 防护口径：是单IP、单业务还是聚合容量；
2. 协议范围：是否覆盖实际使用的端口和协议；
3. 清洗后的回源能力：是否有足够的干净带宽和备用链路；
4. 切换机制：是人工、半自动还是自动，切换动作由谁执行；
5. 源站隐藏能力：源站是否能限制为清洗出口访问；
6. 数据接管能力：是否有可验证的副本、恢复和回切步骤；
7. 日志与审计：能否看到检测、清洗、回源和切换的时间线；
8. 演练限制：是否支持在不发起真实攻击的情况下验证路由和业务接管；
9. 计费变量：带宽峰值、清洗时长、备用资源、回源流量和额外IP等是否分别计算。

如果业务只是展示型网站，优先投入清洗入口、缓存和备用应用节点，未必需要复杂的数据库自动切换。如果业务涉及持续写入、订单或支付，数据副本、幂等和接管演练的重要性会高于单纯增加清洗峰值。

八、回滚条件：攻击期间也不能回到裸源站

回滚不是简单地“恢复之前的配置”。在攻击尚未结束时，如果之前的路径没有清洗保护，直接回滚可能把流量重新引回源站。

应明确触发回滚或再次切换的条件

出现以下任一情况，应暂停扩大变更，并评估切换备用路径：

• 清洗后源站入口仍持续接收异常高流量；
• 清洗出口或回源链路达到容量上限；
• 核心接口错误率持续超过业务阈值；
• 应用节点出现连接耗尽、频繁重启或线程堆积；
• 备用数据副本延迟超过RPO要求；
• 发现主副本和备用副本同时接受写入；
• 切换后出现大面积重复订单、数据不一致或回调丢失；
• 路由在主备之间反复抖动；
• 新规则误封大量正常用户，且无法快速缩小影响范围。

推荐的回滚顺序

1. 先保留防护，再回退业务承载

如果问题出在备用应用节点，先将流量退回经过清洗保护的健康节点，不要退回未保护的公网源站。

1. 只回退有问题的变更项

清洗路径正常、应用节点异常时，只恢复应用后端池；不要同时撤销清洗和网络入口。

1. 数据主副本切换后谨慎回切

如果备用副本已经提升为主库，不能直接把旧主库重新接回写入。应先冻结或限制写入，核对数据差异，完成一致性处理后再安排回切。

1. 保留降级模式作为中间状态

如果全量恢复会再次触发过载，可以先保留只读、缓存和限流，等待攻击下降和资源稳定后再逐步恢复非核心功能。

1. 记录每次切换的时间点和指标

将路由变化、清洗状态、节点摘除、数据切换和业务错误率关联起来，避免因为多个时间点混杂而无法判断真正原因。

观察窗口与最终恢复

切换完成后，不要因为首页能够打开就立即宣布恢复。可以设置一个分阶段观察窗口：前30分钟重点查看带宽、包速率、源站入口、错误率和副本延迟，随后继续观察2至4小时的业务交易、长连接重建、后台任务和数据一致性。攻击仍在持续时，还要保持备用清洗路径和降级开关可用。

只有在清洗入口稳定、源站不再暴露、应用节点有余量、数据副本状态正常、核心交易连续成功，并且观察窗口内没有触发回滚条件后，才逐步恢复非核心业务。若任一核心指标重新越过阈值，应优先切换到备用清洗路径或降级模式，而不是直接撤销防护配置。这样设计，香港服务器的三层DDoS防护才不只是一次性的流量拦截，而是包含备用资源、数据副本、网络冗余和可控切换成本的完整业务连续性方案。