香港服务器Linux系统交付验收，如何核对磁盘、端口、路由与带宽稳定性？

拿到香港服务器的 Linux 登录信息后，控制台显示的配置、服务器本机实际状态和外部访问结果可能并不完全一致。例如，控制台标注了数据盘，但系统没有正确挂载；本机存在监听端口，外部却无法访问；单次测速速度较高，连续访问时却出现丢包或连接失败。对于香港服务器使用linux系统的交付验收，不能只看控制台截图或一次测速结果。

一套可执行的验收顺序是：先核对交付资料与服务器身份，再检查磁盘和挂载关系；随后从本机确认监听端口，从外部节点验证端口可达性；接着核对路由、源地址和路径表现，最后在固定测试节点、方向、并发和时间窗口下测试带宽与稳定性。每个结论都应附带测试时间、节点、命令和原始输出。没有明确约定的容量、带宽、延迟或丢包阈值，不应自行补充为验收标准。

验收前先固定口径和证据目录

正式检查前，应从交付单、工单或合同中确认以下内容：

外部测试节点至少应与服务器分离。如果要判断稳定性，建议使用两个不同出口的测试节点，并记录节点地址、网络环境、操作系统和工具版本。测试节点不能同时运行大规模下载、扫描或其他高负载任务，否则无法判断异常来自服务器、测试节点还是中间路径。

可以先在服务器上创建证据目录：

evidence="/tmp/server-acceptance-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$evidence"
printf 'evidence_dir=%s\n' "$evidence"
date -Is | tee "$evidence/start-time.txt"

后续命令如果在同一个 shell 会话中执行，可以继续使用 $evidence。如果重新登录或开启了新的 shell，应先重新设置证据目录变量，避免输出保存到错误位置。截图可以辅助说明控制台配置，但不能替代服务器本机命令和外部探测结果。

一、先确认服务器身份和配置真实性

1. 查看系统、CPU、内存和地址

在服务器本机执行：

{
    printf '%s\n' '--- time ---'
    date -Is

    printf '%s\n' '--- os ---'
    if command -v hostnamectl >/dev/null 2>&1; then
        hostnamectl
    else
        cat /etc/os-release
    fi

    printf '%s\n' '--- kernel ---'
    uname -a

    printf '%s\n' '--- cpu ---'
    nproc
    lscpu 2>/dev/null | sed -n '1,20p'

    printf '%s\n' '--- memory ---'
    free -h

    printf '%s\n' '--- address ---'
    ip -br address
} | tee "$evidence/system-and-address.txt"

验收时重点比对以下关系：

• 发行版、版本和架构与交付资料一致；
• nproc、lscpu 显示的 CPU 信息与约定基本一致；
• free -h 显示的内存容量没有明显偏差；
• 主机名、实例编号和交付 IP 能对应到工单或实例记录；
• 目标网卡处于 UP 或 LOWER_UP 等正常状态，交付地址已经配置。

虚拟化环境可能存在系统预留、内存显示差异或物理设备信息不可见的情况。虚拟机中看不到真实物理磁盘型号和序列号，不必直接判定为磁盘故障，但块设备容量、文件系统和挂载关系仍应继续核对。

如果系统版本、CPU、内存或 IP 与交付资料明显不一致，应先保存上述输出以及控制台配置页面，暂停软件部署和系统重装，由交付方确认是否存在资源错配、展示口径差异或地址配置问题。不要通过修改主机名、升级系统或重装系统来掩盖验收差异。

2. 记录时间和时区

稳定性测试需要把外部节点日志与服务器日志对应起来，因此应记录服务器时间和时区：

timedatectl 2>/dev/null || date -R

如果测试节点与服务器时间不一致，应在记录中注明各自的时区和时间。不要为了验收临时修改时区或强制校时，时间调整可能影响日志排序、定时任务和业务程序。

二、核对磁盘、文件系统和基本读写

1. 确认设备、容量和挂载点

先执行只读检查：

