VSCode远程开发卡在log.txt和pid.txt？离线环境下的三种修复方案

当你身处内网环境，试图通过VSCode的Remote-SSH功能连接远程服务器时，最令人抓狂的莫过于卡在 log.txt 和 pid.txt 检查环节。这种看似简单的文件检查背后，实则是VSCode远程开发机制对网络连接的隐性依赖。本文将深入剖析这一问题的根源，并提供三种经过验证的离线修复方案，助你在无外网访问权限的服务器上重获开发效率。

1. 问题诊断与离线环境挑战

VSCode远程开发的核心在于其 vscode-server 组件。当首次连接远程服务器时，VSCode会自动尝试下载并安装这个服务端程序。整个过程通常包括：

1. 通过SSH建立基础连接
2. 检查服务器端 ~/.vscode-server 目录结构
3. 下载匹配本地客户端版本的 vscode-server 二进制包
4. 解压安装并启动后台服务

在离线环境中，问题往往出现在第三步。由于无法访问 update.code.visualstudio.com 下载服务器，VSCode会陷入无限重试状态，最终表现为持续检查 log.txt 和 pid.txt 这两个本应在安装成功后自动生成的文件。

典型错误日志特征 ：

[timestamp] [server] Checking /home/user/.vscode-server/cli/servers/Stable-{commit_id}/log.txt
[timestamp] [server] Checking /home/user/.vscode-server/cli/servers/Stable-{commit_id}/pid.txt
[timestamp] [server] Installing and setting up Visual Studio Code Server...

2. 方案一：禁用ExecServer模式（配置降级）

这是最快捷的解决方案，特别适合临时需要连接多台离线服务器的情况。该方法通过回退到旧版文件处理逻辑来规避网络依赖。

操作步骤：

1. 在任意可用的VSCode实例中打开设置（ Ctrl+, ）
2. 搜索 remote.SSH.useExecServer
3. 取消勾选该选项或设置为 false
4. 保存设置后重新连接目标服务器

原理说明 ：

• 新版VSCode默认启用 useExecServer 模式，采用新的服务管理架构
• 旧模式使用更简单的文件结构，便于手动干预
• 修改后需完全关闭并重新打开远程窗口才能生效

注意：此修改会影响所有后续的SSH连接，建议在解决问题后恢复默认设置以获得更好的性能体验。

3. 方案二：手动部署vscode-server组件

对于需要长期稳定工作的环境，手动部署是最可靠的解决方案。这需要你事先在有网络的环境中准备好必要文件。

3.1 文件准备阶段

首先在有网络的机器上获取以下资源：

1. 获取commit ID ：

   • 查看本地VSCode帮助→关于中的提交哈希值
   • 或通过命令面板运行 Developer: Inspect Context Keys

2. 下载核心组件 ：

   • 服务器包： https://update.code.visualstudio.com/commit:{commit_ID}/server-linux-x64/stable
   • CLI工具： https://update.code.visualstudio.com/commit:{commit_ID}/cli-alpine-x64/stable

3.2 服务器端部署

将下载的文件通过U盘或其他离线方式传输到目标服务器，然后执行：

# 创建目录结构
mkdir -p ~/.vscode-server/cli/servers/Stable-{commit_ID}/server

# 解压服务器包
tar -xzf vscode-server-linux-x64.tar.gz -C ~/.vscode-server/cli/servers/Stable-{commit_ID}/server

# 处理CLI工具
unzip vscode-cli-alpine-x64.zip
mv code ~/.vscode-server/cli/code-{commit_ID}
chmod +x ~/.vscode-server/cli/code-{commit_ID}

目录结构验证 ：

.vscode-server/
├── cli
│   ├── code-{commit_ID}    # CLI可执行文件
│   └── servers
│       └── Stable-{commit_ID}
│           └── server      # 解压后的服务器文件
└── bin
    └── {commit_ID}         # 自动生成的符号链接

4. 方案三：版本锁定策略

对于企业级环境，建立版本控制体系能有效避免此类问题。这包括：

4.1 客户端版本控制

1. 禁用VSCode自动更新：

   // settings.json
   {
       "update.mode": "none"
   }
   

2. 统一团队使用的VSCode版本
3. 维护内部插件仓库

4.2 服务端版本匹配

建立版本对应关系表：

VSCode版本	推荐vscode-server版本	备注
1.85.x	stable-{commit_id}	需配套CLI工具
1.82.x	legacy-{commit_id}	兼容旧协议
1.79.x	extended-{commit_id}	支持特殊架构

4.3 降级操作指南

如需回退版本：

1. 卸载当前Remote-SSH插件
2. 安装特定版本插件：

   code --install-extension ms-vscode-remote.remote-ssh@0.106.0
   

3. 清理服务器端残留：

   rm -rf ~/.vscode-server
   

5. 高级排查与优化建议

当基础方案无效时，可能需要深入系统层面排查：

5.1 文件权限检查

确保VSCode进程有足够权限：

# 检查目录所有权
ls -la ~/.vscode-server

# 递归设置权限
chown -R $(whoami):$(whoami) ~/.vscode-server
chmod 755 -R ~/.vscode-server

5.2 环境变量覆盖

通过SSH配置注入必要变量：

Host offline-server
    HostName 192.168.1.100
    User dev
    RequestTTY yes
    RemoteCommand VSCODE_AGENT_FOLDER=/mnt/alt-vscode-server $(which zsh)

5.3 备选传输方案

当SCP协议失效时，可尝试：

1. 使用rsync替代：

   rsync -azP /local/path user@host:~/.vscode-server
   

2. 通过SFTP手动上传
3. 挂载网络共享目录

在实际项目中，我通常会为团队维护一个包含常见版本vscode-server的离线资源包，当有新成员加入或更换开发机时，只需从内网共享目录获取对应版本即可快速完成环境配置。这种集中式管理不仅解决了网络依赖问题，还确保了开发环境的一致性。