一次排查云服务器 SSH 连接超时的实战记录

上周要登录一台云服务器做例行巡检，SSH 客户端一直在连接超时上打转，既不报密码错误，也不报密钥错误。超时是最容易误判的一类故障，因为它不告诉你哪一环断了，只能按链路从外到内逐段排除。这次排查的顺序后来证明很有效，记录下来供遇到同样问题的人参考。

第一步先确认客户端侧有没有低级错误。检查目标 IP 和端口是否抄错，本地网络是否正常，换一个网络（比如手机热点）再试一次。如果换网就通了，问题大概率在本地网络或出口策略上，不必急着动服务器配置。这一步花不了两分钟，却能排除一大类干扰。

第二步看云侧的安全组和网络 ACL。SSH 默认走 22 端口，先确认安全组入方向放行了自己的出口 IP 或所在网段，方向不要写反。很多人只放行了 TCP 却忘了源地址写成了内网段，或者规则加在了另一台服务器绑定的安全组上。改完规则后等一两分钟再生效判断，不要连续改多处，否则事后说不清是哪一条起的作用。

第三步确认服务器本身是否在运行、SSH 服务是否在监听。通过云厂商的控制台终端（VNC 方式）登录进去是最直接的办法：它不走 SSH，相当于绕过了网络这一层。进去后先看 sshd 是否在运行，再看监听地址是不是只绑了内网地址或被改过端口。如果服务没起来，查看日志往往能看到配置文件改错、密钥权限不对之类的直接原因。

第四步查系统层面的拦截。主机防火墙规则、fail2ban 之类的入侵防御、以及云服务器安全组之外的网络 ACL 都可能在静默丢包。排查时可以临时放宽一条规则做对照实验，但做完务必恢复原状，并把最终规则写进文档，而不是留在临时放宽的状态。

这次的故障最后定位在安全组：规则加在了错误的安全组上，服务器绑定的那组始终没有放行 22 端口。修正后连接立刻恢复。复盘下来有两个习惯值得保留：一是每次只改一个变量、改完验证一次；二是把安全组、端口、源地址这些关键信息记在部署文档里，下次巡检或换人接手时不用重新猜。超时不可怕，可怕的是凭感觉同时改好几处，最后修好了也不知道原因。