服务器遭受攻击后调整配置，验收时如何核对带宽、IP与网络冗余？

服务器遭受攻击后，配置调整不能只看“带宽升了多少”或“多配了几个 IP”。验收应按合同与变更单先确定可交付指标，再核对公网可用带宽、地址归属与路由、故障切换路径，并用受控测试验证。若带宽、IP 和冗余没有统一口径，单项看似达标，仍可能因为 CPU、内存、存储或网络链路形成短板。

验收前应具备变更前后的配置记录、服务商交付参数、业务端口和测试窗口；测试对象必须是自有或明确授权的主机，避免制造无关流量。以下步骤按低风险到高风险排列，涉及切换的测试应提前约定时间、影响范围和回滚方式。

先确定验收口径

先把“带宽”“IP”“冗余”写成可判定的指标。下表中的数值用于说明验收方法，不代表任何具体产品规格或实测结果；实际阈值应以合同、变更单和业务需求为准。

应特别区分“端口速率”和“带宽承诺”。例如，网卡协商为 1 Gbps，只能说明主机网卡与对端端口以该速率连接，不能证明公网方向持续提供 1 Gbps。还要确认计量方向、突发时长、限速位置、峰值统计周期，以及防护清洗后交付给源站的带宽口径。

攻击期间的流量也不能直接作为业务容量基线。应以攻击结束后的清洁流量、业务峰值和可接受余量估算需求；如果清洗平台、上游链路或主机端口中任一处更小，最终可用吞吐会受最小项约束。

按顺序核对带宽、IP 与冗余

1. 固化变更前状态和回滚条件

在改配置前记录当前地址、路由、接口状态、带宽监控和业务健康情况。至少保存以下信息：

• 服务器公网与内网地址、掩码、默认网关、静态路由及 DNS 记录。
• 网卡名称、链路状态、协商速率、MTU，以及操作系统和网络配置管理方式。
• 服务商确认的带宽、IP、清洗或回源路径、变更生效时间和工单编号。
• 变更前的 CPU、内存、磁盘使用率、网卡吞吐和丢包情况。
• 业务探测方式、负责人、允许中断时间，以及恢复原配置的操作步骤。

若使用远程管理通道修改网络配置，不要在没有控制台或带外管理能力时直接替换默认路由、清空地址或重启网络服务。先确保有可用的恢复入口，并为配置文件留备份。回滚条件应事先量化，例如公网探测连续失败、业务健康检查异常，或新路径丢包明显高于变更前基线；达到条件立即停止后续测试并恢复已确认可用的配置。

2. 核对主机看到的接口与地址

在常见 Linux 环境中，可先用只读命令查看接口、地址、路由和链路信息：

ip -br link
ip -br addr
ip route
ip -6 route

如果系统安装了 ethtool，可检查物理网卡协商状态：

sudo ethtool <网卡名>

把输出与交付参数逐项对照：接口是否处于 UP，地址是否完整，默认路由是否指向约定网关，IPv6 路由是否确有业务需要，链路速率和双工状态是否符合交付条件。虚拟化环境中，主机看到的可能是虚拟网卡，其显示的速率不一定等同于上游物理端口的公网能力，应以服务商提供的交付口径及监控记录补充验证。

如果地址或网关不符，先确认变更是否尚未生效、地址是否配置在上游设备、或服务是否通过独立的公网映射交付；不要仅凭主机内没有某个地址就判定交付失败。核实后仍不一致，应保存命令输出和时间戳，联系交付方确认地址路由及配置责任边界。

3. 验证可用带宽，而不是只看端口显示

带宽验收应至少结合三类证据：服务商侧限速或清洗交付记录、主机网卡计数器、受控端到端吞吐测试。测试前先确认测试端有足够带宽和处理能力，并与服务商约定测试窗口；单一测试端或单次短测不能证明全天候持续能力。

查看网卡统计与系统负载：

ip -s link show dev <网卡名>
sar -n DEV 1 10

ip -s link 可观察收发字节、错误和丢弃计数；sar 可观察采样期间的接口流量。若系统没有 sar，可使用现有监控平台的网卡吞吐和丢包曲线。注意计数器通常是累计值，判断测试期间新增错误或丢弃时要比较前后差值，不能把历史累计值直接当作当前故障。

端到端测试可在自有测试端和服务器之间使用 iperf3。先确认两端已安装对应工具、测试端口已获准通信，且测试流量不会影响生产业务。以下示例运行 30 秒，实际并发和时长应从低值开始：

# 测试端启动服务
iperf3 -s

# 服务器向测试端发送流量
iperf3 -c <测试端地址> -t 30

# 反向测试：由测试端向服务器发送
iperf3 -c <测试端地址> -R -t 30

测试结果应分别记录方向、持续时间、平均吞吐、重传或丢包信息、两端 CPU 使用率和网卡计数器。测试端 CPU 已满、磁盘写入被纳入测试、并发过高或路径不经过目标公网出口，都会让结果失去代表性。不要仅因一次结果低于标称值就认定线路不达标；应重复测试、排除端侧瓶颈，并对照服务商限速口径。若吞吐持续偏低且主机资源尚有余量，应将两端结果、时间、源目的地址、路由信息和服务商侧监控一并提交核查。

4. 逐个验证 IP 的归属、可达性和业务绑定

将交付的地址整理成清单，逐项标记用途、地址族、掩码或前缀、网关、配置位置、业务绑定和变更责任方。新增 IP 并不自动增加带宽；多个地址若共享同一网卡、同一上游链路和同一网关，通常仍共用这些资源。