{
    date -Is
    printf '%s\n' '--- block devices ---'
    lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

    printf '%s\n' '--- filesystem usage ---'
    df -hT

    printf '%s\n' '--- inode usage ---'
    df -ih

    printf '%s\n' '--- mount options ---'
    findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS
} | tee "$evidence/storage-layout.txt"

判断磁盘是否符合交付要求时，应同时看块设备、文件系统和挂载点，而不是只看 df -h 的剩余容量。正常状态通常包括：

1. 交付资料中的磁盘设备能够在 lsblk 中找到；
2. 标称容量与设备容量在单位换算和系统预留范围内相符；
3. 预期的数据盘已经分区、格式化并挂载到约定目录；
4. 系统盘和数据盘没有挂载到错误目录；
5. df -hT 显示目标文件系统仍有足够空间；
6. df -ih 没有出现 inode 接近耗尽的情况；
7. 需要持久化的数据目录不是 tmpfs 等临时文件系统；
8. findmnt 显示的挂载选项与业务需求不冲突。

图示对应原文命令：lsblk。 容量数字不完全相同并不一定表示少盘。控制台或硬件资料可能使用十进制单位，Linux 工具可能按二进制单位展示；分区表、文件系统格式化和系统保留空间也会使可用容量低于标称容量。应以 lsblk 的设备容量、df -hT 的文件系统容量和交付资料共同判断。

以下情况应判为异常或至少标记为待复核：

• 交付资料中有数据盘，但 lsblk 找不到对应设备；
• 设备存在，但预期挂载点为空目录或实际挂载到了系统盘；
• 文件系统类型与部署要求不一致；
• 文件系统空间或 inode 已接近耗尽；
• 数据目录挂载在临时文件系统上；
• 挂载关系或启动配置可能导致服务器重启后无法自动挂载。

验收阶段不要直接执行 mkfs、fdisk、parted、删除文件或强制挂载。这些操作可能覆盖数据或改变现场。发现设备未挂载时，应先保存 lsblk、blkid、findmnt 和 df -hT 输出，由有权限的人员确认设备用途后再制定变更方案。

2. 验证目标目录的基本读写

如果只需要确认系统临时目录具备基本读写能力，可以使用新建临时文件：

test_dir="/var/tmp"
test_file="$(mktemp "$test_dir/acceptance-XXXXXX")"

printf 'linux-storage-acceptance-%s\n' "$(date -Is)" > "$test_file"
sync

printf '%s\n' '--- file ---'
ls -l "$test_file"

printf '%s\n' '--- checksum ---'
sha256sum "$test_file"

printf '%s\n' '--- readback ---'
cat "$test_file"

rm -f -- "$test_file"
printf 'temporary test file removed: %s\n' "$test_file"

这个检查只能证明当前目录能够创建、写入、读取和删除一个小文件，不能证明磁盘达到某个固定 IOPS 或吞吐值。若要验证数据盘，应将 test_dir 改为已经确认的测试子目录，并先确认该目录没有业务文件。测试完成后，必须确认删除的路径确实是本次命令创建的临时文件。

3. 仅在有性能标准时执行磁盘测试

如果交付资料明确规定了磁盘性能，或业务确实需要性能验收，再考虑使用 fio。测试前应确认测试目录位于目标磁盘、空间足够、允许产生磁盘负载，并且测试参数与约定一致，包括块大小、读写比例、队列深度、并发数和持续时间。

示例：

command -v fio

test_file="$(mktemp /var/tmp/fio-acceptance-XXXXXX)"
rm -f -- "$test_file"

fio --name=acceptance-seqwrite \
    --filename="$test_file" \
    --size=512M \
    --rw=write \
    --bs=1M \
    --direct=1 \
    --iodepth=1 \
    --runtime=30 \
    --time_based=1 \
    --group_reporting \
    | tee "$evidence/fio-seqwrite.txt"

rm -f -- "$test_file"

