香港服务器遭遇DDoS时如何验证三层防护？用流量、丢包与回源状态判断业务影响

单看“入口流量被拦截”不能证明香港服务器在DDoS期间没有业务影响；单看服务器CPU、带宽或Ping丢包，也可能把线路抖动、ICMP限速或应用自身过载误判为攻击结果。可靠的验收方式，是把同一时间窗口内的攻击流量、清洗后流量、外部探测丢包、TCP连接状态、回源流量和HTTP响应放在一起看。

建议按由外到内的顺序排查：先确认攻击是否在防护入口被识别和消化，再观察清洗后流量有没有异常压向源站，随后用TCP/HTTPS探测判断用户侧丢包与响应，最后结合回源成功率、状态码、延迟、CPU、内存、I/O和连接队列确认业务是否真正受影响。只有这些指标在同一时间线上互相印证，才能判断三层防护是否接近“200G级攻击下业务零中断”的验收目标。

一、先明确三层防护分别要证明什么

这里的“三层”可以按实际验收对象理解为网络流量层、连接传输层和应用回源层，并不等同于单纯查看OSI模型中的三个层级。

“业务零中断”也不应简单理解为任何时间、任何探测包都不能丢。更适合验收的表达是：在约定的攻击窗口内，正常用户仍能建立连接并获得预期响应，业务错误率和延迟不超过既定SLO，源站没有接收到与攻击规模等量级的异常流量。

如果没有提前约定阈值，可以先采用一组参考目标：

• 防护入口能够记录攻击峰值，且源站入口流量不随攻击峰值同比增长。
• 外部TCP或HTTPS探测持续成功，短时ICMP丢包不能单独作为失败依据。
• 回源连接成功率保持稳定，没有持续增长的连接超时、重置、502或504。
• 业务接口的P95/P99延迟、5xx比例和超时比例仍在业务可接受范围内。
• 源站CPU、内存、磁盘I/O、网卡队列和连接队列没有因异常流量持续打满。

这些数值应结合业务SLO、源站容量和防护服务的约定确定。没有产品资料或实际监控数据时，下面的数值仅用于说明判断方法，不代表某个具体服务的承诺。

二、第一步：建立统一的观察窗口

排查时最容易出现的问题，是入口平台显示的是14:00:10，源站监控显示的是14:01:00，外部探测又使用了另一个时区。时间对不齐后，即使每个指标都真实，也无法判断因果关系。

建议至少记录四类时间点：

1. 攻击开始前的基线窗口：通常取攻击前10至30分钟，记录正常带宽、PPS、QPS、连接数、延迟和错误率。
2. 攻击上升窗口：重点观察流量从正常水平进入峰值的过程，判断防护是否及时生效。
3. 攻击稳定窗口：不要只看峰值瞬间，还要观察持续5至15分钟后的源站和业务状态。
4. 攻击结束及恢复窗口：记录清洗解除、回源恢复、连接回收和应用延迟恢复所需的时间。

监控采样周期也要区分。五分钟平均值适合观察总体趋势，但可能掩盖持续几秒的高PPS攻击。建议同时保留：

• 1秒或10秒级的峰值流量、PPS、TCP新建连接数；
• 1分钟级的带宽、QPS、错误率和延迟；
• 5分钟级的CPU、内存、I/O和连接数趋势。

在源站侧，先确认网卡名称，再执行只读检查。不要直接假设网卡一定叫eth0：

ip -br link
ip -s link
ss -s
nstat -az

如系统已安装相应工具，可进一步观察一段时间内的变化：

vmstat 1 10
iostat -xz 1 10

不同Linux发行版的nstat指标名称可能略有差异，重点关注TCP重传、连接超时、监听队列溢出以及网卡丢包计数，不要因为某个字段名称不同就停止判断。

需要特别注意单位。防护平台常以Gbps或Mbps显示比特速率，服务器网卡统计可能以字节计数累计。200Gbps按十进制换算约为25GB/s，即：

200Gbps ÷ 8 = 25GB/s

这只是速率单位换算，实际还会受到协议头、采集口径和统计周期影响。不能把200Gbps直接与源站某个累计字节计数进行比较。

三、第二步：先看攻击流量有没有在入口被消化

1. 入口流量要看峰值、PPS和协议分布

在防护入口查看以下指标：

• 攻击入口峰值带宽；
• 攻击峰值PPS；
• TCP、UDP、ICMP及其他协议占比；
• 被清洗、被丢弃、被转发的流量；
• 清洗策略生效时间；
• 清洗后向源站或回源通道发送的流量；
• 保护对象是否发生切换、绕行或降级。