逐个检查地址是否在预期位置配置、路由是否正确，并从授权的外部探测点验证：

• 到服务器的网络连通性是否符合预期。
• 业务端口是否在该地址上监听，且对应服务能否正常响应。
• 反向解析、访问控制或应用白名单是否仍使用旧地址。
• 如果配置了 IPv6，业务是否确实通过 IPv6 提供服务，而不是只有地址存在、路由或应用监听未完成。

可用以下命令检查监听情况和路由选择：

ss -lntup
ip route get <外部探测地址>

防护调整后尤其要核对公网入口与源站之间的关系：若业务入口经过清洗或其他上游防护，源站地址是否仍按约定方式接收流量、健康检查是否指向正确地址、旧地址是否仍对外暴露，都应由交付方案明确。不要在未确认业务依赖和回滚路径时直接删除旧地址、改 DNS 或替换默认路由。

若某个 IP 能连通但业务不通，依次检查路由、监听地址、主机访问控制和应用绑定；若主机侧配置无误而外部不可达，应核对上游路由、地址生效状态与防护策略。异常时保留该地址的配置输出、探测源和时间，不要把所有地址同时改动，否则难以定位问题。

5. 验证冗余覆盖了哪些故障

冗余不是数量，而是故障发生时是否存在独立且可用的替代路径。验收前先明确目标：要应对的是单个公网地址故障、单条链路故障、单台服务器故障，还是上游网络故障。不同目标需要不同设计，不能用一个“双 IP”结论代替。

核对项至少包括：

• 链路独立性：主备路径是否实际经过不同接口、上游端口或网络路径。若两条路径最终汇聚到同一设备或同一出口，仍可能存在共同故障点。
• 地址与路由切换：备用路径是否拥有可用地址和正确回程路由，切换后源地址是否符合应用、访问控制和对端白名单要求。
• 业务连续性：健康检查是否覆盖真实业务，而不只是能 ping 通；故障切换后新连接能否建立，已有连接中断是否符合预期。
• 恢复条件：主路径恢复后是否自动回切、是否存在频繁来回切换，以及人工介入方式是否明确。
• 服务器资源：备用路径启用后，CPU、内存、连接处理和日志写入是否仍有余量。

在获准的维护窗口内进行切换验证，先确认备用路径状态，再按预案切换一个故障点，观察外部探测、业务健康、路由变化和监控告警。记录切换耗时、丢包区间、失败请求数和恢复动作。测试结束后按预案恢复主路径，再验证路由和业务均回到预期状态。若没有独立备用链路或授权的切换手段，不要通过拔线、关闭接口等方式模拟故障；应将“未验证”明确列为验收遗留项，而不是判定冗余已通过。

结果如何判定，配置怎样保持平衡

验收结论要依据约定阈值，不能用“看起来正常”代替。可按以下方式解释结果：

• 带宽达标、业务仍慢：检查 CPU 是否持续饱和、内存是否发生交换、磁盘或日志写入是否受限，以及应用连接处理能力。扩带宽不会自动提升这些资源。
• 网卡速率达标、端到端吞吐偏低：核对服务商限速、测试端能力、路径拥塞、丢包与重传，再比较不同方向和时间段的结果。
• 单个 IP 可用、其他地址不可用：检查地址路由、监听绑定、上游策略及业务白名单；不要把地址数量当作链路冗余。
• 主路径正常、切换失败：通常说明备用地址、路由、健康检查、回程路径或应用状态至少有一项未纳入设计，需修正后重新做受控验证。
• 带宽测试中 CPU 或丢包先到阈值：先定位主机或链路瓶颈，不宜继续提高并发，否则测试会放大业务风险。

配置评估应采用同一业务峰值口径。比如，某网站攻击后清洁流量峰值约为 120 Mbps，验收目标可以按业务约定预留一定增长空间，而不是把网卡显示的 1 Gbps 直接当成可长期使用的带宽。假设应用在高峰时 CPU 已持续接近满载，增加公网带宽也可能只会让更多请求更快地堆积在应用层；若内存余量不足，新增连接可能引发交换或进程退出；若日志盘写入饱和，排障所需的访问记录也可能无法及时落盘。

因此，配置调整应按瓶颈顺序决策：先确认清洁流量和业务峰值，再看带宽与连接能力；检查 CPU、内存和磁盘是否能承接对应请求；最后确认 IP、路由和冗余是否满足故障目标。若服务器只有一条上游链路，增加地址不能替代链路冗余；若已经有备用路径但应用只监听主地址，网络切换仍无法保证业务恢复。每次调整尽量只改变一个关键变量，便于定位效果和回滚。

异常留证与复核清单

发现不一致时，先停止扩大变更范围，保存原始状态和时间信息，再按“主机配置—端到端探测—服务商侧交付”逐层定位。留证材料应包括：

• 变更单、配置前后差异、接口和路由输出、测试命令与完整结果。
• 测试时间、测试源与目标、方向、持续时间、样本次数、业务负载和服务器资源状态。
• 监控截图或导出数据，尤其是吞吐、丢包、接口错误、CPU、内存和磁盘指标。
• 外部探测结果、业务健康检查、切换与恢复时间、告警记录及对应工单。

每项验收结果标为“通过”“未通过”或“未验证”，并注明依据和责任方。修复后按相同测试条件复测，不能只凭配置文件已修改就关闭问题；涉及路由、地址或切换的修复，还要复核回程路径和业务监听。最后确认旧配置是否需要保留、回滚入口是否仍可用、监控告警是否覆盖新地址和备用路径，并把最终拓扑、地址清单、带宽口径及未完成事项交接给后续值守人员。