2026-10-19-server-10-50-80-63-unreachable

lq · 10/19/2026

10.50.80.63 连接故障排查（2026-10-19）

做什么 / 为什么

用户报告 10.50.80.63（vllm-dev-63，root/22 及 8322）SSH 连接不上，从本地 macOS 逐步排查定位原因。

排查步骤与关键结果

检测项	结果
ping（ICMP）	✅ 通，4/4 收包，延迟 1.8–7.3 ms，TTL 60
TCP 22 端口	✅ 三次握手成功
TCP 80 端口	✅ 三次握手成功
TCP 8322 端口	✅ 三次握手成功
SSH banner（22）	❌ `Connection timed out during banner exchange`，服务端 0 字节
SSH banner（8322）	❌ 同样超时无 banner
HTTP GET /（80）	❌ curl 28 超时，0 字节响应
尝试 vllm-dev-35 跳板	❌ `Permission denied (publickey,password)`，本机无该机凭据

结论

网络层完全正常（ICMP/TCP 均通），但所有端口的应用层协议（SSH/HTTP）完全不响应。 典型症状是「TCP 能建链、应用层无应答」，指向服务器本身处于半死状态，而非网络/防火墙问题：

内核网络栈还在工作（回 ICMP、接受 TCP 握手、socket accept 队列正常完成握手）
但用户态进程全部无响应——sshd（22 与 8322 两个实例）和 HTTP 服务都不回数据

最可能的原因（按概率排序）：

服务器负载极高或资源耗尽：CPU/内存/磁盘 IO 打满、OOM 频繁、swap 死亡循环，用户态进程无调度机会。若该机在跑 vLLM/大模型推理，大概率是显存/内存耗尽或推理任务把机器压死
fs 挂载异常（如 NFS/网络存储 hang），sshd 等
内核活锁/驱动问题（如 GPU 驱动 D 状态锁死）

基本可以排除：网线/交换机故障、IP 冲突、防火墙 DROP（那样 TCP 握手不会成功）。

影响

SSH（22/8322）与 HTTP（80）均无法使用，该机在跑的服务对外不可用
无法远程登录，需机房/带外管理（IPMI/BMC）或现场介入恢复

后续建议

走带外管理通道：IPMI/BMC/iDRAC 控制台登录，查看是否 OOM、D 状态进程堆积、GPU/NVMe 驱动异常
若无带外，联系机房现场接显示器键盘，或直接硬重启（长按电源/拔电）
恢复后登录检查：dmesg | grep -i -E 'oom|nvidia|nvme'、journalctl -b -1 -u ssh、nvidia-smi、df -h、uptime，确认根因（大概率是推理任务把内存/显存压爆）
如有同网段可达的兄弟机（如 10.20.152.x 系列），配置好密钥后可从那边 ssh/ping 交叉验证

排查环境：本地 macOS（本机直连），记录时间 2026-10-19 09:54 +08
SSH config 相关条目：10.50.80.63（root/22）、vllm-dev-63（root/8322）

补充：traceroute 结果（09:55 完成）

 1  * * *              （本机网关不回 TTL 超时）
 2  10.23.252.1   ~3-22ms
 3  10.0.1.25/.33 ~3-6ms
 4  10.0.1.22/.18 ~2-3ms
 5+ * * *              （后续跳点静默）

前 4 跳响应正常且延迟无异常跳变；第 5 跳起全部静默属常见现象（中间路由器普遍不回 ICMP TTL exceeded）。结合 ping 双向通 + TCP 握手成功，网络路径无断点，维持原结论：服务器本机假死（应用层无响应），非网络故障。

补充：假死根因分析（10:20-10:35 复盘）

服务器重启后状态（10:20）

10:07 重启，SSH 已恢复；48 核 / 128G 内存 / 5×L20 GPU / openEuler 6.6 内核 / K8s master1 + containerd+docker 双运行时
load 50（高但可用）；无 swap；GPU 0/1 号卡被 vLLM 占用，其余空闲
journald 未持久化（无 /var/log/journal），上次启动内核日志全部丢失，只能靠 sar + docker logs + .bash_history 取证

