客户端先加详细日志#

1
ssh -vvv -o ConnectTimeout=8 root@8.141.117.145

-vvv 能看到连接停在哪一步。如果一直卡在 connecting，优先查网络和端口。

检查端口#

1
Test-NetConnection 8.141.117.145 -Port 22

端口不通时，不要继续试密码。先看云服务器安全组、防火墙和 sshd 是否监听。

服务器侧检查#

1
systemctl status sshd
2
ss -lntp | grep ':22'
3
iptables -S
4
ufw status

如果服务器能通过控制台登录，就从这些命令开始查。

常见原因#

• 云服务器安全组没有放行 22。

• sshd 服务停止或端口被改。

• 本地网络阻断 22 端口。

• 服务器负载过高，响应很慢。

实战复盘#

把《SSH 连接超时排查》写成可复用排查记录时，我会保留四类证据：原始现象、执行命令、关键输出、修复后的验证结果。少了其中任何一类，下次遇到类似问题都容易重新猜一遍。

排查类文章不要只写最终命令，还要写为什么先查这里。比如端口问题先看监听进程，Nginx 问题先分清 404 和 403，Python 环境问题先确认解释器路径。

如果修复动作有风险，例如杀进程、删文件、改服务配置，就应该写清回退方式。能恢复，才敢在服务器上操作。

最小验收样例#

验收《SSH 连接超时排查》时，我会保留一条修复前命令和一条修复后命令。前者证明问题存在，后者证明问题已经消失，而不是只凭浏览器或终端感觉判断。

如果这篇文章涉及服务器操作，还要记录当前路径、用户、服务名和关键配置文件。排查记录越能还原现场，下次遇到同类问题越不需要重新摸索。

小结#

SSH 超时不是账号密码问题。先证明端口可达，再看 sshd 和登录认证，顺序清楚会省很多时间。