香港服务器交付验收不应只看控制台截图，也不能只执行一次 ping 就判断可用。比较稳妥的做法是：先以订单或交付单中的 CPU、内存、磁盘、IP、带宽和端口要求为基准，再分别从服务器内部、控制台和独立外部节点核对，最后用多次样本确认路由与连接稳定性。

以下步骤以 Linux 香港服务器为例，默认具备服务器登录权限、一个不依赖待验收服务器的外部测试节点，以及完整的交付信息。测试前不要为了“测出结果”临时修改防火墙、路由或业务配置；任何参数变更都应先备份并取得维护授权。

先固定验收口径

开始前准备一份验收记录，至少包含以下内容：

• 服务器公网 IPv4、IPv6（如有）、登录地址和实例标识。
• 操作系统及版本。
• 交付单中的 vCPU 数量、内存、磁盘数量与容量、磁盘挂载点。
• 约定的公网带宽口径：独享、共享、峰值或其他明确描述。
• 需要开放的 TCP、UDP 端口，以及每个端口对应的服务。
• 测试节点的公网 IP、网络环境和运营商出口。
• 测试日期、时区、开始和结束时间。
• 测试工具及版本、测试参数、原始输出和异常截图。

测试节点必须与香港服务器分离，不能在同一台服务器上同时充当客户端和服务端。否则，即使连接成功，也无法证明公网入口、路由和外部端口正常。

服务器内部先记录时间和基础环境，避免后续无法确定结果对应的时间窗口：

date -Is
cat /etc/os-release
uname -a
ip -br addr
ip route

如果服务器同时提供 IPv4 和 IPv6，应分开测试，不能用 IPv4 的结果代替 IPv6 的验收结果。

配置真实性：控制台、系统和交付单三方核对

CPU、内存和操作系统

在服务器内执行：

nproc --all
lscpu
free -b
cat /etc/os-release

重点记录以下信息：

• nproc --all 返回的逻辑处理器数量。
• lscpu 中的 CPU 数量、架构和虚拟化信息。
• free -b 中的总内存。
• 实际运行的操作系统名称和版本。

判定时不能只看某一个命令。虚拟机可能存在内核保留内存、虚拟化展示差异或容器限制，因此应将系统输出与控制台资源规格、交付单同时对照。

例如：

• 交付单为固定 vCPU 数量，但系统显示数量明显不一致，应先确认是否存在 CPU 热插拔、容器限制或实例规格未生效。
• 交付单标注的内存与 free -b 存在少量差异时，要确认是单位换算还是系统保留；不能直接把所有差异都判定为少配。
• 只看到某个 CPU 型号，不能据此证明是独享物理 CPU，也不能据此推断性能等级。

如果控制台规格和系统检测结果不一致，先保存控制台截图、实例 ID、命令输出和时间，再联系交付方复核，不要自行重装系统或调整实例配置。

磁盘容量、类型和挂载点

先确认块设备和文件系统的对应关系：

lsblk -b -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
df -hT
findmnt

检查时区分三个概念：

1. 块设备容量：由 lsblk 看到的设备大小。
2. 文件系统可用容量：由 df 看到的空间，可能扣除文件系统元数据和保留空间。
3. 业务实际挂载点：例如业务是否真正使用了交付的独立数据盘，而不是仍写入系统盘。

容量单位也要统一。厂商常用十进制单位，Linux 工具可能同时显示十进制或二进制单位；验收记录中应保留原始字节数，不要只抄取四舍五入后的 G 或 T。

建议重点核对：

• 是否存在交付单中列出的每块磁盘。
• 磁盘容量是否与交付规格相符。
• 文件系统类型是否符合部署要求。
• 业务数据目录是否挂载在目标磁盘上。
• 磁盘是否以只读方式挂载。

如果只是核对容量，不需要写入磁盘。若还要验证磁盘读写性能，应使用业务低峰期和临时测试文件，不要直接对生产块设备执行破坏性测试。

例如，确认 /data 是可用于验收的非生产目录后，可使用 fio 测试临时文件：

fio --name=acceptance \
  --filename=/data/.acceptance-fio.test \
  --size=1G \
  --time_based \
  --runtime=60s \
  --ramp_time=5s \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --iodepth=32 \
  --numjobs=1 \
  --direct=1 \
  --group_reporting

