根本原因是服务器端sshd空闲超时或防火墙/NAT丢弃连接，需两端配合：服务端启用ClientAliveInterval 60和ClientAliveCountMax 3并重启sshd，客户端检查~/.ssh/config避免冲突，同时清理VSCode残留进程并更新扩展。
SSH连接被服务器主动断开（Connection closed by remote host）
相信不少开发者都遇到过这个场景：正专注编码时，VSCode的Remote-SSH插件突然弹出一个“Disconnected from server”的提示，终端里则留下一句冷冰冰的 Connection closed by remote host。问题出在哪？其实，这多半不是你的网络问题，而是服务器端的SSH守护进程（sshd）设置了空闲超时机制。比如，默认的 ClientAliveInterval 和 ClientAliveCountMax 参数值可能偏低，或者更底层一些，是防火墙或NAT设备在连接空闲一段时间后，直接丢弃了TCP连接。
所以，解决思路不能只盯着客户端，必须两端配合调整。具体怎么做？
- 首先，登录到你的服务器，编辑
/etc/ssh/sshd_config这个配置文件。找到并确保以下两行是生效的（如果被注释了，就取消注释并调整数值）：ClientAliveInterval 60
这两行的作用很明确：服务器会每隔60秒向客户端发送一个保活探测包，如果连续3次（也就是大约3分钟）都得不到任何回应，才会判定连接失效并断开。这个时间窗口对大多数开发间歇来说，已经足够宽裕了。
ClientAliveCountMax 3 - 配置修改后，别忘了重启SSH服务让改动生效。在Linux上通常是
sudo systemctl restart sshd，而在macOS上则用sudo launchctl kickstart -k system/com.openssh.sshd。 - 客户端这边，通常无需专门修改VSCode的设置。但有个细节值得检查：看看你本地的
~/.ssh/config文件里，是否已经为这个主机设置了ServerAliveInterval参数。如果有，建议要么删除它，要么将其值也设为60，目的是避免客户端和服务器的保活机制产生冲突，反而导致意外断开。
VSCode Remote-SSH 不自动重连（显示“Reconnect”按钮但不触发）
另一种更让人恼火的情况是：连接断了，VSCode也乖巧地显示了“Reconnect”按钮，但你一点下去，要么毫无反应，要么弹个窗口就卡在那里。指望它像一些智能终端那样自动重试？基本不可能。这通常是因为VSCode的Remote-SSH扩展缓存了旧的、错误的连接状态，或者底层的SSH进程已经僵死了。
遇到这种情况，别急着反复点击。按照下面这个顺序操作，往往能快速解决问题：
- 第一步，在VSCode里按下
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），打开命令面板。输入并运行Remote-SSH: Kill VS Code Server on Host...这个命令，然后选择对应的远程主机。这个操作非常关键，它能清理掉服务器上可能残留的vscode-server进程和临时目录，相当于给远程环境来一次“重启”。 - 第二步，关闭当前的远程窗口。这里有个要点：**不要选择“Keep Window”**，而是应该彻底退出VSCode应用程序，然后重新启动它，再用Remote-SSH去连接。这样可以确保客户端的扩展状态也被完全重置。
- 第三步，检查一下你的Remote-SSH扩展版本。确保它已经更新到最新版（例如v0.107.0及以上）。一些旧版本在某些特定的Linux发行版（比如老旧的CentOS 7）上，会因为对
glibc库版本的兼容性问题，导致重连时静默失败，而你却看不到任何错误提示。
远程开发环境启动慢 / 卡在“Setting up SSH Host”
严格来说，这不算连接断开，但它的表现——VSCode状态栏长时间显示“Setting up SSH Host”，鼠标悬停提示“Installing VS Code Server…”且进度条一动不动——足以让任何人误以为连接失败了。问题的本质，是VSCode在尝试下载或解压远程服务器端的 vscode-server 组件时遇到了阻碍，常见原因包括网络策略限制和磁盘权限不足。
排查时，可以重点关注这几个方面：
- 权限问题：手动登录服务器，检查
~/.vscode-server这个目录的权限。它必须属于当前用来连接的用户，并且组和其他用户不应有写入权限（可以用chmod 755 ~/.vscode-server来修正）。一个典型的坑是：如果你之前曾经用sudo权限运行过VSCode的远程命令，这个目录就可能变成了root所有，导致后续普通用户无法写入。 - 网络问题：很多公司的内网会屏蔽GitHub或限制TLS SNI，而VSCode默认会从
update.code.visualstudio.com下载server组件。这时候，可以采取离线安装的方式：先在一台能正常联网的机器上，下载对应平台（如linux-x64）的vscode-server-linux-x64.tar.gz文件，然后通过scp将其传输到服务器上~/.vscode-server/bin/目录下对应的commit ID子目录中。 - 扩展干扰：某些扩展同步配置（例如
"remote.extensionKind": {"ms-vscode.vscode-typescript-next": ["ui"]}）可能会干扰远程环境的初始化。作为临时测试，你可以在~/.ssh/config文件中对应主机的配置块里，加入"disableExtensions": true这一行，暂时禁用所有扩展来连接，看看速度是否恢复正常。
如何让 VSCode 在断连后真正“自动”恢复工作区
必须明确一点：出于安全和资源控制的考虑，VSCode Remote-SSH本身并不支持在后台自动重连。所以，我们追求的“自动”，更多是指通过一些配置和最佳实践，尽可能保留工作上下文，并将重连后的人工操作降到最少。
一套实用的组合策略是这样的：
- 启用
remote.restoreEditorsOnRestart这个设置（将其值设为true）。它的作用是，在连接意外中断并重新建立后，VSCode会自动为你恢复上次打开的所有文件及其编辑位置，让你能立刻接上之前的思路。 - 将你常用的终端初始化命令（如进入特定项目目录、设置环境变量等）写进服务器的
~/.bashrc或~/.zshrc文件里。同时，确保VSCode设置中的shellIntegration.enabled是开启状态。这样，每次重连后打开新终端，shell状态都能快速复原，无需再手动执行一堆cd和source命令。 - 最重要的一点是，改变工作习惯：不要依赖“远程窗口必须一直开着”这种脆弱的工作流。例如，如果你有一个需要长期运行的开发服务器命令（如
npm run dev），不要直接在前台运行。改用tmux或screen这类终端复用器来启动它。这样，即使VSCode断连，后台进程也不会受影响，重连后只需一个简单的tmux attach命令，就能回到完整的工作现场。
当然，对于那些依赖持续TCP连接的服务——比如通过VSCode转发的数据库端口，或者需要监听特定端口的Docker守护进程——它们不会随着SSH重连而自动恢复。这部分确实需要单独设计保活或重连逻辑，不能指望Remote-SSH来解决所有问题。话说回来，把基础连接的稳定性解决好，已经能消除日常开发中绝大部分的恼人中断了。
