VSCode实时协作连不上，八成是网络出口或认证上下文未对齐：Remote-SSH下协作插件运行于远端，请求走服务器网络出口；需检查DNS、HTTPS连通性、防火墙拦截及known_hosts密钥污染。
VSCode实时协作连不上，八成不是插件问题，而是网络出口或认证上下文没对齐——尤其当你用Remote-SSH连进服务器后再开协作功能时。
Remote-SSH环境下协作插件根本没发请求
很多用户反馈“装了Live Share或CodeTogether，本地能用，一连远程就灰屏”。这不是插件失效，而是协作服务（如vscode-liveshare）默认作为Workspace扩展运行在远端vscode-server进程里。它发起的WebSocket连接走的是服务器的网络出口，不是你本地的。常见表现包括：
- 状态栏显示“Connecting…”但一直不变成“Sharing”
- 输出面板里
Live Share日志卡在Starting collaboration service... - 手动
curl -v wss://prod.liveshare.vsengsaas.visualstudio.com从服务器上直接失败
实操建议：
- 先在服务器终端执行
curl -I https://prod.liveshare.vsengsaas.visualstudio.com，确认DNS解析和HTTPS连通性 - 若超时或
Connection refused，检查服务器是否禁用了出站wss（443端口），或被公司防火墙拦截 - 临时绕过：在服务器上配
export HTTPS_PROXY=http://127.0.0.1:8080（需提前运行本地代理并转发到服务器）
Known hosts污染导致SSH通道反复中断
协作依赖稳定SSH隧道。一旦known_hosts里存了旧主机密钥，VSCode Remote-SSH会在后台频繁重连、断开，协作插件的长连接就被连带杀掉。典型现象是协作刚起来几秒就断，控制台刷出write EPIPE或socket hang up。
实操建议：
- 定位问题行：
ssh-keygen -F "your-host.example.com" -f ~/.ssh/known_hosts - 删掉对应行：
ssh-keygen -R "your-host.example.com"（注意带引号，支持域名/IP） - 不要手动编辑
known_hosts——格式错一位就会让整个文件失效 - 如果用跳板机，要分别清理跳板机和目标机两处记录
协作服务端口被本地防火墙静默拦截
Live Share等工具会在本地监听随机高危端口（如39257、40123），用于P2P直连或中继通信。Windows Defender或第三方安全软件常将其识别为“可疑外连”，不报错、不弹窗，只默默丢包。
实操建议：
- 打开Windows安全中心 → 防火墙和网络保护 → 允许应用通过防火墙 → 找到
Code.exe，确保勾选“专用”和“公用”网络 - 命令行快速验证：
netsh advfirewall firewall show rule name="Visual Studio Code" - 若仍不行，临时关闭防火墙测试（仅限可信内网）：
netsh advfirewall set allprofiles state off
真正卡住人的地方往往不在“怎么开协作”，而在“谁在替你做网络决策”——是服务器上的iptables？是跳板机的ProxyCommand配置？还是你笔记本上那个从不提醒的国产安全软件？每次连不上，先问一句：这个请求，最后是哪台机器在发、往哪发、被谁拦了。