这个结果只代表指定目录、指定文件大小、指定块大小和指定队列深度下的样本，不代表所有业务负载，也不能脱离测试环境直接推断整块磁盘的长期性能。测试期间应记录磁盘利用率和服务器负载，并保存 fio 的完整输出。

不要把 /dev/vda、/dev/sda 等原始块设备直接作为 fio 的 --filename，除非已经确认是空白测试盘并完成备份。对生产块设备写入可能覆盖文件系统，失败后通常无法通过普通回滚恢复。

端口连通：先确认监听，再从外部验证

端口验收应分成三层：

1. 服务是否在服务器本机监听。
2. 服务是否能在本机完成协议层响应。
3. 独立外部节点能否通过公网 IP 连接。

查看本机监听状态

sudo ss -lntup

记录目标端口的监听地址和进程信息。监听地址的含义不同：

• 127.0.0.1:端口：通常只接受本机连接，外部访问不会成功。
• 0.0.0.0:端口：通常表示监听所有 IPv4 地址，但仍可能被防火墙或云侧策略拦截。
• [::]:端口：表示 IPv6 监听，是否同时接受 IPv4 取决于系统参数和服务配置。
• 没有监听记录：应先检查应用是否启动、端口是否配置正确，而不是先判断网络故障。

如果目标是 HTTP 或 HTTPS 服务，在已知正确路径的前提下进行本机协议测试。下面的 /health 只是示例，应替换为实际存在的健康检查地址：

curl --connect-timeout 5 \
  --max-time 10 \
  -sS \
  -o /dev/null \
  -w 'code=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  http://127.0.0.1:PORT/health

本机连接成功只能证明应用和本地监听基本正常，不能证明公网端口已经放行。

从独立节点测试 TCP 端口

在外部测试节点执行：

nc -4 -vz -w 5 SERVER_IPV4 PORT

如果服务器配置了 IPv6，再单独执行：

nc -6 -vz -w 5 SERVER_IPV6 PORT

对于 HTTP 或 HTTPS，建议同时测试一次真实协议：

curl -4 -I --connect-timeout 5 --max-time 10 https://SERVER_IPV4/

端口结果可以按以下方式解释：

UDP 不能仅靠 nc -u 得出可靠结论，因为 UDP 没有类似 TCP 三次握手的连接确认。UDP 端口应使用实际业务协议进行请求和响应验证，并由服务端日志确认是否收到数据。

验收期间不要为了测试临时放开全部端口。如果必须增加临时规则，应先导出原有防火墙配置，记录变更范围和有效时间，测试完成后按原配置恢复，并从外部节点重新验证远程管理端口。

路由稳定性：终点结果比中间节点更重要

路由测试必须明确测试目标。优先使用真实业务访问端、已授权的监控节点或可控测试服务器，不要用一个随机目标的结果代表所有公网访问情况。

先确认到目标地址实际使用的出口：

ip route get TARGET_IP

再进行 ICMP 路径和时延测试：

ping -4 -c 100 -i 1 TARGET_IP

使用 mtr 查看路径变化和各跳统计：

mtr -4 -rwzc 100 TARGET_IP

如果目标和服务器支持 IPv6，应使用对应的 IPv6 地址单独执行：

ping -6 -c 100 -i 1 TARGET_IPV6
mtr -6 -rwzc 100 TARGET_IPV6

每次记录以下信息：

• 测试节点公网 IP和网络出口。
• 目标 IP及目标服务端口。
• 测试开始和结束时间，并注明时区。
• 样本数量、测试间隔和工具版本。
• 最终节点的丢包、平均时延、最大时延和波动情况。
• 路由是否发生变化，以及变化发生的时间。

判断时要注意两个边界：

• 中间某一跳显示丢包，不等于最终目标丢包。许多路由设备会限制或降低 ICMP 响应优先级，如果后续节点和终点正常响应，不能仅凭中间一跳判定线路故障。
• 最终节点持续出现丢包、连接超时或时延明显波动，才更接近真实业务影响，但仍需结合 TCP 端口测试和业务请求结果确认。

路由稳定性不是一次测试就能证明。至少应在交付时记录一组样本，并在不同时间窗口对同一测试节点重复测试。每组结果必须保持目标、测试节点、协议和参数一致，否则不同结果无法直接比较。

带宽测试：固定节点、方向和测试参数

