东南亚服务器上线前，不能只确认“服务器能登录”或“能访问互联网”。更可靠的验收方式是：先从实际访问端确认域名、路由和端口，再检查服务器监听、系统环境、运行时依赖和应用自身健康状态。任一环节出现异常，都要区分是解析、链路、主机策略、权限还是应用配置问题。

开始检查前，应准备好业务域名或目标 IP、访问方向、协议与端口、允许的来源网段、应用依赖清单、测试账号以及预期返回结果。所有测试尽量使用与正式业务一致的来源网络和测试数据，并记录执行时间、执行主机、目标地址、命令输出和返回码。

一、先固定上线验收边界

东南亚服务器可能同时承担公网访问、内部服务调用和主动访问外部依赖等不同角色。先把每一条连接写清楚，避免只测到“服务器能出网”，却没有验证真实业务路径。

建议为每个依赖建立一条记录：

来源主机或服务 → 目标域名/IP → 协议与端口 → 身份认证方式 → 预期结果 → 实际结果 → 证据位置

如果无法明确某个依赖的目标、端口或认证方式，不应直接上线后再观察。先向应用负责人确认，否则后续出现超时或认证失败时，很难判断问题边界。

二、从外到内检查网络连通性

1. 确认域名解析和地址选择

在东南亚服务器上执行解析检查。以下命令适用于大多数 Linux 环境：

getent ahosts app.example.com

正常结果应包含业务批准使用的地址，并且应用实际使用的地址族与网络设计一致。如果同时返回 IPv4 和 IPv6，需要分别验证两条路径；不能因为 IPv4 正常，就默认 IPv6 也能使用。

常见异常及含义：

• 没有返回地址：可能是 DNS 配置、域名记录、搜索域或解析服务不可用。
• 返回旧地址：可能存在缓存、TTL 尚未生效，或服务器使用了错误的解析配置。
• 只返回 IPv6，但服务器或上游链路没有可用 IPv6：应用可能表现为连接超时。
• 解析正常但访问失败：问题通常已从 DNS 层转移到路由、访问控制、监听或应用层。

检查服务器使用的地址和路由：

ip -br addr
ip route
ip route get 203.0.113.20

将示例地址替换为实际依赖的目标 IP。ip route get 可以显示内核选择的出口接口和源地址。正常情况是路由存在，出口接口、源地址符合预期；如果源地址不在已批准的访问名单中，后续即使端口开放，也可能被目标侧拒绝。

2. 不把 Ping 当成唯一验收依据

ICMP 可能被目标侧或中间网络限制，因此 Ping 失败不一定代表业务端口不可用；Ping 成功也不能证明 TCP、TLS 或应用认证正常。

ping -c 4 203.0.113.20

这个命令只适合作为辅助观察。若失败，应继续测试实际业务端口，而不是直接判定服务器不可用。

3. 检查实际 TCP 端口

对于非 HTTP 服务，可以在服务器上使用 nc 检查 TCP 建连：

command -v nc
nc -vz -w 5 db.example.com 5432

其中端口必须替换为应用实际依赖的端口。正常结果是连接建立成功；“拒绝连接”通常表示目标端口没有监听或被主动拒绝；“超时”更常见于路由、访问控制、安全策略或目标侧白名单问题。

nc 不存在时，不要为了临时检查随意修改生产环境的软件包。可以使用应用自身的客户端，或者在具备相应工具的跳板机、监控节点上测试。测试必须与真实来源一致：服务器本机能连通，并不代表用户端能访问服务器的入站端口。

对于 HTTPS 入口，使用应用层请求进行验证：

curl -sS -o /dev/null -D - \
  --connect-timeout 5 \
  --max-time 15 \
  -w '\nconnect=%{time_connect} starttransfer=%{time_starttransfer} http=%{http_code}\n' \
  https://app.example.com/health

正常结果应符合业务约定，例如健康检查返回预期状态码，或者出现已批准的跳转。不能只看“建立了 TCP 连接”：如果返回认证失败、路径不存在、上游不可用或证书错误，仍然不能算业务验收通过。

4. 检查 TLS、证书和服务器时间

当 HTTPS、签名请求或短期令牌依赖系统时间时，时间偏差会造成看似随机的认证失败。先检查：

