VSCode Remote-SSH 远程 Windows Server 卡死的排查与解决

最近遇到一个比较隐蔽的 VSCode Remote-SSH 问题：同一台远程 Windows Server 服务器，网络本身是通的，普通 SSH 客户端也可以连接，其他人也能通过 Tailscale 访问这台机器，但是我自己的 VSCode 1.113.0 突然无法重新连接远程项目。

问题最终不是 Tailscale，也不是 SSH 配置，而是远端残留的 VS Code Server 进程异常。强制终止远端 VS Code 相关进程后，VSCode 重新连接时触发了"正在下载 VSCode 服务器"，下载完成后连接恢复正常。

这篇文章记录一下现象、排查过程、原因分析和解决办法。

问题现象

我的环境大致如下：

本地使用 VSCode 1.113.0。

远端是一台通过 Tailscale 访问的 Windows Server。

VSCode 通过 Remote-SSH 连接远端服务器。

远端同时存在 WSL 环境，并且 WSL 的 SSH 也能正常连接。

问题发生前几个小时，我还可以正常使用 VSCode 打开远端项目。但是关闭远程窗口后，再次连接就异常了。

具体表现包括：

VSCode 连接时一直要求输入密码。

多次输入密码后仍然无法打开项目。

VSCode 资源管理器没有列出远端项目文件。

打开文件窗口里显示的是本地路径，而不是远端路径。

VSCode 最近项目中也找不到上次打开过的远端项目路径。

连接过程看起来像是卡住了，但又没有明确报出 SSH 连接失败。

这些现象一开始很容易让人误以为是 Tailscale、SSH 配置、密码或远程目录权限出了问题。

初步判断

首先排除网络和 SSH 层问题。

因为其他人可以通过 Tailscale 连接这台服务器，而且我使用其他 SSH 客户端也可以连接，所以 Tailscale 网络本身大概率没有问题。

同时，最近没有修改 SSH 配置，普通 SSH 登录也正常，所以也不像是 sshd 配置、用户名、密码、密钥权限突然出了问题。

真正异常的是 VSCode Remote-SSH。

VSCode Remote-SSH 并不是简单地建立一个 SSH 终端。它的连接过程大致可以理解为：

本地 VSCode 先通过 SSH 登录远端。

然后在远端启动或安装 VS Code Server。

本地 VSCode 通过远端 VS Code Server 访问远端文件、终端、扩展和工作区。

因此，普通 SSH 能连，只能说明 SSH 入口是通的，并不能说明 VSCode Remote-SSH 一定能正常打开远端工作区。

关键线索

这次问题里有几个非常关键的线索。

第一个线索是：普通 SSH 客户端可以连接。

这说明不是基础网络、Tailscale 或 SSH 认证完全失败。

第二个线索是：VSCode 资源管理器没有显示远端文件，而打开文件窗口显示本地路径。

这说明 VSCode 并没有真正进入远端工作区。如果 Remote-SSH 连接成功，打开文件、资源管理器、终端等上下文都应该是远端环境。

第三个线索是：最近项目记录中没有上次的远端项目路径。

这通常说明上一次远端窗口可能没有正常保存工作区状态，或者本次连接根本没有成功恢复到远端窗口状态。

第四个线索是：强制终止远端 VS Code 相关进程后，再次连接时出现"正在下载 VSCode 服务器"。

这个现象非常关键。它说明 VSCode 在重新连接时没有继续复用之前那个异常的远端 server 状态，而是重新下载并启动了一套新的 VS Code Server。下载完成后能恢复正常，基本可以确认问题集中在远端 VS Code Server 进程或其状态目录上。

最终解决办法

最终的解决方式是：强制终止服务器远端的 VS Code 相关进程，然后重新连接。

在远端 Windows Server 上，可以通过任务管理器查找并结束相关进程。常见进程可能包括：

Code.exe

node.exe

与 .vscode-server 目录相关的 node 进程