fio 未安装时，不要从不明来源临时安装软件。可以记录为“未执行性能测试”，或按照既有软件源和变更流程安装。不同块大小、队列深度、并发数和负载条件下的结果不能直接比较。

三、核对监听端口和外部可达性

端口验收必须先有白名单。白名单至少应包含端口、协议、用途和允许来源。例如：

表中的端口必须替换为实际交付值，不能因为某个端口常见就默认它应当开放。

1. 查看本机监听状态

sudo ss -lntup | tee "$evidence/listening-tcp-udp.txt"
sudo ss -s | tee "$evidence/socket-summary.txt"

检查时关注：

• TCP LISTEN 端口是否属于预期服务；
• UDP 是否存在交付资料未列出的监听；
• 服务绑定的是 127.0.0.1、指定地址还是所有地址；
• 监听进程和端口用途是否相符；
• 是否存在未列入白名单的管理、调试或测试端口。

监听地址与外部可达性不是同一个结论。绑定 127.0.0.1 通常只允许本机访问；绑定指定地址说明服务使用该地址，但仍可能被防火墙或上游访问控制拦截；绑定 0.0.0.0 或 IPv6 所有地址，只表示具备接收多个地址连接的条件，不代表一定能从公网访问。

如需确认本机防火墙，只做读取操作：

if command -v nft >/dev/null 2>&1; then
    sudo nft list ruleset
fi

if command -v firewall-cmd >/dev/null 2>&1; then
    sudo firewall-cmd --list-all
fi

if command -v ufw >/dev/null 2>&1; then
    sudo ufw status verbose
fi

不要为了让端口测试通过而直接关闭防火墙或放行全部来源。修改管理端口规则前，应备份当前规则，确认影响范围，并准备通过控制台或带外管理恢复。远程修改错误可能导致当前登录连接中断。

2. 从外部节点测试 TCP 端口

在与服务器分离的外部节点上执行：

test_ip="SERVER_IP"
test_port="SERVICE_PORT"

nc -vz -w 5 "$test_ip" "$test_port" 2>&1 \
    | tee "tcp-${test_port}.txt"

TCP 连接成功，只能证明三次握手和基础连接路径可用，不能证明应用层正常。对 HTTP 或 HTTPS 服务，还应进行应用层检查：

curl -sS -o /dev/null \
    --connect-timeout 5 \
    --max-time 15 \
    -w 'remote=%{remote_ip} code=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
    "https://SERVER_IP/health"

如果使用域名，应分别记录域名解析结果、通过 IP 访问的结果和通过域名访问的结果，并确认解析地址属于本次交付地址。证书校验不能为了验收而长期关闭。

可以按以下关系判断：

UDP 端口不能仅依靠一次 nc 结果判断应用可用性。应使用对应协议的健康检查、客户端命令或业务测试，并结合服务日志和计数器判断。

四、核对路由、源地址和实际路径

1. 查看接口、路由表和策略规则

在服务器本机保存当前网络状态：

{
    date -Is

    printf '%s\n' '--- interfaces ---'
    ip -br address

    printf '%s\n' '--- ipv4 main route ---'
    ip route show table main

    printf '%s\n' '--- ipv6 route ---'
    ip -6 route show

    printf '%s\n' '--- policy rules ---'
    ip rule show
} | tee "$evidence/routes-and-rules.txt"

需要确认交付 IP 配置在预期网卡上，默认路由存在，业务地址对应的出接口和源地址正确，并且没有不明的策略路由将流量导向其他接口。

针对实际目标地址查询内核的路由选择：

target_ip="TARGET_IP"
ip route get "$target_ip" \
    | tee "$evidence/route-to-${target_ip}.txt"

输出中的接口、下一跳和 src 源地址应符合测试目的。多网卡环境不能只看默认路由，必须查看到具体目标地址的实际决策结果。

2. 分别测试服务器出站和外部入站

如果从服务器向目标地址测试，得到的是服务器出站方向的路径；如果从外部节点访问服务器，验证的是外部节点到服务器的入站路径。两者方向不同，不能用其中一个结果代表全部网络质量。

