SSH 连不上服务器时，几种中转方案的实战总结

很多人都会遇到这种情况：服务器在线，SSH 服务看起来也正常，但本地网络就是连不上，直接 SSH 不是超时就是卡住。

这次我碰到的就是一个很典型的场景：本地网络无法直接连接目标服务器，但通过另一台日本服务器做 SSH 跳板后成功连通。顺着这次排障过程，我把几种常见的中转方案也一起梳理了一遍。

一、先说结论：问题往往不在“域名”，而在“连接路径”

很多人的第一反应是：

我有 Cloudflare 域名，直接把 A 记录解析到服务器，再开代理，是不是就能 SSH 了？

答案是：不行，不能直接靠普通橙云代理原生 SSH。

Cloudflare 普通代理主要面向的是：

• HTTP
• HTTPS
• WebSocket
• 一些 Web 协议相关流量

而 原生 SSH 并不是普通 Cloudflare 橙云直接代理的对象。也就是说：

• 网站开橙云没问题
• SSH 不能指望开个代理就直接打通

所以，很多时候问题不在“域名配没配对”，而在“你现在选的连接路径本身就不适合 SSH”。

二、方案 1：灰云直连（仅 DNS）

适用场景

• 你怀疑是 Cloudflare 橙云影响了直连
• 你的本地网络本身并没有屏蔽服务器
• 你只是想让域名直接解析到服务器 IP

做法

把 Cloudflare 上对应记录从：

• 已代理（橙云）

改成：

• 仅 DNS（灰云）

然后直接测试：

1
ssh root@your-domain.com

本质上等价于：

1
ssh root@服务器IP

优点

• 简单
• 适合快速排查
• 不需要额外安装工具

缺点

• 不解决“本地网络屏蔽服务器”的问题
• 22 端口仍然暴露公网
• 安全性一般

结论

灰云只能解决“别让 Cloudflare 橙云挡住 SSH”这个问题，不能解决网络本身不通的问题。

三、方案 2：Cloudflare Tunnel 中转 SSH

这是更正规的做法。

原理

目标链路会变成：

1
本地 SSH -> cloudflared -> Cloudflare -> Tunnel -> 服务器 localhost:22

也就是：

• 服务器主动连接 Cloudflare
• 本地通过 cloudflared 接入
• 不需要在公网暴露 22 端口

适用场景

• 本地网络不能直连目标服务器
• 服务器本身可以正常出网
• 你已经有 Cloudflare 域名
• 想要长期、安全、规范的方案

优点

• 不必公网暴露 SSH 端口
• 比直开 22 更安全
• 可以结合 Cloudflare Access 做身份控制

缺点

• 配置比灰云复杂
• 服务器端和本地都要安装 cloudflared

适合谁

如果你有 Cloudflare 域名，又希望把 SSH 接入做得更优雅一些，Cloudflare Tunnel 值得长期使用。

四、方案 3：SSH 跳板机 / Bastion Host

这是这次实际排障里真正跑通的方案。

原理

你的本地不能直接到目标服务器，那就先连另一台能访问的机器，再从那台机器跳过去：

1
本地 -> 跳板机 -> 目标服务器

例如：

• 本地不能直连目标服务器
• 但能连上另一台日本服务器
• 日本服务器又能访问目标服务器的 22 端口

这时就可以把日本服务器当作跳板机。

命令行写法

1
ssh -J user@跳板机IP root@目标服务器IP

例如：

1
ssh -J root@jump-server-ip root@target-server-ip

图形客户端

很多 SSH 客户端都直接支持：

• Jump Host
• ProxyJump
• SSH Tunnel
• Bastion Host
• 跳板机

只要在目标连接里指定一台代理主机即可。

这次实测结果

通过图形 SSH 客户端把日本服务器设为跳板后，最终成功登录到目标机。验证方式包括：

• 登录来源显示为跳板机 IP
• hostname 显示为目标服务器主机名
• curl ifconfig.me 与目标服务器公网出口对应

这就能确认：当前会话已经不在跳板机上，而是成功落到了目标服务器。

优点

• 非常实用
• 配置简单
• 网络受限场景往往立刻见效

缺点

