必须同步清理本地和远程.vscode-server目录并执行Remote-SSH: Kill VS Code Server on Host，否则因VSCode 1.86+签名校验变严格，残留缓存会导致连接卡在“Installing VS Code Server”或报Cannot read property 'length' of undefined错误。
终端掉线不是 VSCode 故障，而是 SSH 连接被中间设备或服务端主动切断；重置的关键是清理残留进程 + 强制重建连接上下文，不是点“重连”按钮。
Terminal 卡在 “Connecting…” 或直接空白
这是最典型的终端子通道断连现象：VSCode 界面还在，但终端底层 SSH 会话已死，remote.SSH.keepAlive 完全不干预该通道。常见于 NAT 超时、WiFi 切换、休眠唤醒后。
- 别等它自己恢复——VSCode 不会自动重连终端会话，必须手动干预
- 先确认状态栏左下角是否还显示
SSH: user@host；若已消失，说明整个远程会话已断，终端必然不可用 - 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并运行Remote-SSH: Kill VS Code Server on Host，选目标主机 - 关闭当前 VSCode 窗口（必须彻底退出，不要选“Keep Window”）
- 重启 VSCode 后，再用
Remote-SSH: Connect to Host重连——终端会随新会话一起初始化
Terminal 能打开但命令无响应、光标卡住
这通常是远程 vscode-server 进程僵死或资源耗尽所致，比如内存溢出、fd 耗尽、或 ~/.vscode-server 下的 socket 文件被锁住。
- 不要在 VSCode 内部尝试重启终端——它复用的是已损坏的通道
- 用系统终端（如 Terminal、iTerm、PuTTY）SSH 登录同一用户，执行：
ps aux | grep -E "(vscode-server|code-server)" | grep -v grep - 若有残留进程，用
pkill -f "vscode-server"杀干净；再执行rm -rf ~/.vscode-server - 回到 VSCode，彻底退出后重连——这次终端会从零部署，不再继承旧状态
- 如果仍卡，检查远程磁盘空间：
df -h ~；vscode-server解压失败时也会静默卡住
为什么改了 remote.SSH.keepAlive 没用？
这个设置只保活 VSCode 的控制通道（比如设置同步、命令面板响应），对终端、端口转发、文件监听等子通道完全无效。它甚至不发任何网络包，纯属 UI 层心跳。
- 真正起作用的是 SSH 底层保活，必须写进
~/.ssh/config： -
ServerAliveInterval 60：客户端每 60 秒发一次空包 -
ServerAliveCountMax 3：连续 3 次无响应才断开（即容忍最多 3 分钟丢包） - 这两项必须成对出现；只设
ServerAliveInterval而不设ServerAliveCountMax，OpenSSH 会用默认值 0，反而导致秒断 - 服务端
/etc/ssh/sshd_config也得配ClientAliveInterval 60和ClientAliveCountMax 3，否则心跳包会被丢弃
重连后终端快捷键（如 Ctrl+C、Ctrl+L）失效
这不是终端坏了，而是远程 shell 初始化没完成或上下文未刷新。VSCode 重连后可能复用了旧的 shell 进程，但它的 TTY 状态和信号处理链已损坏。
- 先关掉所有终端标签页，再新建一个——不要复用旧 tab
- 新开终端后，执行
exec $SHELL强制重新加载 shell 配置（尤其 zsh 用户常因插件未初始化导致 Ctrl+C 失效） - 如果仍异常，检查远程
~/.bashrc或~/.zshrc是否有阻塞语句（比如卡在curl或git status） - 极端情况可临时绕过配置：
bash --norc --noprofile，验证是否为 shell 初始化问题
真正麻烦的不是掉线本身，而是 VSCode 默认把终端、文件监听、端口转发这些子通道当成“附属品”，不提供独立保活或自动恢复机制。一旦底层 SSH 断开，它们不会像浏览器标签页那样自动重载——你得亲手把整个 vscode-server 进程树和缓存目录一并清空，才能让终端回归可用状态。
