香港服务器交付后如何验收？检查三网路由、CPU、硬盘与实际带宽

同一台香港服务器，电信、联通、移动测试节点可能出现不同的延迟、路由跳数和下载速度；服务器本机测速正常，也不能证明中国内地用户访问时三网都稳定。因此，交付验收不能只截取一次测速页面，而应固定测试节点、运营商、时间、方向和工具，分别检查三网路由、CPU、硬盘与实际带宽，并保留可复现的原始记录。

先固定测试条件，再确定验收指标

测试前记录以下信息：

• 香港服务器公网 IP、操作系统、网卡名称和测试端口；
• 测试节点所在城市及运营商，至少区分电信、联通、移动；
• 测试日期、时间和时区，注明业务高峰或低峰；
• 测试方向：测试节点访问香港服务器，或香港服务器向外发送；
• 工具及参数，例如 MTR 探测次数、FIO 块大小和并发数、iperf3 并行连接数；
• 测试时的 CPU、内存、磁盘 I/O、网卡流量、连接数及其他业务负载。

三网直连或线路质量不能只从香港服务器本机判断。服务器执行 traceroute，反映的是服务器访问外部目标的路径；要检查电信、联通、移动用户访问服务器的路径，应分别从三类运营商的测试节点向服务器发起探测。

建立空载基线，避免测试结果失真

先确认系统和资源状态。以下命令适用于常见的 Debian、Ubuntu、CentOS、Rocky Linux 等发行版，但网卡名称和软件包管理器应以实际系统为准：

cat /etc/os-release
uname -a
nproc
free -h
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT
ip -br addr
ip -s link

进一步查看 CPU 型号、核心数、频率和当前负载：

lscpu
grep -E 'model name|cpu MHz' /proc/cpuinfo | head
uptime
top
ps -eo pid,ppid,comm,%cpu,%mem,state --sort=-%cpu | head -n 15

若刚交付的服务器正在执行初始化、备份、日志压缩或安全扫描，应先记录任务状态，不要在未确认业务影响前直接结束进程。验收前应形成一份空载基线：CPU 是否长期接近满载、内存是否不足、磁盘是否被大量占用。否则，CPU、硬盘和带宽测试可能测到的是业务任务或系统资源争用，而不是实例本身的能力。

从三类运营商节点检查三网路由

在测试节点安装工具。Debian 或 Ubuntu 可执行：

sudo apt update
sudo apt install -y mtr-tiny traceroute

CentOS、Rocky Linux 等系统通常执行：

sudo dnf install -y mtr traceroute

完成后确认版本：

mtr --version
traceroute --version

将 SERVER_IP 替换为香港服务器公网 IP，从电信、联通、移动节点分别执行：

mtr -rwzc 100 -i 0.2 SERVER_IP

其中，-r 输出报告，-w 扩大列宽，-z 尝试显示 AS 信息，-c 100 发送 100 次探测，-i 0.2 表示每 0.2 秒探测一次。若 ICMP 受限，可选择实际开放并承载业务的端口进行 TCP 探测，例如 HTTPS 的 443 端口：

sudo mtr -rwzc 100 -T -P 443 -i 0.2 SERVER_IP

不同 MTR 版本的参数可能存在差异，执行 mtr --help 核对即可。建议按运营商和时间保存原始报告：

mtr -rwzc 100 -i 0.2 SERVER_IP > mtr-report-telecom-YYYYMMDD-HHMM.txt

判断时应优先看最终目标行：

• 中间某一跳显示丢包，但最终目标丢包为 0，可能是该路由器对 ICMP 限速，不足以证明业务丢包；
• 从某一跳开始，后续节点及最终目标持续出现丢包，更值得关注，可能存在真实链路或回程问题；
• 延迟较高但波动小，可能是路径较远或跨运营商转接，不等同于网络不稳定；
• 延迟偶发大幅升高并伴随抖动，应增加探测次数，并结合 TCP 连接耗时和业务请求耗时判断；
• 三类运营商经过不同节点是正常现象。“三网直连”应结合实际路径、业务端口连通性、最终目标丢包和稳定性判断，不能只凭某个路由节点名称下结论。

用可控负载分别验收 CPU、硬盘和带宽

CPU：区分单核能力与多核吞吐