远端 VS Code Server 相关进程

更稳妥的方式是先关闭本地 VSCode 的远程窗口，然后在远端结束 VSCode Remote-SSH 残留进程。

结束后重新从 VSCode 执行：

Remote-SSH: Connect to Host...

再次选择对应远程主机。

这时 VSCode 出现"正在下载 VSCode 服务器"的提示。等待下载和安装完成后，远端项目可以正常打开，资源管理器也恢复显示远端文件。

原因分析

这次问题的根因大概率是远端 VS Code Server 进程异常残留，导致 VSCode Remote-SSH 在复用旧 server 时卡死。

VSCode Remote-SSH 的工作机制决定了它依赖远端的 VS Code Server。每次连接时，本地 VSCode 会检查远端是否已经存在对应版本的 server。如果存在，通常会尝试复用；如果不存在，或者版本不匹配，则会重新下载并安装。

问题可能出现在以下阶段：

远端旧的 VS Code Server 进程没有正常退出。

旧进程仍然占用某些连接状态、端口、锁文件或内部 IPC 状态。

本地 VSCode 再次连接时误以为远端 server 可用，于是尝试复用。

但这个 server 实际已经处于半死不活的状态，导致连接卡住。

因为 SSH 登录本身是成功的，所以用户看到的不是传统意义上的 "Connection refused" 或 "Permission denied"，而是反复输入密码、连接卡死、资源管理器不显示远端文件、打开文件仍是本地路径等更迷惑的现象。

这也解释了为什么普通 SSH 客户端正常，但 VSCode Remote-SSH 不正常。

普通 SSH 客户端只需要完成登录，然后启动一个 shell。

VSCode Remote-SSH 还需要在远端启动 VS Code Server，并完成本地客户端与远端 server 的握手。

所以二者的故障边界不一样。

为什么强杀进程有效

强制终止远端 VS Code 相关进程后，旧的异常 server 状态被打断。

再次连接时，VSCode 无法继续复用那个异常状态，于是重新进入 server 安装流程，表现为"正在下载 VSCode 服务器"。

这个过程相当于让 Remote-SSH 重新初始化远端运行环境。

因此，下载完成后连接恢复正常。

这也说明：这次问题不一定需要修改 SSH 配置，也不一定需要重装 VSCode，更不一定是 Tailscale 出问题。关键是要清理远端 VS Code Server 的异常运行状态。

推荐排查顺序

如果以后再次遇到类似问题，可以按照下面顺序排查。

首先，用普通 SSH 客户端连接远端服务器。

如果普通 SSH 都连不上，再排查 Tailscale 网络、SSH 服务、端口、用户名、密码、密钥和防火墙。

如果普通 SSH 可以连接，但 VSCode Remote-SSH 不行，就不要优先怀疑网络层，而应该重点看 VSCode Remote-SSH 的远端 server。

然后，在 VSCode 中打开 Remote-SSH 日志。

可以执行：

Remote-SSH: Show Log

重点关注日志中是否有 server install、server start、vscode-server、timeout、failed to parse remote port、permission denied、already running、download、resolver error 等信息。

接着，可以尝试 VSCode 自带命令：

Remote-SSH: Kill VS Code Server on Host...

这个命令会尝试终止远端 VS Code Server，并让下次连接重新初始化。

如果这个命令无效，或者 VSCode 已经卡到无法正常执行该命令，就直接到远端服务器上手动结束 VS Code Server 相关进程。

最后再重新连接。如果重新连接时出现"正在下载 VSCode 服务器"，说明 VSCode 正在重新安装远端 server。等待完成即可。

Windows Server 上的手动处理方式

如果远端是 Windows Server，可以先关闭本地 VSCode 的远程窗口，然后在远端服务器打开任务管理器，结束和 VSCode Remote-SSH 相关的进程。

也可以使用 PowerShell 查看相关进程：