date -u
timedatectl status

如果系统使用 systemd，正常状态应显示时间服务已同步；具体同步方式以操作系统和企业时间源配置为准。没有同步状态、时间明显不准确或时区配置与日志约定不一致，都应先修复并重新验证。

检查证书链和主机名匹配：

openssl s_client \
  -connect app.example.com:443 \
  -servername app.example.com \
  -verify_return_error 

重点观察证书主题、有效期、主机名和验证结果。异常分支包括：

• 证书过期或尚未生效：检查证书部署时间和服务器时钟。
• 主机名不匹配：确认访问时使用的域名与证书覆盖范围一致。
• 证书链不完整：检查服务端是否发送了必要的中间证书。
• 服务器本机能连接，但真实用户端报证书错误：从用户实际访问网络再次验证。

不要使用跳过证书校验的方式作为上线验收标准。临时排查可以帮助定位问题，但不代表正式访问安全有效。

三、检查服务器本身的系统环境

网络路径确认后，再进入主机内部。以下检查以 Linux 为例；如果系统没有对应命令，应先确认发行版和管理方式，不要照搬其他系统的修复命令。

1. 核对系统、架构和运行时

cat /etc/os-release
uname -a
uname -m

将结果与应用支持的操作系统、内核和 CPU 架构要求对照。常见异常包括：

• 架构不匹配，导致依赖程序无法启动。
• 系统版本过旧，缺少应用所需的系统库或加密组件。
• 系统版本过新，应用依赖的接口或运行时行为发生变化。
• 测试环境和正式环境的运行时版本不一致。

只检查“命令存在”还不够，还要确认实际执行路径和版本。按应用实际使用的运行时执行相应命令，例如：

command -v python3
python3 --version

command -v java
java -version

command -v node
node --version

不相关的运行时无需检查。若应用由服务管理器启动，还要确认服务使用的环境变量、工作目录和运行时路径，不能只依据交互式登录用户的环境。

2. 检查磁盘、挂载和文件句柄

df -hT
df -ih
findmnt
free -h
ulimit -n

正常状态不是简单地“磁盘没有满”，而是应用所需目录已挂载、文件系统可写、 inode 充足，且文件句柄上限满足应用要求。重点查看：

• 日志目录是否位于正确的挂载点；
• 临时目录是否可写；
• 数据目录是否使用了错误的文件系统；
• inode 是否耗尽；
• 文件句柄上限是否低于应用并发和连接需求；
• 内存是否存在持续回收或交换压力。

不要凭经验给所有环境设定统一数值。应以应用文档、压测基线和正式业务规模为依据。检查结果应记录“当前值、要求值、判断依据”，而不是只写“资源足够”。

3. 检查服务账号和文件权限

先确认服务由哪个用户运行：

systemctl show app.service -p User -p Group -p WorkingDirectory -p Environment
id appuser
namei -l /opt/app

将 app.service、appuser 和路径替换为实际值。正常情况是：

• 服务账号存在；
• 工作目录和配置目录可访问；
• 证书、密钥等敏感文件不能被无关账号读取；
• 日志、缓存和上传目录具备业务需要的写权限；
• 服务不依赖某个管理员登录会话才能启动。

如果必须调整权限，应先记录原权限和所属关系，限定影响路径，再进行变更。不要使用递归权限修改覆盖整个应用目录。变更前可保存清单，变更后逐项复核；发现异常时按原所属用户、用户组和权限恢复，而不是直接使用宽泛权限替代。

四、检查进程、监听端口和主机策略

1. 验证服务是否真正运行

systemctl is-enabled app.service
systemctl is-active app.service
systemctl status app.service --no-pager
journalctl -u app.service -b --no-pager -n 100

正常结果应是服务已按设计启用、当前处于 active 状态，日志中没有持续重启、端口占用、配置解析失败或依赖连接失败。

需要注意：进程存在不等于业务可用。服务可能已经启动，但仍在等待数据库、消息服务或外部接口；也可能只监听本地地址，无法接受真实用户连接。

2. 核对监听地址和端口

ss -lntup

将输出与业务入口和依赖清单逐项比对：