CPU 核心数不等于业务性能。Web 服务、数据库、编译和视频处理对单核响应或多核并行能力的要求不同。安装 Sysbench 后执行：

sudo apt install -y sysbench

单线程测试：

sysbench cpu --threads=1 --time=60 run

多线程测试：

sysbench cpu --threads="$(nproc)" --time=60 run

测试期间另开终端观察：

top
vmstat 1

记录 events per second、单线程与多线程差异、测试期间负载变化以及虚拟化环境中的 steal。steal 持续偏高，说明可能存在宿主机资源争用。Sysbench 分数只适合作为相同参数下的交付基线，不能直接换算成网站每秒请求数；真实请求还受应用、数据库、缓存和网络影响。测试结束后再次检查：

uptime
top

硬盘：先确认测试路径和写入风险

硬盘写测试可能占用空间、影响业务，甚至覆盖数据。优先使用新建测试文件、临时盘或专用空目录，并先确认剩余空间和备份状态：

df -hT
lsblk -o NAME,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINT

ROTA 只能作为设备类型参考，云盘或虚拟磁盘的真实介质应以服务商信息和实际表现为准。

使用 FIO 前调整 --size，不能盲目照搬 2G：

fio --name=seq-read \
  --filename=/tmp/fio-testfile \
  --size=2G \
  --bs=1M \
  --rw=read \
  --direct=1 \
  --ioengine=libaio \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --group_reporting

随机读写示例：

fio --name=rand-rw \
  --filename=/tmp/fio-testfile \
  --size=2G \
  --bs=4k \
  --rw=randrw \
  --rwmixread=70 \
  --direct=1 \
  --ioengine=libaio \
  --iodepth=16 \
  --numjobs=2 \
  --runtime=60 \
  --time_based \
  --group_reporting

重点记录 IOPS、BW、clat 或延迟分布，以及读写比例、队列深度和并发数。顺序读写高，不代表随机 IOPS 高；增大队列深度可能提升吞吐，也可能让高分位延迟恶化。测试结束后核对文件路径和空间占用，再按业务规则删除，避免误删真实数据。

实际带宽：同时验证方向、并发和资源占用

带宽测试至少要明确测试节点、方向、持续时间和并发数。iperf3 需要一端运行服务端，建议临时开放端口并仅允许测试节点访问，完成后关闭服务和防火墙规则。

接收端执行：

iperf3 -s -p 5201

香港服务器向外发送：

iperf3 -c TEST_SERVER_IP -p 5201 -P 4 -t 60 -O 5

外部测试节点向香港服务器发送时，将客户端放在外部节点：

iperf3 -c HONGKONG_SERVER_IP -p 5201 -P 4 -t 60 -O 5

-P 4 表示 4 条并行 TCP 连接，-t 60 持续 60 秒，-O 5 忽略前 5 秒预热阶段；支持时可使用 -R 切换数据方向。同步观察：

sar -n DEV 1
top

没有 sar 时可使用：

watch -n 1 'ip -s link'

单线程低而多线程接近预期，可能是 TCP 窗口、单连接路径或对端能力限制；多线程仍低，则应检查测试节点出口、网卡、CPU、丢包和服务端能力。上下行差异明显，可能与方向性路由、对端限速或拥塞有关。吞吐达到高位但 CPU、重传或丢包明显增加时，不应只采用峰值，应评估稳定吞吐。实际业务速度还会受连接数、对象大小、TLS、应用处理速度、缓存和运营商路径影响。

复测并建立持续监控边界

每个运营商至少重复两到三次，尽量覆盖高峰和低峰；对关键业务还应固定同一批测试节点、同一时间窗口和同一参数进行对照。每次保存：

• 测试节点城市、运营商、IP 和测试端口；
• 日期、时间、时区及业务负载；
• MTR 协议、探测次数、最终目标丢包、平均延迟和抖动；
• CPU、FIO、iperf3 的完整参数及原始输出；
• 吞吐方向、并发数、持续时间、CPU 占用和网络错误。

如果不同时间结果差异明显，应继续复测，不要用一次峰值代表长期性能。线路和性能会受运营商、测试点、回程路径、时段及网络负载影响。验收完成后，可对固定节点持续监控 MTR、TCP 连接耗时、带宽利用率、磁盘延迟和资源占用，并保留原始数据，以便区分线路变化、服务器资源瓶颈和业务自身问题。