根本原因是ssh连接层未维持活跃状态导致中间网络设备回收空闲连接，需在~/.ssh/config中为对应host配置serveraliveinterval 60、serveralivecountmax 3和tcpkeepalive yes。
为什么 VSCode Remote-SSH 会频繁断开或卡在“Opening remote…”
根本原因通常是 SSH 连接层未维持活跃状态，导致中间网络设备（如路由器、防火墙、跳板机）主动回收空闲连接。VSCode 本身不处理保活逻辑，完全依赖底层 SSH 配置。现象包括：Failed to connect to the remote extension host、终端光标冻结、Opening remote... 卡住超 1 分钟、偶尔自动重连但工作区未恢复。
必须修改的 SSH 客户端配置（~/.ssh/config）
仅靠 VSCode 设置或 remote.SSH.configFile 指定路径不够——VSCode Remote-SSH 插件调用的是系统 ssh 命令，它只读取 ~/.ssh/config 中匹配的 Host 段落。关键参数必须显式写入：
Host my-remote-server
HostName 192.168.1.100
User ubuntu
ServerAliveInterval 60
ServerAliveCountMax 3
ConnectTimeout 10
TCPKeepAlive yes
-
ServerAliveInterval 60：每 60 秒发一次空包探测服务端是否存活（不是心跳，是 TCP 层探测） -
ServerAliveCountMax 3：连续 3 次探测失败才断开，避免偶发丢包误判 -
TCPKeepAlive yes：启用底层 TCP keepalive（部分老旧服务器要求此选项配合） - 不要用
ControlMaster或ControlPersist：VSCode Remote-SSH 内部已实现连接复用，开启反而引发竞态和权限问题
VSCode 插件与服务端环境的隐性冲突点
即使 SSH 配置正确，仍可能卡在“Installing VS Code Server”或终端无响应，常见于以下情况：
- 远程服务器磁盘满或
/tmp不可写：VSCode Server 安装失败但错误被静默吞掉，表现为无限等待；检查df -h和ls -ld /tmp - 远程 shell 启动脚本（如
~/.bashrc）中含阻塞操作：比如卡在git status、等待用户输入、执行耗时命令；VSCode 启动时会加载完整 shell 环境，建议将非交互逻辑移出或加[ -z "$PS1" ] && return守卫 - 远程
sshd配置限制：检查服务端/etc/ssh/sshd_config是否设了ClientAliveInterval但值过大（如 3600），应设为 ≤60 并重启sshd - Windows 客户端 WSL2 下使用 Remote-SSH：WSL2 的虚拟网卡有时触发 NAT 超时，需在 WSL2 中运行
echo "net.ipv4.tcp_keepalive_time = 60" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
调试断连时该看哪几处日志
别只盯着 VSCode 弹窗。真实线索藏在三层日志里：
- VSCode 输出面板 → 选择 “Remote-SSH”：搜
stderr或exit code，常有Connection reset by peer或Broken pipe - 本地终端手动运行：
ssh -v -F ~/.ssh/config my-remote-server，观察最后几行是否出现debug1: send SSH2_MSG_KEX_ECDH_INIT类重协商日志，或直接断在debug1: Connection died - 远程服务器上查：
sudo journalctl -u sshd --since "5 minutes ago" | grep -i "timeout\|disconnect"，确认是客户端超时还是服务端强制踢出
真正稳定的 Remote-SSH 连接，不靠插件刷新或重装，而取决于 SSH 层能否让每个 TCP 连接在穿越所有中间节点时不被静默切断。保活参数必须落在 ~/.ssh/config 对应 Host 段，且服务端 sshd 配置不能比客户端更激进地回收连接——这点最容易被忽略。
