VSCode Remote-SSH显示“Reconnecting”的典型触发条件是网络抖动、防火墙回收空闲TCP连接（如5分钟超时）、远程sshd的ClientAliveInterval未配置或为0、本地Wi-Fi切换导致DNS重解析失败，以及GitLens等插件与Remote Development存在IPC冲突。
VSCode Remote-SSH 显示 Reconnecting 的典型触发条件
这不是连接完全断开，而是 VSCode 客户端与远程服务器之间的 WebSocket 信道反复重连——通常意味着底层 SSH 连接未彻底中断，但心跳或隧道维持失败。常见于网络抖动、防火墙主动回收空闲连接、或远程 sshd 配置过于激进。
- 本地 Wi-Fi 切换（如从公司切到手机热点）会触发 DNS 重解析失败，
Remote-SSH不自动重试新 IP - 企业级防火墙/网关默认 5 分钟清理无数据流的 TCP 连接，而默认
sshd的ClientAliveInterval是 0（不发保活） -
Remote Development插件与GitLens、Auto Close Tag等高频监听文件系统变更的插件存在 IPC 冲突，尤其在 WSL2 或 NFS 挂载目录中
快速验证是网络层还是插件层问题
别急着改配置，先用两个终端命令交叉验证：
- 在本地终端运行
ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=3 user@host，观察是否稳定维持 10 分钟以上；如果也频繁断开，说明是网络或服务端问题 - 在 VSCode 中禁用所有非
Remote Development插件（特别是带「Git」「File Watcher」「Sync」字样的），再重连；若恢复正常，逐个启用定位冲突源 - 打开 VSCode 输出面板 → 选择
Remote-SSH，搜索关键词Failed to connect或tunneling socket，比弹窗提示更准
ServerAliveInterval 和 ClientAliveInterval 到底该配哪边
必须两边都配，且逻辑不同：客户端（VSCode 所用的 OpenSSH）靠 ServerAliveInterval 主动发探测包；服务端（sshd_config）靠 ClientAliveInterval 被动检测客户端是否存活。只配一边等于白搭。
- 本地
~/.ssh/config加入：Host myserver HostName 192.168.1.100 User dev ServerAliveInterval 30 ServerAliveCountMax 2 - 远程服务器编辑
/etc/ssh/sshd_config，确保有：ClientAliveInterval 45 ClientAliveCountMax 3
（改完需sudo systemctl restart sshd） - 注意：VSCode Remote-SSH 默认忽略
~/.ssh/config的某些选项，务必确认你用的是「Connect to Host...」而非「Connect Current Window to Host...」，后者可能绕过 config
Reconnecting 时 VSCode 自动重连失败的隐藏原因
VSCode 并非每次断开都尝试重连——它依赖一个叫 remote.SSH.enableDynamicForwarding 的开关和后台隧道进程状态。一旦该进程僵死（常见于 Ctrl+C 中断或崩溃后残留），后续所有重连请求都会卡在「Reconnecting」动画里不动。
- 手动杀掉残留进程：
pkill -f "vscode-server.*--port="（Linux/macOS）或任务管理器结束node进程（Windows） - 在 VSCode 设置中关闭
remote.SSH.useLocalServer（设为false），强制每次连接都走全新隧道，避免复用旧态 - 如果用的是跳板机（ProxyJump），确保中间节点也配置了保活，否则第二跳隧道会在第一跳静默断开后无法恢复
真正麻烦的不是配置本身，而是 VSCode 把底层 SSH 连接状态和前端 UI 状态做了两套独立管理——你看到「Reconnecting」时，后台可能已经连上三次又断了两次，而 UI 只显示最后一次结果。
