交付时能登录韩国服务器，不等于配置和网络已经验收合格：磁盘可能未按约定挂载，服务端口可能只允许本机访问，单次测速也可能受测试端或对端影响。较稳妥的做法是先对照交付资料确认实例和指标口径，再依次检查磁盘、端口、路由、带宽和稳定性；每项都记录测试条件与原始结果。

验收标准应以订单、合同或交付单约定为准。尤其要先说清磁盘核对的是原始容量、文件系统容量还是业务可用空间，带宽核对的是端口速率、单向吞吐量还是其他指标。若约定不明确，应先补充测试口径，不能拿一次测速或一个容量显示值代替完整判断。

验收前先确定口径和测试条件

准备交付单、服务器地址和实例标识、系统登录权限、业务端口清单，以及用于外部连接测试的设备。测试设备应尽量来自业务实际访问环境；带宽测试还需要有足够网络能力、且条件可控的对端。

每次测试至少记录日期、时区、测试端及其网络环境、目标地址、协议、命令和原始输出。若要比较修复前后结果，尽量使用相同测试端、对端、方向和参数。网络和性能测试只能说明特定时间、环境与样本下的情况，不能直接推导为所有用户、所有时段的长期表现。

验收期间优先使用只读查询和低风险连接测试。不要为了证明磁盘容量而格式化、重新分区或覆盖写入，也不要随意改变生产防火墙规则。确需启动临时测试服务或开放测试端口时，应先保存原有配置，限定测试来源，测试结束后停止服务、移除临时规则并恢复原配置。

先确认实例身份，再核对磁盘

实例身份不一致时，后续测试即使通过也不能证明交付正确。应将实际登录的服务器与交付资料中的地址、实例标识、系统和磁盘对应起来；主机名可能被修改，不能单独作为身份依据。

Linux 系统可先执行以下只读命令：

date -Is
hostnamectl
uname -a
ip -br address
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

核对地址和系统信息是否符合约定，并确认交付单列出的磁盘或卷能在系统中识别。Windows 系统可使用 PowerShell：

Get-Date -Format o
Get-NetIPAddress | Format-Table IPAddress,AddressFamily,InterfaceAlias
Get-Disk | Format-Table Number,FriendlyName,OperationalStatus,Size
Get-Volume | Format-Table DriveLetter,FileSystem,Size,SizeRemaining

如果地址或实例无法与交付资料对应，应先暂停验收并要求交付方确认实例关系；否则后续磁盘和网络结果都可能来自错误目标。

磁盘容量要区分三个层级

磁盘验收常见的误差来自比较了不同层级的数据：

• 块设备容量：系统识别到的磁盘或虚拟磁盘大小。
• 文件系统总容量：分区或逻辑卷可供文件系统管理的空间。
• 当前可用容量：扣除已有文件和文件系统保留空间后，当前还能使用的空间。

Linux 可执行：

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
findmnt -o TARGET,SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%
df -ih

lsblk 用于查看块设备和容量，df -hT 用于查看文件系统总量与可用空间，findmnt 用于确认业务目录实际落在哪个设备上。df -ih 用于检查 inode 使用情况；空间尚有剩余但 inode 耗尽时，仍可能无法创建新文件。必要时可查看根目录各挂载点的占用情况：

sudo du -xhd1 / 2>/dev/null

Windows 可使用：

Get-Disk | Format-Table Number,FriendlyName,Size,OperationalStatus
Get-Partition | Format-Table DiskNumber,PartitionNumber,DriveLetter,Size
Get-Volume | Format-Table DriveLetter,FileSystem,Size,SizeRemaining

判定时要按交付约定选择对应数据：约定原始磁盘容量，就看块设备或磁盘对象；约定文件系统容量，就看对应分区或挂载点；约定业务可用空间，就检查业务目录所在文件系统的可用量。十进制与二进制单位的显示差异、系统预装文件和文件系统元数据可能造成数值不同，不应直接视为少配。

若数据盘未识别、未挂载到约定目录，或交付资料写的是可用容量而实际可用空间明显不符，应保存完整输出并要求交付方核对。不要自行格式化、重新分区或扩容；这类操作可能破坏数据，也会改变待验收现场。

从服务器监听到外部端口连通

端口是否可用，需分别确认服务器上有正确服务监听，以及业务实际来源能够从外部连接。服务器本机连接成功，只能说明本机路径可用，不能证明公网或其他外部网络可达。

Linux 上查看 TCP、UDP 监听：

ss -lntp
ss -lnup

重点检查目标端口、协议和监听地址。服务若只绑定 127.0.0.1，通常只能接受本机连接；是否能接受外部连接，还取决于监听地址、防火墙、来源限制和上游访问控制。

从外部 Linux 测试端检查 TCP：

nc -vz -w 5 <服务器地址> 

Windows 测试端可执行：

Test-NetConnection -ComputerName <服务器地址> -Port 

如果端口提供 HTTP 或 HTTPS 服务，还应验证实际业务请求，而不只看 TCP 握手：

curl -I --connect-timeout 5 --max-time 15 https://<服务器地址或域名>/

使用业务允许的来源地址测试，并记录来源、目标、协议和时间。若服务只允许指定来源，而测试端不在允许范围内，失败不能作为整体端口故障的依据。

不同结果的解释也不同：连接成功表示当前来源和时间下 TCP 握手完成，不代表应用层正常；Connection refused 通常意味着没有对应监听服务，或目标主动拒绝；连接超时可能与防火墙、来源限制、路径丢包、服务无响应等有关，不能直接归因于网络。若本机成功而外部失败，优先核对监听地址和访问控制；若 TCP 成功但业务请求失败，再检查应用协议、证书、域名或服务本身。