• 需要额外一台服务器
• 跳板机本身也要维护安全
• 公共、陌生、免费跳板机不适合作为长期正式方案

结论

如果你手里刚好有另一台可用服务器，SSH 跳板机通常是恢复连接最快的方案。

五、方案 4：Tailscale / WireGuard

如果你的目标不是“用域名优雅接入”，而是“先稳定连上”，那么 Tailscale 或 WireGuard 也非常值得考虑。

原理

本地和服务器都加入同一个虚拟网络：

1
本地 <-> Tailscale / WireGuard <-> 服务器

然后通过分配到的内网地址 SSH。

优点

• 对 NAT、复杂网络环境友好
• 不一定需要暴露 22 端口
• 多台机器统一管理时很方便

缺点

• 需要额外安装客户端
• 对部分只想临时排障的人来说，理解成本略高

结论

如果你管理的不止一台服务器，Tailscale/WireGuard 更像是一种长期网络方案，而不是一次性的补丁。

六、这次排障中最容易踩的误区

误区 1：以为开橙云就等于可以代理 SSH

不是。普通 Cloudflare 橙云适合网站，不适合直接代理原生 SSH。

如果想通过 Cloudflare 做 SSH 中转，应该用：

• Cloudflare Tunnel
• Cloudflare Access / Zero Trust

而不是只改 DNS 开关。

误区 2：以为改灰云就一定能连上

灰云只是“直接解析到服务器 IP”，它不负责解决：

• 本地网络封锁
• 运营商限制
• 服务器 22 端口未开放
• 云厂商安全组拦截
• 服务器防火墙限制

所以灰云只是排查步骤，不是万能修复。

误区 3：只盯着目标服务器，不看连接路径

这次最关键的发现就是：

• 目标服务器并不是彻底不可达
• 真正不通的是“本地到目标服务器这条路径”
• 一旦换成“本地 -> 跳板机 -> 目标服务器”，整个链路立刻恢复

很多 SSH 故障，问题并不在服务器本身，而在“你怎么到达它”。

七、怎么选：不同场景下的建议

1. 只是临时排查

先试：

• 把 Cloudflare 记录改成仅 DNS（灰云）
• 直接 SSH 测试

适合快速确认问题是否来自 Cloudflare 代理。

2. 本地网络受限，但你有另一台服务器

直接上：

• SSH 跳板机

这是恢复连接最快的实战方案。

3. 你有 Cloudflare 域名，想长期正规使用

直接考虑：

• Cloudflare Tunnel

长期看，它比直开 22 更优雅，也更安全。

4. 你管理多台服务器，希望网络统一

考虑：

• Tailscale
• WireGuard

适合长期多机互联。

八、安全提醒：不要长期使用 root + 密码

排查 SSH 时，很多人为了快，会直接用：

• root
• 密码登录

这虽然方便，但风险非常高，尤其在需要截图、远程协助、多次调试跳板机的场景里，密码很容易在不经意间暴露。

更推荐的做法是：

1. 尽快改成 SSH key 登录
2. 验证密钥可用后关闭密码登录
3. 跳板机也要单独做安全加固
4. 避免长期直接使用 root + 密码

九、最后总结

这次排障最重要的结论其实很简单：

当 SSH 连不上时，先别急着怀疑服务器坏了，先判断是不是“连接路径”出了问题。

从这次实战来看：

• Cloudflare 橙云不适合直接代理原生 SSH
• 灰云只是直连解析，不解决网络封锁
• Cloudflare Tunnel 适合长期正规中转
• SSH 跳板机是最快恢复连接的实战方案
• Tailscale/WireGuard 更适合长期多机互联

而这次最终真正跑通的方案，是：

通过一台日本服务器作为 SSH 跳板机，成功连接到目标服务器。

这再次说明：有时候问题不在目标机，而在你怎么到达它。

十、附：几条实用命令

灰云直连测试

1
ssh root@your-domain.com

跳板机连接

1
ssh -J root@jump-server-ip root@target-server-ip

Cloudflare Tunnel 方式连接

1
ssh -o ProxyCommand="cloudflared access ssh --hostname ssh.example.com" root@ssh.example.com

登录后确认当前机器

1
hostname
2
curl ifconfig.me