对已授权目标执行：

target_ip="TARGET_IP"

ping -n -c 20 -W 2 "$target_ip" \
    | tee "$evidence/ping-${target_ip}.txt"

如系统已经安装 tracepath，可以继续执行：

tracepath -n "$target_ip" \
    | tee "$evidence/tracepath-${target_ip}.txt"

ping 的延迟和丢包只对当前源节点、目标地址、时间窗口和协议成立。ICMP 可能被目标或中间设备限制，因此无法响应不必然代表 TCP 或应用访问失败。路径中某一跳不响应，也不能直接判定最终链路丢包；应优先观察最终目标的端到端结果，以及 TCP 或应用层访问是否同步失败。

路由异常时至少保存测试时间、源节点地址、目标地址、ip route get 输出、完整路径探测结果以及最终访问结果。不要在验收阶段直接执行 ip route add、ip route del 或覆盖网络配置。修改路由前应导出当前路由和策略规则，准备控制台恢复方案，并确认不会影响当前远程会话。

五、按固定口径测试带宽

1. 先明确方向、连接数和测试服务

带宽测试必须写清楚四个问题：

1. 从哪个节点测到哪个节点；
2. 测试上行、下行还是双向；
3. 使用单个 TCP 流还是多个并行 TCP 流；
4. 测试服务、文件大小、持续时间和样本数是什么。

iperf3 -P 4 表示 4 个并行 TCP 流，不等于每秒 4 个请求，也不等于应用层每秒请求数。应用请求量还会受到请求大小、连接复用、服务端处理能力和响应时间影响，不能用并发连接数直接替代每秒请求数。

测试期间应同时记录服务器 CPU、内存、磁盘写入和其他业务流量。服务器网卡流量正常但应用层速度较低时，问题可能来自测试服务、磁盘或应用处理能力，而不一定是带宽不足。

2. 使用已授权的吞吐测试服务

如果有由测试方控制并授权使用的 iperf3 服务，可以执行单流测试：

test_server="AUTHORIZED_TEST_SERVER"
test_port="5201"

iperf3 -c "$test_server" \
    -p "$test_port" \
    -t 30 \
    -P 1 \
    -J \
    | tee "$evidence/iperf3-single-direction.json"

反向方向测试：

iperf3 -c "$test_server" \
    -p "$test_port" \
    -t 30 \
    -P 1 \
    -R \
    -J \
    | tee "$evidence/iperf3-reverse-direction.json"

只有在交付标准明确涉及多连接时，才执行并发测试：

iperf3 -c "$test_server" \
    -p "$test_port" \
    -t 30 \
    -P 4 \
    -J \
    | tee "$evidence/iperf3-four-streams.json"

这些命令要求测试服务已经授权并开放。若需要临时启动服务，应限制来源地址和测试端口，测试结束后停止进程，并用 ss -lntup 确认测试端口已经关闭。不要在生产服务器上长期保留测试端口。

如果没有受控的吞吐测试服务，可以使用固定来源的测试文件进行下载样本测试：

test_url="https://AUTHORIZED_TEST_HOST/test-file"

for i in $(seq 1 5); do
    printf 'sample=%s time=%s\n' "$i" "$(date -Is)"
    curl -L --fail --silent --show-error \
        --connect-timeout 5 \
        --max-time 180 \
        -o /dev/null \
        -w 'code=%{http_code} remote=%{remote_ip} size=%{size_download} speed=%{speed_download}B/s connect=%{time_connect}s total=%{time_total}s\n' \
        "$test_url"
    sleep 10
done | tee "$evidence/download-samples.txt"

上传测试只能使用明确提供的测试接口，并确认服务端会清理或丢弃测试数据。不能把业务接口当作上传测速接口。

3. 记录网卡计数和单位

测试前后分别保存网卡状态：

ip -br link | tee "$evidence/link-state-before.txt"
ip -s link | tee "$evidence/link-counters-before.txt"

