美国服务器交付后，能登录并不等于验收通过。CPU、内存和磁盘可能与订单描述不一致；服务在本机监听，也可能无法从外部访问；一次测速达标，更不能证明业务时段的带宽稳定。验收应先固定订单约定和测试条件，再按“配置与磁盘—端口—路由—带宽—持续运行”的顺序核对，每项都留下可复测的结果。

开始前，准备订单或交付单、管理控制台和服务器登录权限，并确认约定的是物理机还是虚拟实例、磁盘容量与挂载方式、网络端口速率与带宽计费口径、需开放的业务端口。另准备至少一个服务器外部的测试节点，记录其公网地址、所在网络、测试时间和所用协议。以下服务器侧命令以具备相应权限的 Linux 系统为例；工具未安装时先确认系统环境和安装权限，不要为验收直接改动生产防火墙或磁盘分区。

先定通过标准：以交付约定和业务路径为准

验收不是把命令结果与某个通用“合格值”比较，而是检查交付内容是否符合约定、关键业务路径是否可用。测试前把口径写清楚，可避免出现“测出了速度，却不知道该与什么比较”的情况。

没有写入交付约定的指标，不宜事后当作供应方承诺；但如果它直接影响业务上线，例如特定来源无法连接，即使配置数字相符，也应先列为待排查项。可将每项标记为“通过、待复核、不通过”：证据充分且符合约定才记为通过；测试条件不完整或单次结果异常，先记为待复核。

核对配置真实性：先看资源，再看磁盘能否使用

先在服务器上记录时间和基础信息。下面的查询不修改配置，适合保留为交付时的原始快照：

date -u
uname -a
lscpu
free -h
lsblk -b -o NAME,TYPE,SIZE,MODEL,MOUNTPOINT
df -hT
findmnt /
ip -br addr
ip route

CPU 要区分逻辑 CPU 数、核心数以及交付形式。虚拟实例里看到的处理器型号、主频和逻辑 CPU 数，不能单独证明底层物理 CPU 的独占情况；如果订单约定了物理核心或独占资源，需要结合交付记录和管理侧信息核对。内存以系统识别的总量为主要参考，free 中的“可用内存”会随缓存和进程占用变化，不能拿它直接与订单容量比较。

磁盘至少核对三件事：系统识别到了哪些设备、目标文件系统挂载在何处、挂载后还有多少可用空间。lsblk 展示设备容量，df -hT 展示文件系统容量，两者可能因分区、文件系统开销而不同；十进制 GB 与二进制 GiB 的显示口径也要区分。虚拟化环境未显示底层磁盘型号，不应仅凭这一点判定配置不符。

如果交付要求某块数据盘可用，不要只看它出现在设备列表里，还要用 findmnt -T 确认业务实际写入目录落在哪个文件系统。确需验证读写时，先确认目录已获准用于测试、有剩余空间，且相关业务数据已有备份；只对文件系统中的临时文件操作，不要对 /dev/ 下的设备执行写入测试。例如，将下方目录替换为已批准、确实位于目标磁盘上的目录：

TEST_DIR="/已批准的测试目录"
findmnt -T "$TEST_DIR"
TEST_FILE=$(mktemp "$TEST_DIR/.accept.XXXXXX")
printf 'acceptance-check\n' > "$TEST_FILE"
cat "$TEST_FILE"

能够在预期文件系统中创建并读回文件，说明这一路径具备基本读写能力，不代表磁盘性能或长期健康状态已得到证明。记录生成的文件路径，核对无误后仅清理这次生成的文件；若发生误删，按事先准备的备份恢复。若设备缺失、挂载位置不符或写入失败，先保存 lsblk、df、findmnt 输出及错误信息，不要通过格式化、重新分区来“修好”交付状态。

核对端口：本机监听与外部可达分开判定

端口验收要按“服务是否监听—监听在哪个地址—外部指定来源能否完成连接”逐层进行。先在服务器上查看地址、路由和监听情况：

ip -br addr
ip route
ss -lnt
ss -lnu

ss -lnt 对应 TCP 监听，ss -lnu 可查看 UDP 监听。若服务只绑定 127.0.0.1，外部通常不能直接连接；若端口根本没有监听，应先检查业务服务，而不是立即判断网络端口被封。对使用公网 IP 映射或转发的环境，也不要因为公网 IP 未出现在网卡地址列表中，就直接判定交付错误，应结合控制台映射信息核对。

接着从服务器外部、实际需要访问的网络测试指定 TCP 端口。测试节点装有 nc 时可执行：

SERVER_IP="替换为服务器公网IP"
TCP_PORT="替换为约定的TCP端口"
nc -vz -w 3 "$SERVER_IP" "$TCP_PORT"

连接成功只表示该 TCP 端口在此次测试条件下可建立连接；若交付要求的是具体业务可用，还应完成对应协议的实际请求。连接被拒绝，通常先查监听地址和服务状态；连接超时，则结合服务器防火墙、安全策略、上游访问控制及来源限制排查。不要把 UDP 的“发送成功”当成服务可用，应使用该业务协议的请求与响应验证。