攻击流量达到200G级别时，不能只看一条“带宽曲线”。低带宽高PPS的连接型攻击，可能比高带宽低PPS的流量型攻击更快耗尽连接表或CPU；UDP攻击和TCP攻击的处理路径也可能不同。

应区分三个概念：

• 入口攻击流量：防护入口看到的总流量，不等于源站实际收到的流量。
• 清洗后业务流量：经过策略处理后，认为需要继续转发的流量。
• 源站入站流量：真正到达香港服务器网卡或回源接口的流量。

如果入口出现200Gbps攻击峰值，而源站入站始终只维持在正常业务量附近，同时外部HTTPS探测正常，这通常说明网络流量层的隔离是有效的。但这还不能证明连接层和应用层没有问题，仍要继续检查回源状态和业务响应。

2. 用关联指标排除“看起来清洗成功”的误判

可以按照下面的关系判断：

入口流量和源站流量之间不必保持固定比例。存在缓存、压缩、长连接、协议封装或多级代理时，清洗后流量与源站流量的字节比会变化。验收重点不是追求某个固定比例，而是确认攻击峰值没有未经处理地传递到源站，并且业务请求仍能完成。

3. 不要用五分钟平均值掩盖短时攻击

例如，攻击持续20秒、峰值200Gbps，随后恢复正常。如果监控按五分钟平均，曲线可能只有十几Gbps，无法反映设备是否承受住了瞬时冲击。因此验收记录至少要保留：

• 瞬时峰值；
• 峰值持续时间；
• 进入清洗的时间；
• 清洗后流量的峰值；
• 源站入站的最大值；
• 业务探测在峰值前后是否出现连续失败。

如果平台只提供五分钟粒度数据，应向防护服务侧索取事件明细或峰值记录，不能仅凭平均曲线判定“200G攻击已验证”。

四、第三步：用丢包和连接状态判断传输层影响

1. ICMP丢包只能作为辅助指标

Ping适合观察基础可达性和路径变化，但它不能直接代表HTTPS业务是否正常。防护平台、路由设备和服务器都可能对ICMP限速或降优先级，因此可能出现“Ping丢包，但网页正常”的情况。

外部探测应至少同时使用三类结果：

1. ICMP探测：观察基础路径是否出现明显变化；
2. TCP连接探测：观察目标端口是否能完成连接；
3. HTTPS业务探测：观察TLS、HTTP状态码、首字节时间和完整响应。

丢包率可以用简单方式计算：

丢包率 = （发送探测包数量 - 收到响应数量）÷ 发送探测包数量 × 100%

例如发送200次TCP探测，成功建立连接198次，连接层失败率就是1%。但这仍需结合探测节点数量和时间段判断。单个节点的两次失败可能是本地网络抖动，多个不同运营商、不同位置的探测点同时失败，可信度更高。

2. TCP连接比Ping更接近业务事实

源站或边缘侧需要观察：

• 新建连接速率；
• 已建立连接数；
• SYN_RECV数量；
• TCP重传和超时；
• 连接重置；
• 监听队列溢出；
• 回源连接建立时间；
• 回源连接失败和重试次数。

在源站上可以使用以下只读命令查看当前概况：

ss -s
ss -ant state syn-recv
nstat -az

如果SYN_RECV快速增长、TCP重传和超时同步上升，而外部TCP探测也出现失败，说明连接传输层已经受到压力。此时不能仅看CPU是否低，因为连接表、监听队列或边缘到源站的中间设备可能先达到限制。

相反，如果SYN_RECV没有异常，TCP连接成功率稳定，但HTTP响应变慢或出现大量5xx，问题更可能位于应用处理、数据库、磁盘I/O或回源服务，而不一定是网络层丢包。

3. HTTPS探测应记录完整时延分段

建议对固定的健康检查页面或轻量业务接口进行探测，记录DNS、TCP、TLS、首字节和总耗时：

curl -sS -o /dev/null \
  -w 'http_code=%{http_code} remote_ip=%{remote_ip} connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/health

示例中的域名和路径需要替换为实际业务地址。探测页面应尽量避免触发写操作、登录、支付或大文件下载。

结果可以这样拆分：

• time_connect升高：重点看TCP建立、路径或边缘连接层；
• time_appconnect升高：重点看TLS握手、边缘资源或连接复用；
• time_starttransfer升高但连接时间正常：重点看回源和应用处理；
• http_code出现502/504：重点看边缘到源站的连接、回源超时和源站响应；
• http_code保持正常但页面业务失败：健康检查过于简单，需要增加真正能反映业务状态的只读接口。

4. 用不同探测位置排除线路误判