if command -v vmstat >/dev/null 2>&1; then
    vmstat 1 10 | tee "$evidence/vmstat.txt"
fi

ip -s link | tee "$evidence/link-counters-after.txt"

如果系统已经安装 sar，可以记录网卡流量：

if command -v sar >/dev/null 2>&1; then
    sar -n DEV 1 10 | tee "$evidence/sar-network.txt"
fi

iperf3 常以 bit/s 展示吞吐，文件下载命令中的 speed_download 通常以 Byte/s 展示。换算时应明确单位：在十进制口径下，1 Gbit/s 约等于 125 MB/s，但实际应用速度仍会受到协议开销、远端服务和本机处理能力影响。验收时必须使用交付资料规定的单位和口径，不能把不同单位的数字直接比较。

结果解释应结合测试条件：

• 单流速度低、多流接近约定口径，可能与单流处理、远端服务或 TCP 参数有关；
• 下载正常而上传偏低，应分别核对测试方向、服务端能力和交付口径；
• 网卡计数增长正常但应用层速度低，可能是远端服务、磁盘或应用限制；
• 测试中接口错误、丢包或重传计数增加，应结合内核日志和服务日志继续判断；
• 不同外部节点结果差异明显，只能说明路径或节点条件不同，不能单独归因于服务器带宽不足。

六、用连续样本判断稳定性

单次 ping、单次下载或一次 TCP 连接只能说明一个时间点的表现，不能直接代表稳定性。稳定性测试应固定测试节点、目标、参数和间隔，并保存每个样本的时间和结果。

对 HTTP 服务，可以执行连续访问：

test_url="https://AUTHORIZED_TEST_HOST/health"

for i in $(seq 1 20); do
    printf 'sample=%s time=%s ' "$i" "$(date -Is)"
    curl -sS -o /dev/null \
        --connect-timeout 5 \
        --max-time 15 \
        -w 'code=%{http_code} remote=%{remote_ip} connect=%{time_connect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
        "$test_url" || printf 'request_failed=1\n'
    sleep 15
done | tee "$evidence/http-stability-samples.txt"

没有 HTTP 服务时，可以对已授权的 TCP 端口进行连续连接测试：

test_ip="SERVER_IP"
test_port="SERVICE_PORT"

for i in $(seq 1 20); do
    printf 'sample=%s time=%s ' "$i" "$(date -Is)"
    if nc -vz -w 5 "$test_ip" "$test_port" >/tmp/nc-result.$$ 2>&1; then
        printf 'tcp_connect=success\n'
    else
        printf 'tcp_connect=failed detail=%s\n' "$(tr '\n' ' ' 

测试结束后应确认 /tmp/nc-result.$$ 是本次命令创建的临时文件，再执行删除。样本数量、间隔和持续时间不是普遍适用的性能承诺，只是示例参数；实际验收应以业务约定为准。

同时检查接口错误和系统告警：

ip -s link | tee "$evidence/link-counters-stability.txt"

dmesg -T --level=err,warn 2>/dev/null \
    | tail -n 200 \
    | tee "$evidence/dmesg-warnings.txt"

if command -v journalctl >/dev/null 2>&1; then
    journalctl -p warning..alert -b --no-pager \
        | tail -n 200 \
        | tee "$evidence/journal-warnings.txt"
fi

如需核对具体服务：

service_name="ACTUAL_SERVICE_NAME"

systemctl status "$service_name" --no-pager \
    | tee "$evidence/service-status.txt"

journalctl -u "$service_name" -b --no-pager -n 200 \
    | tee "$evidence/service-log.txt"

稳定性正常，不是指日志中完全没有任何告警，而是测试窗口内没有与网络中断、网卡重置、服务崩溃、磁盘错误或大量连接失败对应的异常。历史告警、与当前设备无关的告警或无法与测试时间对应的记录，不能单独作为本次验收失败依据。

发现异常时按低风险顺序处理

