Live Share 协作断连主因是令牌过期、代理冲突或后台进程被杀；需手动登出/登录刷新 token，禁用代理或设 "liveshare.proxy": "direct"，并确保 liveshare-authentication 进程不被系统终止。
VSCode Live Share 协作会话频繁断开，基本不是网络抖动导致的，而是服务端连接保活机制没对齐、客户端代理配置冲突、或协作会话被后台进程意外终止。直接重连往往无效，必须从 Live Share 插件底层依赖的 WebSocket 连接和身份令牌生命周期入手。
Live Share 连接超时的典型错误日志
打开 VSCode 的 Output 面板，选择 Live Share 日志，你会看到类似：
[2026-10-25 14:22:17.891] [error] Failed to connect to collaboration service: Error: WebSocket closed with code 4401 [2026-10-25 14:22:17.892] [error] Connection failed: Unauthorized (4401)
这个 4401 不是认证失败，而是 Live Share 后端判定你的访问令牌（access token）已过期或被撤销——它默认有效期仅 24 小时，且不自动刷新。
- 手动触发重连不会重新获取 token，只会复用旧的失效凭证
- 如果你在公司内网 + 代理环境下使用，
http.proxy配置可能拦截了 Live Share 的 WebSocket 升级请求（Upgrade: websocket） - Windows 上杀毒软件/防火墙有时会静默终止
liveshare-authentication进程，导致后续所有会话无法续签
强制刷新 Live Share 访问令牌
令牌过期是最隐蔽也最常被忽略的原因。VSCode UI 不提示“token expired”，只报错断连，用户误以为是网络问题。
- 退出当前所有 Live Share 会话（包括“正在加入”的协作者）
- 按
Ctrl+Shift+P打开命令面板，输入并执行：Live Share: Sign Out - 再执行：
Live Share: Sign In—— 这步必须手动触发，不能靠“Start Collaboration Session”自动带出登录流程 - 登录成功后，再启动新会话，此时拿到的是全新 24 小时有效期的 token
注意：remote.SSH 和 Live Share 使用完全独立的身份系统，SSH 登录状态不影响 Live Share token。
绕过代理限制 WebSocket 连接
很多企业网络强制走 HTTP 代理，但 Live Share 的通信走的是 wss://（WebSocket Secure），部分老旧代理不支持 CONNECT 到非 443 端口，或拒绝升级请求。
- 检查你是否设置了全局
http.proxy：打开settings.json，搜索"http.proxy" - 若存在，临时注释掉该行，或改为仅对特定域名生效：
"http.proxyStrictSSL": false必须同时设为true才能绕过证书校验干扰 - 更稳妥的做法是，在
settings.json中显式禁用 Live Share 的代理："liveshare.proxy": "direct" - 重启 VSCode，再试一次 —— 大多数“秒断”问题在此解决
避免后台进程被系统回收
Live Share 在本地依赖一个长期运行的 liveshare-authentication 进程（Windows 下是 liveshare-authentication.exe），它负责维护 token 续期和密钥交换。Windows 电源管理、第三方优化工具、甚至 Windows Defender 的“性能建议”都可能把它当成闲置进程干掉。
- 任务管理器中观察该进程是否存在；若协作中突然断开且无日志，大概率是它挂了
- 关闭 Windows 的“内存压缩”和“快速启动”（设置 → 系统 → 电源和睡眠 → 其他电源设置 → 选择电源按钮的功能 → 更改当前不可用的设置）
- 在 VSCode 设置中启用：
"liveshare.enableAutoReconnect": true（默认为false） - 如仍不稳定，可考虑将 VSCode 加入 Windows Defender 排除项，路径通常是：
C:\Users\{user}\AppData\Local\Programs\Microsoft VS Code\
真正麻烦的不是第一次连不上，而是连上后 10–15 分钟莫名中断——那几乎可以确定是 token 续期失败或后台进程被杀，而不是网络本身的问题。