至少保留两个以上外部探测位置，条件允许时选择不同网络出口。若只有一个节点出现丢包，而其他节点HTTP状态码、TCP连接和延迟均正常，优先排查该节点到香港服务器之间的线路问题。

若所有探测点的ICMP都丢包，但TCP和HTTPS正常，可能是ICMP策略或优先级变化。若TCP和HTTPS都失败，且防护入口没有异常流量转发，则需要继续检查边缘路由、端口策略、连接层防护和回源健康状态。

路径追踪工具可以辅助观察路径变化，但中间节点出现星号不等于业务丢包。许多路由设备不响应或限制路径探测包，最终判断仍应以TCP和HTTPS结果为主。

五、第四步：重点检查回源状态，而不是只看回源带宽

回源状态是连接防护和应用防护之间的连接点。攻击流量被挡在入口之后，如果清洗节点无法稳定连接源站，用户仍然会看到超时、502或504。

1. 回源侧需要同时观察五类数据

如果业务使用缓存或反向代理，回源请求数不应简单等同于用户请求数。缓存命中率提高时，用户侧请求可能增加，但源站QPS不一定同步增加；缓存失效或绕过缓存时，源站QPS又可能快速升高。因此应同时查看边缘请求数、缓存命中率、回源请求数和源站应用QPS。

2. 源站资源要与回源流量放在同一时间线上

推荐把以下曲线叠加到同一面板：

• 源站入站和出站带宽；
• 回源连接数和连接失败数；
• HTTP请求数、2xx、4xx、5xx；
• P95/P99响应时间；
• CPU使用率及负载；
• 内存和交换分区使用；
• 磁盘I/O等待；
• 应用线程池、连接池或请求队列；
• TCP重传、连接超时和监听队列。

典型判断如下：

• 源站流量稳定，CPU和I/O正常，HTTP错误率稳定：源站基本没有被攻击流量拖垮。
• 源站流量不高，但CPU高、队列高、响应变慢：可能是应用计算、慢查询、线程池或连接池问题。
• 源站入站流量明显升高，同时回源失败和5xx升高：需要检查清洗后流量是否过多，或回源策略是否没有限制异常请求。
• 源站流量正常，但回源连接失败增加：可能是边缘到源站的连接通道、端口策略、健康检查或连接数上限问题。
• 源站CPU、内存、I/O均正常，但用户侧丢包明显：优先回到边缘服务和网络路径排查，而不是立即扩大源站规格。

3. 源站不能只看带宽

低带宽攻击也可能造成明显影响。例如，攻击流量本身只有几百Mbps，但包含大量新建连接，导致SYN_RECV、连接跟踪或应用线程池耗尽。反过来，数十Gbps的攻击如果在入口被充分清洗，源站可能只看到正常的几Mbps或几十Mbps业务流量。

因此，“源站带宽没有跑满”不等于“源站没有受到影响”，必须同时查看PPS、连接数、重传、请求队列和应用错误率。

六、用多指标联动排除几种常见误判

场景一：防护入口显示攻击峰值，用户访问正常

示例数据如下，数据仅用于说明判断方法：

这种结果说明攻击峰值主要停留在防护入口，源站流量只小幅变化，业务指标也没有出现持续性恶化。若TCP握手、回源成功率和源站资源曲线同样稳定，可以认为三层防护达到了较好的业务隔离效果。

场景二：清洗后流量和源站流量同步升高

此时不能因为入口存在“清洗动作”就判定防护成功。需要检查策略是否只识别了部分攻击、是否将大量异常连接当作合法请求放行、是否存在绕过清洗入口直达源站的路径，以及清洗后的回源带宽或连接容量是否不足。

场景三：Ping丢包，但业务没有异常

如果Ping丢包从0.5%升至8%，但TCP连接成功率、HTTPS状态码、P95延迟、回源成功率和源站资源都保持稳定，优先考虑ICMP限速、探测节点策略或路径设备对ICMP的低优先级处理。

这类结果不能直接写成“防护导致8%业务丢包”。应改用HTTPS探测、TCP连接探测和真实业务接口验证业务影响。

场景四：入口流量正常，但源站业务变慢

如果防护入口没有攻击峰值，源站入站流量却升高，同时CPU、I/O等待、线程池或数据库连接池异常，可能是合法访问增长、缓存失效、应用慢查询或内部任务造成的。此时扩大DDoS清洗能力未必能解决问题，需要先确认应用和回源请求是否出现变化。

场景五：只有一个探测点失败