• 预期端口没有监听：检查服务启动参数、配置文件和启动日志。
• 只监听 127.0.0.1：仅允许本机访问，若设计要求外部访问则不合格。
• 监听 0.0.0.0 或 ::：表示覆盖范围较大，必须与安全策略和入口设计一致。
• 监听了未登记端口：确认是否为管理接口、临时调试服务或遗留进程，并按变更流程处理。
• 本机监听正常但外部连接失败：继续检查主机防火墙、云侧访问控制和真实来源测试。

主机策略只读检查即可：

command -v nft && sudo nft list ruleset
command -v ufw && sudo ufw status verbose

上述命令不会修改规则。若需要调整防火墙或访问控制，必须先备份当前规则、记录影响的来源和目标、明确维护窗口，并准备恢复原规则的回滚步骤。不要在未确认管理连接仍可用的情况下直接清空规则或放开所有来源。

五、逐项验证应用依赖

建议把依赖检查做成矩阵，而不是只测试一个首页。

对数据库、消息服务等有写入风险的依赖，应使用专用测试账号和隔离测试数据。不要用生产业务数据验证“写入是否成功”。测试完成后清理测试对象或消息，并保留清理记录。

认证信息检查应遵循两点：一是确认服务实际读取的是正式配置，而不是管理员当前会话中的临时变量；二是不把密码、令牌、私钥直接粘贴进命令历史、工单或截图。证书和密钥只记录路径、权限、指纹或有效期等必要信息。

六、按结果分支定位问题

可以按照下面的顺序判断，避免一开始就重启服务或修改防火墙：

1. 解析失败

先检查 DNS 配置、记录和地址族。解析未恢复前，不进入端口和应用排查。

1. 解析正常但路由不存在

检查目标网段、默认路由、出口接口和实际源地址。涉及路由调整时，先确认不会中断当前管理连接，并保留原路由配置以便恢复。

1. 路由存在但 TCP 超时

依次核对目标侧白名单、云侧访问控制、主机防火墙和中间网络策略。超时通常不等同于应用进程崩溃。

1. TCP 被拒绝

优先检查目标端口是否监听、服务是否启动、监听地址是否正确。若本机端口已监听，再检查目标侧策略。

1. TCP 成功但 TLS 失败

检查服务器时间、证书链、主机名、受信任的根证书和协议配置。不要用关闭校验的方式结束排查。

1. TLS 成功但应用返回错误

查看认证材料、接口路径、请求格式、账号权限和应用日志。此时网络基本可用，继续改动路由或防火墙通常没有帮助。

1. 应用偶尔成功、偶尔失败

对比 IPv4/IPv6、不同出口、不同依赖、连接池和超时日志，记录每次测试的时间与目标地址。不要只用一次成功结果判定上线。

七、修复后如何复测和留证

任何配置变更都要先确定影响范围。修改服务配置、监听地址、访问控制或路由前，应完成以下准备：

• 保存原配置、原规则或原路由信息；
• 确认当前管理连接和备用登录方式可用；
• 明确变更影响哪些来源、端口和业务；
• 使用软件自带的配置校验命令；
• 约定失败后的恢复动作和执行人。

配置校验通过后，再在维护窗口内进行必要的服务重载或重启。重启可能中断现有连接，不能在高峰期无计划执行。若变更后服务未恢复，应停止继续修改，先读取服务状态和本次启动日志；确认原因后恢复备份配置，再按原顺序复测。

每次复测至少保留：

date -u '+%Y-%m-%dT%H:%M:%SZ'
hostname
ip -br addr
ip route
getent ahosts app.example.com
ss -lntup
systemctl is-active app.service

网络测试记录还应包含来源主机、目标域名或 IP、端口、协议、返回码和测试时间。敏感信息需要脱敏，不能上传完整密码、令牌、私钥或带认证头的请求日志。

最终验收应满足三个条件：真实访问来源能够按预期访问入口；东南亚服务器能够按指定协议访问全部必要依赖；应用日志、监控和告警能够反映成功与失败。上线后继续观察启动日志、连接错误、时间同步、磁盘增长和依赖响应情况，至少覆盖一次正常请求和一次预先设计的异常告警。这样才能确认检查结果不仅在命令行上成立，也在实际业务链路中成立。