sar 时间线（关键证据）

时间	sda 写入	%util	await	iowait	load	D 状态任务
~05:40 前	正常 ~2-3MB/s	~30%	~15ms	低	~120-150	~100
05:50	86 MB/s	69%	189ms	—	—	—
06:28（峰值）	508 MB/s	86%	168ms	—	—	—
06:39-09:54	12-37万 kB/s	98.8%	256ms	86%	450-680	350-550
10:07	重启

CPU iowait 从正常值飙到 86%，即几乎所有 CPU 时间都在等磁盘；load 从 ~140 冲到 680；350-550 个任务长期 blocked。整机 48 核被磁盘 IO 卡死，用户态进程（含 sshd）拿不到调度——这就是「TCP 能握手但 SSH 无 banner」的直接原因。

注：故障期间内存 94% 使用率但 sar -W 显示换页为 0（swappiness=0 且无 swap 设备），排除 swap 抖动主因；kbcommit 236% 是长期慢性内存 overcommit，属背景风险。

根因

.bash_history 时间线（.bash_history mtime 06:22:34，/root mtime 06:22:36）：

06:2x  cd /root/dbbackup/ && bash deploy.sh -c deploy.conf
06:2x  bash restore.sh --version
06:2x  kubectl -n highgo exec highgo-repo-host-0 -c pgbackrest -- pgbackrest --stanza=db --repo=2 info
06:22  bash restore.sh        ← 触发点

06:22 有人在这台机器上执行了 HighGo 数据库还原脚本 restore.sh（还原 HighGo + MinIO 备份），触发大规模备份下载/落盘。sar 磁盘写入从 05:50 开始爬升（对应 cron 05:30 的 minio-mirror 增量同步仅 1 分钟完成、Total 0B，可排除），06:28 达峰值 508MB/s，随后 sda 单盘 98.8% 饱和持续 3.5 小时。

佐证：MinIO 容器日志 06:55（UTC 22:55）报 taking drive /data offline: unable to write+read for 37.559s —— 磁盘健康但被写满队列，健康检测写超时 37 秒。

同时排除：

minio-mirror.sh cron（05:30 那轮 1 分钟完成、传输 0B）
OOM（故障期间内存 94% 但无 swap-in/out、无 OOM killer 痕迹）
GPU/NVMe/文件系统硬件故障（dmesg 无相关错误）

为什么会「假死」而不是彻底断网

内核网络栈软中断处理优先级足够，ICMP 应答、TCP 握手（内核态完成）不受影响 → ping 通、端口开
sshd 用户态进程因内存分配/日志写入等被磁盘 IO 阻塞（写 /var/log、加载 PAM 模块等），banner 发不出来 → SSH 握手超时
D 状态任务大量堆积 → systemd/kubelet/containerd 全部被拖慢，整机服务无响应

遗留风险与建议

highgo-standby 容器正在崩溃重启循环：license 加载失败（hg_lic load license file failed，备份 license 文件超 100 个上限），需清理 $HGDB_HOME/etc/lic/ 后重启
数据库还原未完成：/var/lib/dbbackup-restore 只有 10-15 的旧 run 目录，今天 06:22 的还原没有产物——操作人需确认是否重跑
无 swap 且 overcommit 236%：内存冗余不足，一旦 IO 风暴叠加内存压力更易死锁，建议评估配置小 swap 或调低 overcommit
journald 未持久化：建议开启 Storage=persistent，下次故障可查内核日志
单盘 sda 承载一切（22T 系统盘同时是数据盘）：备份/还原类大 IO 任务建议限速（如 pv -L、mc --limit、ionice）或错峰执行，避免再次压死整机
载入还在跑：podman load -i images/template/allinone.tar（10:15 启动）目前 sda %util 82%，建议等它完成后再做其他大 IO 操作