带宽结果受测试节点、并发数、协议、时间段、目标服务器负载和传输距离影响。没有约定的测试节点和方法时，不宜只引用某个测速网站的单次结果判定是否达标。

较适合交付验收的方式是使用双方都能控制的 iperf3 测试端点。远端测试节点运行服务端：

iperf3 -s

在香港服务器上测试到远端节点的发送方向：

iperf3 -c TEST_NODE_IP -t 30 -P 1

测试反向传输方向：

iperf3 -c TEST_NODE_IP -t 30 -P 1 -R

其中：

• -t 30 表示本次样本持续时间，实际值应与验收口径保持一致。
• -P 1 代表单连接样本，不能代表多连接业务的峰值表现。
• -R 用于交换发送方向，不能省略方向说明。
• 测试节点必须有足够的出口能力，否则测到的可能是测试节点瓶颈。

建议同一方向重复多次，并分别记录每次结果，不要只保留平均值。测试时还要记录服务器 CPU、内存、磁盘和网络负载。带宽测试可能产生较大流量，正式生产环境应提前确认流量成本、业务影响和测试窗口。

如果交付要求包含 UDP 丢包或抖动，应使用双方已约定的目标速率进行 UDP 测试。没有约定速率时，不要随意用大流量压测，因为这可能造成拥塞、影响业务或触发流量策略。

稳定性复核：连接、资源和系统日志一起看

在端口和带宽测试期间，同时采集服务器状态：

uptime
free -h
vmstat 1 10
systemctl --failed --no-pager
journalctl -k -b --no-pager -n 100

如果命令不可用，应记录工具缺失，不要在验收过程中直接执行系统升级。重点观察：

• 测试期间是否出现内存不足或交换分区异常使用。
• CPU 是否持续满载，导致应用响应变慢。
• 内核日志中是否出现网卡、磁盘、文件系统或虚拟化错误。
• 是否存在失败的系统服务。
• 带宽测试时的结果下降是否与 CPU、磁盘或应用负载同时发生。

如果需要验证应用端口的短时稳定性，可以在外部节点以固定间隔重复连接，并保存每次的时间、连接结果和响应时间。测试目标应是实际业务端口，测试频率应避免造成服务压力。

“端口偶尔能通”不能直接算通过。应区分以下情况：

• 本机始终正常、外部偶发失败：重点检查公网入口策略、路由波动和外部节点本身。
• 本机也偶发失败：重点检查应用进程、资源使用和系统日志。
• TCP 始终成功、业务请求偶发失败：重点检查 TLS、应用依赖、认证或上游响应。
• 只有 ICMP 异常、TCP 业务始终正常：可能是 ICMP 限速，不能单独作为业务中断证据。

通过、不通过与待复核的判定

可以按以下口径整理结果：

没有明确写入订单、服务协议或验收单的性能阈值，不应自行补造一个“合格数值”。这时应保留原始样本，先确认双方采用的指标、节点、方向和时间窗口。

异常留证与失败回滚

建议建立独立的验收目录保存命令输出，但不要把密码、私钥、令牌或完整业务配置复制进去：

mkdir -p "$HOME/acceptance-$(date +%F-%H%M%S)"

每条证据至少标注：

• 服务器 IP 和实例标识。
• 测试节点 IP。
• 测试日期、时间和时区。
• 命令及完整参数。
• 工具版本。
• 测试方向和协议。
• 原始输出、截图或日志时间范围。
• 失败时的重现次数。

验收测试原则上应保持无侵入。若使用 fio 创建了临时文件，只有在确认路径准确、文件确实由本次测试生成且没有业务进程使用后，才能删除。删除前应保留测试输出；如果路径存在歧义，不要执行删除命令，应交由管理员确认。任何业务文件在删除前都必须先完成备份，误删后的恢复只能依赖备份。

如果为了测试临时增加了防火墙规则、监听端口或流量工具，应记录变更前配置，测试完成后只恢复本次新增内容，不要用“重置全部规则”的方式回滚。恢复前要确认远程管理通道仍然可用，并在恢复后从外部节点再次验证管理端口和业务端口。

若配置、磁盘或网络验收失败，不要通过重装系统、修改路由、扩大端口放行或调整应用参数来掩盖结果。应先保留现场和日志，再根据失败项提交复核。交付方修复后，使用同一测试节点、同一目标、同一时间记录方式和同一命令重新测试，只有前后结果具备可比性，复核结论才有效。