Get-Process | Where-Object {
    $_.ProcessName -like "*Code*" -or
    $_.ProcessName -like "*node*"
} | Select-Object Id, ProcessName, Path

如果确认某些 node.exe 来自 .vscode-server 目录，可以结束它们。

为了避免误杀其他业务进程，不建议无脑结束所有 node.exe。应该先看进程路径，确认它确实来自 VSCode Server。

可以使用下面的方式筛选路径中包含 .vscode-server 的进程：

Get-CimInstance Win32_Process | Where-Object {
    $_.ExecutablePath -like "*\.vscode-server\*" -or
    $_.CommandLine -like "*\.vscode-server\*"
} | Select-Object ProcessId, Name, ExecutablePath, CommandLine

确认无误后再终止：

Get-CimInstance Win32_Process | Where-Object {
    $_.ExecutablePath -like "*\.vscode-server\*" -or
    $_.CommandLine -like "*\.vscode-server\*"
} | ForEach-Object {
    Stop-Process -Id $_.ProcessId -Force
}

注意，这个操作会中断当前用户下的 VSCode 远程开发会话。如果多人共用同一台服务器，执行前最好确认不要影响其他人的远程开发连接。

Linux 或 WSL 上的处理方式

如果远端是 Linux 或 WSL，可以查看 VS Code Server 相关进程：

ps -ef | grep -E "vscode-server|\.vscode-server|code-server" | grep -v grep

确认进程后再结束：

pkill -f ".vscode-server"

如果担心误杀，也可以先只列出进程，再根据 PID 手动 kill。

ps -ef | grep ".vscode-server" | grep -v grep
kill <PID>

如果 server 状态目录疑似损坏，也可以将目录改名备份，而不是直接删除：

ts="$(date +%Y%m%d-%H%M%S)"
[ -d "$HOME/.vscode-server" ] && mv "$HOME/.vscode-server" "$HOME/.vscode-server.bak-$ts"

这样下次连接时 VSCode 会重新安装 server，同时保留原目录用于回滚或排查。

不建议一上来做的事情

遇到这个问题时，不建议一开始就重装 VSCode。

也不建议一开始就改 SSH 配置。

更不建议直接怀疑 Tailscale 网络问题。

因为普通 SSH 可以连接时，说明基础链路大概率是正常的。此时盲目修改 SSH 配置，可能会把原本正常的认证配置改坏，反而扩大问题。

同样，也不建议直接删除远端项目目录、用户目录或 SSH 配置文件。VSCode Remote-SSH 的问题通常集中在 .vscode-server 目录和相关进程上，不应该影响业务代码。

经验总结

这次问题的关键经验是：普通 SSH 正常，不代表 VSCode Remote-SSH 一定正常。

VSCode Remote-SSH 比普通 SSH 多了一层远端 VS Code Server。如果这个 server 残留、卡死、版本状态异常或启动失败，就会出现 SSH 能连但 VSCode 打不开远端项目的情况。

当出现以下现象时，可以优先怀疑远端 VS Code Server：

普通 SSH 客户端可以连接。

VSCode Remote-SSH 一直卡住或反复要求输入密码。

资源管理器不显示远端文件。

打开文件窗口显示本地路径。

最近项目中远端项目记录异常消失。

执行强杀远端 VS Code 进程后，再连接出现"正在下载 VSCode 服务器"。

这种情况下，优先处理方式是：

先确认普通 SSH 是否能连。

如果普通 SSH 能连，查看 Remote-SSH 日志。

尝试执行 Remote-SSH: Kill VS Code Server on Host...。

如果无效，手动终止远端 .vscode-server 相关进程。

必要时备份并重建 .vscode-server 目录。

重新连接，等待 VSCode 重新下载并安装远端 server。

这类问题本质上不是网络不通，而是 VSCode Remote-SSH 的远端运行环境卡在了一个异常状态。把远端 VS Code Server 清理干净，通常比反复修改 SSH 配置更有效。