UDP 没有 TCP 式握手，单凭没有“连接成功”提示不能判定端口故障。应使用业务实际请求与响应，或双方约定的 UDP 测试程序，记录响应、丢包和超时；不要用持续发送大量 UDP 流量的方式验收。

路由结果要结合最终目标和业务测试

路由探测能展示测试端到服务器的大致路径，但不是带宽测试。某个中间节点不响应 ICMP，或显示探测丢包，不一定代表业务流量丢失；应重点看最终目标是否可达，并与端口连接、实际业务请求结果对照。

Linux 测试端可执行：

ip route
tracepath -n <服务器地址>

如已安装 mtr，可按固定参数采样：

mtr -n -r -w -c 20 <服务器地址>

Windows 测试端可执行：

tracert <服务器地址>
pathping <服务器地址>

记录测试端网络环境、时间、目标地址、命令参数、最终目标可达性，以及最终目标的延迟和丢包表现。中间节点有丢包但最终目标稳定可达，不能单独判故障；最终目标持续丢包且端口连接也间歇失败，则应保留连续结果并提交核查。只有一个测试端异常时，先排查该测试端自身网络或其到服务器的路径；多个具有代表性的测试端在相近时间出现相似异常，更适合交由交付方进一步定位。

路径发生变化本身不等于交付不合格，除非交付约定明确要求特定路径或网络条件。若业务依赖服务器主动向外连接，还应分别验证服务器发出的方向；到服务器的路径正常，不代表反向通信也正常。

按约定口径测试带宽与稳定性

测试前先确认交付资料中的带宽指什么：端口接入速率、单向吞吐量、双向能力、共享或峰值指标，以及流量额度，含义并不相同。流量额度不是实时速度，单次测速峰值也不能证明持续带宽。

测试端、对端和服务器负载都可能成为瓶颈。开始前记录测试端出口环境、对端地址及其网络能力、服务器负载、测试方向、协议、持续时间、并发数和测试时段。测试结果只适用于记录的这些条件，不能脱离条件横向比较。

使用受控对端进行 TCP 吞吐测试时，可使用 iperf3。在作为服务端的对端启动：

iperf3 -s

测试端进行正向测试：

iperf3 -c <对端地址> -p <测试端口> -t 30 -P 1 --json

需要测试反向方向时：

iperf3 -c <对端地址> -p <测试端口> -t 30 -P 1 -R --json

这些命令中的地址、端口、持续时间和并发数是示例参数，不是交付标准。-P 设置并行连接数，不等于每秒请求数，也不能据此推算应用的每秒请求处理能力。若改变并发数，应把参数变化写进记录；测试前限制临时服务的访问来源，结束后停止服务并恢复访问控制。

带宽结果可按约定分为三种处理方式：

• 符合约定：在约定方向、对端、时间窗和方法下达到标准，重复采样没有持续异常。
• 待复核：只有一个测试端结果偏低，或测试端出口、对端能力可能构成瓶颈；应更换受控对端，并在相同参数下重测。
• 异常或无法判定：同一来源、对端和方向多次低于约定标准，或持续中断、吞吐下降，应提交原始数据；若合同没有说明带宽类型、测试方向和允许偏差，则不能凭一次测速作出合格与否的最终判断。

稳定性应看重复采样，而非最高速度。观察窗口和采样频率以合同或双方书面约定为准；若未约定，应把实际测试时段和样本次数写清楚，不把短时间结果描述成长期承诺。将 ICMP、TCP 端口连接和实际业务请求分开记录：ping 正常不代表业务端口正常，ping 不响应也不必然代表业务不可用。若业务以 UDP 为主，应另行约定测试速率、丢包、抖动和持续时间，并使用可控流量。

异常留证、处理与修复后复核

异常发生时，先固定现场，不要急着修改系统配置。端口问题可按“外部测试结果—服务器监听—访问控制—业务服务”的顺序定位：外部失败且无监听，先确认服务状态和端口配置；只监听本地回环地址，应核对业务要求后由负责方调整；监听正确但外部失败，再检查防火墙、来源限制和路径。若外部连接成功但业务请求失败，继续核验应用层响应。任何防火墙变更都应先备份原规则、限定影响范围，并准备恢复原配置的回滚方式。

建议保存交付资料版本、实例标识、服务器和测试端地址、时间及时区、命令参数及完整输出；磁盘信息、监听状态、外部连接结果、路由和带宽结果也应一并留存。异常发生前后的时间、交付方回复、修复时间和复测结果，能帮助区分配置问题、访问条件问题与测试环境问题。

Linux 可用 script 保存终端会话：

script -a -f acceptance-session.log
date -Is

完成记录后执行：

exit
sha256sum acceptance-session.log

哈希值可用于核对日志文件是否被改动；截图适合作为补充，不能替代带有时间、命令和完整输出的记录。日志若含账号或敏感业务信息，提交前可对副本脱敏，内部保留原始文件。

交付方修复后，尽量用首次验收的测试端、目标、协议和参数复测，并将前后结果并列保存。复核顺序仍从实例身份开始，再查磁盘、端口监听、外部连接、路由和带宽。每项记录为“通过”“待复核”或“不通过”；没有明确阈值的项目应如实注明测试条件和观察结果，避免把一次正常样本扩大解释为持续性能保证。