如确需临时调整访问规则，先备份原规则、确认控制台或带外登录可用，明确仅放行哪个测试来源和端口；变更可能影响现有访问或使管理连接中断。测试结束恢复原规则，若变更后失联，通过控制台按备份回滚，而不是继续扩大放行范围。

核对路由：固定方向、节点和时间

“到美国服务器的路由”不是一条对所有用户都相同的路径。至少分别检查目标客户端网络到服务器的方向，以及服务器到关键业务目标的方向；不同运营网络、测试时段、IPv4/IPv6 协议和出口条件下，结果不能直接混用。

在外部 Linux 测试节点上，可对已确认允许探测的服务器公网 IP 做一次基础检查：

SERVER_IP="替换为服务器公网IP"
date -u
ping -c 20 -W 2 "$SERVER_IP"
tracepath -n "$SERVER_IP"

服务器访问业务目标时，则在服务器侧对该目标执行同口径测试，并记录目标地址。这里的 20 次探测仅用于快速发现明显异常，不足以证明长期稳定。目标不响应 ICMP 时，ping 失败也不等于实际 TCP 业务不可用，应回到已约定的业务端口验证。

解释路由结果尤其要谨慎：中间节点不回复探测包，或对探测包限速，并不必然表示业务流量在该节点丢失；去程与回程也可能不同。若发现末端持续异常，先在同一测试节点、同一协议下复测，再换一个已记录来源的节点比较。报告中应写明节点、网络、UTC 时间、目标 IP、命令和样本次数；不能仅凭一张路由截图推断线路归属或普遍访问质量。

核对带宽与稳定性：短测定位，持续观察确认

先确认订单描述的是网卡端口速率、保证带宽、共享带宽，还是按流量计费；这些不是同一个指标。测速前避开正在进行的备份、迁移和大流量任务，记录测试节点的接入网络及其自身带宽限制，否则瓶颈可能在测试端。

双方都已安装 iperf3、测试符合服务使用约定，并且现有访问策略已仅允许指定测试节点连接测试端口时，可以做短时双向测试。在服务器运行一次性监听：

iperf3 -s -p 5201 -1

从外部测试节点向服务器发送数据：

SERVER_IP="替换为服务器公网IP"
iperf3 -c "$SERVER_IP" -p 5201 -t 15

测试服务器向该节点发送数据时，需在服务器重新启动一次性监听，再从测试节点运行：

SERVER_IP="替换为服务器公网IP"
iperf3 -c "$SERVER_IP" -p 5201 -t 15 -R

这里的方向以 iperf3 客户端为参照：普通测试主要观察客户端向服务器发送，-R 主要观察服务器向客户端发送。单连接结果偏低时，可在获得许可后增加并发流复测，以判断是否受单连接条件限制；不要用多连接峰值替代单连接体验，也不要用一次短测证明持续带宽。测试会产生实际流量，可能影响现有业务或流量计费；开始前应确认影响范围，结束后关闭测试监听并撤销临时放行规则。

稳定性验收则应在预先约定的观察窗口内，定时从固定测试节点检查实际业务连接，同时查看服务器运行时间、资源状态和接口错误计数。具备相应权限、系统使用 systemd 时，可辅助检查：

date -u
uptime
ip -s link
systemctl --failed --no-pager
journalctl -k -b -p warning --no-pager

网络接口计数应记录测试前后值，并结合接口流量、是否重启来解释；日志中的一条 warning 也不等于服务器不稳定。若窗口内出现连接中断，应对齐外部探测时间、服务日志和系统日志，区分服务故障、服务器重启与测试节点自身断网。验收阶段不宜在未备份、未约定维护窗口时擅自重启或运行长时间压力测试；需要重启验证的，应先确认业务影响和控制台恢复路径。

异常如何留证，修复后如何复核

发现不符时，先保留原始状态，再处理变更。一次可用于沟通和复核的记录，至少包含：订单中的对应条款、服务器标识和目标 IP、测试节点及其网络、UTC 时间、测试命令或业务请求、完整结果、期望值，以及测试期间是否存在业务负载或访问限制。提交记录前应遮盖密码、令牌和不必要的用户数据。

处理顺序也应与风险相称：配置数量不符，先对照交付单和系统信息；端口不通，先查监听和指定来源，再查访问策略；路由或带宽异常，先用同条件复测，再比较其他节点和时段。需要供应方调整配置、挂载或网络策略的，保留调整前证据，并明确变更窗口、影响范围与回滚方式。不要在争议未确认前自行覆盖原配置，使交付时的状态无法还原。

复核时使用原来的测试节点、方向、协议和方法，另记录修复后的时间与结果；若条件发生变化，要注明差异，不能直接拿两组数字作性能改善结论。最终将通过项、待复核项、不通过项及对应证据一并保存。这样既能判断这台美国服务器是否符合交付约定，也能在后续出现连接或性能问题时，找到可比较的初始基线。