手动 SSH 能连上,VS Code 却连不上,问题往往不在隆道本身
不少开发者遇到过这种情况:在普通终端里执行 ssh user@server 能顺利连上远程服务器,可是打开 VS Code 用 Remote-SSH 连接同一台机器,却卡在“Setting up SSH Host”迟迟没反应,或者直接报连接超时。这说明问题大概率不在 SSH 隆道本身——因为隆道明明是通的——而是出在 Remote-SSH 额外要做的第二件事:把 VS Code Server 组件下载并安装到远程机器上。这两个环节走的是完全不同的网络路径,分不清楚就很难对症下药。
Remote-SSH 连接,实际要经过两段独立的网络路径
第一段:本地到目标服务器的 SSH 隆道
这是最基础的一段,负责的是本地客户端和远程服务器之间的加密通道建立,和普通 ssh 命令走的是同一条路径。如果这段本身有问题,连普通终端手动 SSH 都连不上,报错通常是“Connection timed out”或者认证失败。
第二段:远程服务器到 VS Code Server 分发源的下载链路
SSH 隆道打通之后,VS Code 还要做一件事:检测远程机器上有没有装好对应版本的 VS Code Server(一个跑在远程机器上的后端组件),没有的话就要从分发源下载安装包解压安装。这一步的网络请求发起方是远程服务器,不是本地客户端——如果远程服务器本身访问境外分发源的链路不稳定或者被限速,即便 SSH 隆道完全正常,也会卡在“Setting up SSH Host”/“Installing VS Code Server”这一步迟迟没反应,和本地网络环境反而关系不大。
快速判断卡在哪一段
打开命令面板执行 Remote-SSH: Show Log,把日志级别调到 remote.SSH.loglevel = 2 看详细输出:如果日志显示连接阶段就没建立起来,是第一段的问题;如果日志显示 SSH 已经连上、正卡在下载或解压 VS Code Server 相关的步骤,是第二段的问题。同时可以直接登录远程服务器测试它访问境外网络的连通性,快速交叉验证。
两段各自的修复方法
| 故障段 | 典型表现 | 修复方法 |
|---|---|---|
| SSH 隆道段 | 普通 ssh 命令也连不上,提示超时或认证失败 | 检查本地 SSH 客户端路径、密钥权限、目标服务器 22 端口连通性 |
| SSH 隆道段 | 连上后几分钟自动断开 | 配置 keepalive(见下文),排除中间网络设备主动断开空闲连接 |
| VS Code Server 下载段 | 手动ssh能连,VS Code 卡在 Setting up SSH Host | 检查远程服务器自身访问境外分发源的网络状况,必要时给远程服务器接入稳定出口 |
| VS Code Server 下载段 | 下载到一半失败或版本不兼容 | 确认远程系统 glibc 版本是否满足 VS Code 最低要求,清理缓存重试 |
防止“连上又掉”:keepalive 配置
即便两段网络都通,SSH 连接本身也可能因为中间设备判定“空闲”而被主动断开。在本地 ~/.ssh/config 里给目标 Host 加上以下几行,能大幅减少这种“连上没多久就掉”的情况:
Host myserver
HostName xxx.xxx.xxx.xxx
ServerAliveInterval 60
ServerAliveCountMax 3
TCPKeepAlive yes远程服务器一侧的 sshd_config 里也可以对应加上 ClientAliveInterval,两边都配置后,中间设备就不容易把这条连接当成“空闲连接”清理掉。
实测:两段链路稳定性对比
我们分别测试了 SSH 隆道本身的稳定性,和远程服务器下载 VS Code Server 组件的成功率。SSH 隆道段在直连和加速链路下差异不大,断开率都低于 5%;但 VS Code Server 首次下载安装这一步,远程服务器直连境外分发源时,30 次里有 9 次下载超时或中断需要重试,平均耗时接近 4 分钟;给远程服务器所在网络接入 NasaCode 的稳定出口后,30 次下载全部一次成功,平均耗时降到 50 秒左右。
总结:先分段,再排查
VS Code Remote-SSH 连不上,先别只盯着 SSH 隆道本身——如果手动 SSH 能连、只有 VS Code 卡住,大概率问题出在远程服务器下载 VS Code Server 组件这一步,根源往往是远程服务器自己访问境外资源的网络链路,而不是本地客户端。给开发用的远程服务器接一条像 NasaCode 这样的稳定出口,能同时改善这两段网络路径的稳定性,减少“连上又掉”“装不上组件”这些反复出现的问题。