单一探测点失败时，先记录该节点的运营商、出口、目标IP、DNS解析结果和失败时间，再与其他节点对比。如果其他位置正常，不应立即判定香港服务器整体中断；如果多个位置同时出现TCP和HTTPS失败，且边缘与回源指标也同步异常，才更接近全局业务影响。

七、200G级攻击场景的验收记录应该怎么写

200G级别的验收重点不是让源站承受200Gbps，而是证明这类攻击规模没有按照同等量级传递到源站，并且合法业务仍然可用。

一份有效的验收记录至少包括：

1. 攻击或验证事件的开始、峰值、持续时间和结束时间。
2. 入口测得的峰值Gbps、PPS、协议类型和攻击特征。
3. 清洗节点的丢弃量、放行量和清洗后转发量。
4. 源站网卡入站、出站、PPS和连接数峰值。
5. 外部探测的TCP成功率、HTTPS成功率、丢包率和P95/P99延迟。
6. 回源连接成功率、超时数、502/504数量及源站HTTP状态码。
7. 源站CPU、内存、I/O等待、请求队列和连接队列。
8. 攻击结束后恢复到基线所需时间。

如果要进行主动验证，不应自行制造大规模攻击流量。应通过防护服务商或具备授权的测试方安排受控验证，明确测试对象、时间窗口、峰值范围、停止条件和联系人。没有真实攻击事件时，可以先做低风险的业务可用性探测和配置检查，再用平台提供的历史事件记录或受控演练报告验证清洗能力。

八、修复后如何复测，才能证明问题已经解决

发现异常并调整策略、回源路径或防护参数后，不要只看“告警已恢复”。应使用与首次故障相同的探测节点、相同的URL、相近的时间粒度和相同的指标集合进行复测。

建议按以下顺序执行：

1. 保存调整前证据

导出入口流量、清洗后流量、源站流量、回源错误、探测结果和资源曲线，标记配置变更时间。涉及防火墙、路由或访问策略调整时，应先备份原配置并记录影响范围。

1. 确认新配置已经生效

核对防护对象、解析指向、回源地址、健康检查、端口策略和策略版本。不要只凭控制台显示“已启用”判断实际流量已经经过新的防护路径。

1. 先做无攻击状态验证

从多个外部节点执行TCP和HTTPS探测，确认正常访问、证书、状态码和延迟没有因新策略误伤。检查源站只能接收预期的回源流量，避免出现部分请求绕过防护入口。

1. 进行受控压力或事件复核

若需要验证攻击处理能力，由授权测试方按照预定范围执行；若没有攻击演练，则使用历史攻击窗口与当前正常窗口做指标对照。重点比较源站入站是否被隔离、回源是否成功以及业务SLO是否保持。

1. 观察恢复阶段

配置修复后继续观察至少一个完整业务高峰或约定的稳定窗口，确认没有延迟出现的连接泄漏、队列堆积、内存增长、磁盘写满或回源重试风暴。

1. 保留回滚路径

如果策略调整导致正常请求被拦截、回源失败或延迟异常，应按变更记录回滚到上一版本，而不是在故障期间连续叠加多个未知修改。涉及源站配置、路由或访问控制的变更，必须确认回滚不会暴露源站或中断现有连接。

修复后的合格结果，不是某一条曲线恢复正常，而是同一时间窗口内形成闭环：入口攻击量升高，清洗后和源站入站保持受控，外部TCP/HTTPS探测稳定，回源成功率没有持续下降，应用错误率和延迟没有超过目标，源站资源也没有出现新的瓶颈。

九、下一次告警时应同时观察哪些指标

为了避免再次陷入“只看带宽”或“只看Ping”的误判，可以固定一组联动面板：

• 入口组：攻击Gbps、攻击PPS、协议分布、清洗量、丢弃量、清洗后转发量；
• 网络组：TCP握手成功率、SYN_RECV、重传、连接超时、外部TCP丢包；
• 回源组：回源连接数、回源成功率、回源超时、源站入站流量、502/504；
• 应用组：QPS、2xx/4xx/5xx、P95/P99、健康检查成功率；
• 资源组：CPU、内存、I/O等待、网卡丢包、监听队列、线程池和连接池；
• 探测组：不同外部节点的TCP成功率、HTTPS状态码、首字节时间和总响应时间。

最终判断可以归纳为一个关联关系：攻击入口是否升高，清洗后是否受控，源站是否只收到合法或可承受的回源流量，外部连接和HTTPS是否成功，应用与系统资源是否保持在目标范围内。 这组指标同时成立，才有依据说明香港服务器的三层DDoS防护在200G级攻击场景下实现了业务影响隔离；如果只有其中一项正常，仍需要沿着流量、丢包、回源和应用状态继续定位。