配置、CPU、内存或 IP 不一致

先停止部署和初始化，保存本机输出、控制台配置和交付资料。不要重装系统、修改主机名或自行调整资源，先由交付方确认资源展示差异和实际配置。

磁盘存在但无法使用

再次保存：

lsblk
blkid
findmnt
df -hT

未确认设备用途前，不要执行 mkfs、fdisk、parted、强制挂载或删除文件。如果错误目录已经产生业务写入，应先停止继续写入的服务并备份数据，再制定恢复方案。

本机监听但外部无法连接

依次确认目标 IP、监听地址、本机防火墙、上游访问控制和外部节点状态，并查看服务日志是否记录了连接请求。不要直接关闭防火墙，因为这会改变验收环境，也可能暴露未授权服务。

外部端口可达但应用异常

TCP 建连成功不等于应用正常。继续进行协议层健康检查，核对状态码、响应内容、证书、进程日志和资源使用情况。发现未列入白名单的端口可达时，应先保存证据，再按安全变更流程限制访问。

路由、带宽或稳定性波动

先用同一节点、同一目标和同一参数重复测试，再使用第二个外部节点交叉验证。记录服务器网卡计数、CPU、内存、磁盘负载、测试服务状态和业务流量。只有当异常能够在相同条件下重复，才适合提交网络质量复核。

测试期间连接中断

不要立即重启。先保存当前状态：

date -Is
uptime
ip -br address
ip route
ip -s link
ss -s

随后检查内核和服务日志。重启可能丢失部分运行态证据。只有在确认服务器失联、具备带外管理、完成数据备份并有恢复方案时，才考虑重启等高影响操作。

验收单签字前的结果检查

每个项目至少记录测试时间、服务器时区、执行节点、节点地址、系统和工具版本、执行命令、原始输出文件、对照资料以及“通过、异常或待复核”结论。网络性能还应记录目标地址、方向、单流或多流、测试时长、样本数、业务流量情况、连接失败、延迟、丢包和吞吐结果。

可以按以下项目逐项确认：

• [ ] 系统版本、架构、CPU、内存、主机身份和 IP 与交付资料一致；
• [ ] 磁盘设备、容量、文件系统和挂载点对应正确；
• [ ] 目标目录完成基本读写测试，验收临时文件已经清理；
• [ ] 本机监听端口与白名单一致，未发现未授权服务；
• [ ] 外部节点能够按约定访问业务端口，内部端口没有被错误暴露；
• [ ] ip route get 显示的接口、下一跳和源地址符合测试目的；
• [ ] 路径探测和端到端访问结果已经保存，没有把中间跳不响应直接当作最终丢包；
• [ ] 带宽记录包含测试节点、时间、方向、连接数、测试服务和单位；
• [ ] 稳定性测试包含连续样本，并说明异常是否可复现；
• [ ] 网卡计数、系统告警和服务日志已经保存；
• [ ] 每个异常项都已明确为整改、待复核或接受偏差。

测试完成后的回滚检查

本套验收以只读检查为主，原则上不应改变服务器配置。若曾经启动临时吞吐服务、修改防火墙、路由、服务配置或启动项，应执行以下收尾：

1. 只删除本次命令创建的临时文件，并确认没有误删业务文件；
2. 停止临时启动的测试服务；
3. 使用 ss -lntup 确认临时测试端口已经关闭；
4. 根据变更前备份恢复修改过的配置；
5. 恢复前核对备份时间和配置路径，避免覆盖验收期间产生的有效业务变更；
6. 恢复后重新检查端口、路由和服务健康状态；
7. 分别保存变更前、变更中和回滚后的输出；
8. 如果验收失败但没有进行配置修改，应保留现场，不要通过重启、升级、重装或清理日志改变证据。

当配置真实性、磁盘、端口、路由、带宽和稳定性六类记录都能对应到明确的交付口径，且每个异常项都有留证、责任归属和处理状态后，再在验收单上签字确认。