重连失败时需手动清理远程vscode-server：先SSH登录执行ps aux|grep vscode-server杀残留进程，再rm -rf ~/.vscode-server；若无法联网下载server，须在~/.ssh/environment中配置http_proxy。
VS Code 断连后左下角显示 “Disconnected from SSH” 怎么办
直接点：别关窗口，先点左下角那个灰色状态栏（通常写着 SSH: your-host），选 Reconnect to Host —— 大部分时候它真能续上，未保存的文件、终端、调试会话都还在。
但这个“重连”不是万能的。它只负责重建 VS Code 和远程 vscode-server 的通信链路；如果远程进程本身已被系统 kill（比如 SSH 断开时没做守护），那重连只会卡在“正在安装 server”或报 Connection refused。
- 现象：点击重连后弹出提示“Installing VS Code Server”，然后不动了 → 说明远程端
vscode-server进程没了，且自动部署失败 - 原因常见于：服务器网络受限（无外网/需代理）、磁盘满、
glibc版本太低、或上次异常退出留下损坏缓存 - 此时必须手动干预远程端，不能只靠本地点几下
远程端 vscode-server 没起来，怎么手动救活
本质是 VS Code Remote-SSH 在远程主机上跑了一个轻量服务（vscode-server），断连后它常被一并终止。重连失败时，优先确认并清理这个服务环境。
- 用其他终端（如 Terminal、Xshell）SSH 登上去，执行：
ps aux | grep vscode-server，看有没有残留进程；有就kill -9掉 - 删干净旧缓存：
rm -rf ~/.vscode-server（注意不是~/.vscode）；这步能绕过大多数版本冲突和权限错乱 - 如果服务器无法直连微软 CDN（比如内网/需代理），得提前设好环境变量：
export http_proxy="http://proxy:port"，再运行 VS Code 连接，否则下载vscode-server会静默卡死 - 代理要写进
~/.ssh/environment才对 SSH 启动的进程生效（仅export到当前 shell 不管用）
怎么让 SSH 连接不轻易断，从根上减少重连需求
VS Code 断连，八成是底层 SSH 先挂了。不是 VS Code 不行，是 SSH 默认太“娇气”——空闲 5 分钟就断，中间丢两个包就判死刑。
- 改本地
~/.ssh/config，加这两行（作用范围是所有 Host，也可只针对某台）：ServerAliveInterval 20ServerAliveCountMax 3 -
ServerAliveInterval 20表示每 20 秒发个空包探活；ServerAliveCountMax 3是允许最多丢 3 次包才断，比默认值（0）靠谱得多 - 别设
ServerAliveCountMax 999—— 看似保险，实则会让 VS Code 在网络恢复前一直傻等，UI 卡死，反而更难操作 - Windows 用户若用 Git 自带 SSH，记得改的是
C:\Program Files\Git\etc\ssh\ssh_config，不是用户目录下的~/.ssh/config
后台任务（比如训练、编译）怎么不因断连中断
VS Code 断了，你跑着的 python train.py 或 make build 很可能跟着一起凉——因为默认它们绑在 SSH session 生命周期里。
- 正确做法：进服务器后先开
tmux或screen，再跑任务。例如：tmux new -s train→python train.py→Ctrl+B, D脱离 - 断连重连后，在 VS Code 集成终端里输
tmux attach -t train，立马回到原来界面，日志、进度全在 - 别用
nohup python xxx.py &敷衍：它不支持交互、看不到实时输出、出错难排查，只适合真正“扔完就不管”的脚本 -
tmux和screen本身也依赖 SSH 连接存活，但只要 SSH 层不断（靠上面的保活配置撑住），它们就能稳住你的任务
最易被忽略的一点：VS Code 的重连行为高度依赖远程 vscode-server 的状态，而这个状态又受制于服务器网络、磁盘、glibc、甚至 ~/.ssh/environment 里有没有代理——它不像浏览器刷新那么简单，得把远程端当一个独立服务来维护。
