SSH 提示 `Connection timed out` 怎么处理？网络、防火墙和安全组排查

`Connection timed out` 的重点是“没有响应”。它不代表密码错，也不直接代表 SSH 服务配置错，而是客户端发出的连接请求没有在规定时间内收到目标端口回应。排查这类问题，应按网络链路从外到内推进，而不是一上来就改密码、改密钥或重装系统。

用一条路径理解超时

客户端访问 SSH 大致经过：本地网络 -> 运营商线路 -> 服务器公网 IP -> 云安全组或上游防护 -> 系统防火墙 -> SSH 监听端口。任何一层丢弃请求，都可能表现为超时。

第一步：确认是不是只有 SSH 不通

先测试服务器是否还有其他服务可访问，比如网站、面板或业务端口。如果网站也打不开，SSH 也超时，问题可能不只在 SSH。此时不要只围绕 SSH 配置排查，应先确认服务器实例是否运行、IP 是否正常、线路是否异常。

本地可以先执行：

ping 服务器IP

ping 不通不能单独作为宕机证据，因为有些服务器禁 ICMP。但如果 ping 不通、端口也不通、控制台也无法进入，就需要服务商协助确认实例和网络状态。

第二步：测试端口是否可达

nc -vz 服务器IP 22

如果输出 `succeeded` 或类似连接成功，说明端口可达，问题可能已经不是超时这一层，而是认证、密钥或登录策略。如果输出 `timed out`，说明请求没有得到端口响应。如果输出 `refused`，说明目标端口有明确拒绝，排查方向应转到 SSH 服务和监听端口。

没有 `nc` 时可以用：

telnet 服务器IP 22

如果 SSH 改过端口，必须测试真实端口。很多用户只测 22，但服务器实际已经改到 2222，结论自然会偏。

第三步：看路由在哪里中断

traceroute 服务器IP

或：

tracepath 服务器IP

如果路由在本地网关附近中断，先排查本地网络、办公室出口或运营商限制。如果跨境后中断，可能是线路波动。如果接近目标机房后中断，就需要服务商从机房侧确认。

第四步：服务器侧查防火墙和监听

如果能通过控制台进入服务器，检查防火墙：

firewall-cmd --list-all
ufw status
iptables -S

再看 SSH 是否监听：

ss -lntp | grep ssh

如果 sshd 没监听目标端口，外部连接可能超时或拒绝。如果 sshd 监听正常，但外部仍超时，重点转向安全组、上游防护和线路。

需要服务商确认的情况

如果多个地区测试都超时、控制台无法进入、IP 被黑洞、正在攻击清洗、或安全组确认放行但端口仍不可达，就不是用户系统内能完全解决的问题。提交工单时建议提供源 IP、目标 IP、目标端口、测试时间、`nc` 或 `telnet` 结果、traceroute 输出。

不要为了验证而全开放

临时测试可以短时间放行某个明确端口，但不建议把所有端口对所有来源开放。数据库、Redis、面板、Docker API 等端口一旦暴露，风险远高于 SSH 超时本身。

处理超时问题的顺序应是：确认 IP 是否可达，确认端口是否可达，确认安全组和系统防火墙，确认 sshd 是否监听，最后确认线路和上游策略。每一步都能缩小范围，避免在错误位置反复修改。