企业官网建设流程全解析

VSCodium 的 reh 与 reh-web 归档：远程服务器与浏览器访问组件完全指南

【免费下载链接】vscodiumbinary releases of VS Code without MS branding/telemetry/licensing项目地址: https://gitcode.com/gh_mirrors/vs/vscodium

导读

VSCodium 在发布桌面客户端的同时，还同步产出了一类容易被忽略、但对远程开发至关重要的归档产物：reh（Remote Host）与reh-web（Web Host）。前者是支撑 Remote-SSH、Remote-WSL 等远程扩展的服务器端组件，后者是codium serve-web命令在本地启动的浏览器访问服务器。本文以 docs/others.md 中的官方解释为主线，结合本仓库的构建脚本与补丁源码，系统讲解这两个组件的定位、区别、构建方式与产物命名规则，帮助读者理解 VSCodium 远程开发体系的全貌，并能正确下载、部署与排查相关归档。

reh（Remote Host）：远程 SSH/WSL 的服务器组件

按照官方文档 docs/others.md 的定义：

Remote Host（reh）是用于远程 ssh/wsl 的服务器组件，它运行在一台"远程"计算机上，并通过 VSCodium 使该远程计算机变得可访问。

也就是说，reh解决的是"客户端与服务器分离"的场景：

• 客户端：本地安装的 VSCodium 桌面应用，负责渲染界面、提供编辑交互；
• 服务器（reh）：部署在远程机器（云服务器、开发机、WSL 子系统等）上的无头（headless）服务，负责承载扩展、语言服务、终端等后端能力；
• 连接通道：客户端通过 SSH（Remote-SSH 扩展）或 WSL 分发（Remote-WSL 扩展）与 reh 通信，本地窗口打开的文件、终端、调试会话实际都执行在远程机器上。

用户在本地 VSCodium 中按下 "Remote-SSH: Connect to Host" 时，客户端会先在远程主机上安装或下载对应的 reh 归档，解压后启动其中的服务进程，再把工作区 UI 投射回本地窗口。这正是 reh 被称为"Remote Host"的原因——它让远程计算机成为开发的主机，而本地只保留一个"遥控器"。

reh-web（Web Host）：codium serve-web的浏览器访问服务器

官方文档对 reh-web 的解释是：

Web Host（reh-web）是命令codium serve-web的服务器组件，它在本机运行，使 VSCodium 可以通过浏览器访问。

与 reh 的"跨机器远程"不同，reh-web面向的是"无客户端"场景：

• 运行位置：默认在本地机器上运行（也可以手动部署到任何主机）；
• 使用方式：执行codium serve-web后，服务会监听一个本地端口，用户用任意浏览器打开该地址即可获得完整的编辑器体验；
• 典型价值：在没有图形界面的服务器、嵌入式设备，或希望"开箱即用"不安装桌面应用的场景中，通过浏览器即可编写代码。

reh-web与 reh 共享绝大部分后端逻辑，差异主要在于前端承载方式：reh 面向的是桌面客户端（通过 VS Code 专有远程协议通信），而 reh-web 直接把基于 Web 的编辑器前端（web UI）打包进服务器，由浏览器直接加载。

reh 与 reh-web 的对比

简言之：reh 让远程机器"可被编辑器访问"，reh-web 让编辑器"可被浏览器访问"，二者是 VSCodium 无桌面 UI 场景下的两块基石。

仓库源码佐证：两种归档的真实构建流程

构建入口：Linux 与 Alpine 平台

VSCodium 仓库为两种归档提供了独立的构建与打包脚本：

• build/linux/package_reh.sh：面向 glibc 系 Linux（x64、arm64、ppc64le、riscv64、loong64、s390x）；
• build/alpine/package_reh.sh：面向 musl 系 Alpine Linux（x64、arm64）。

在 build/linux/package_reh.sh 中可以看到两种产物由开关变量分别控制：

# 构建 reh（Remote Host） if [[ "${SHOULD_BUILD_REH}" != "no" ]]; then echo "Building REH" npm run gulp minify-vscode-reh npm run gulp "vscode-reh-${VSCODE_PLATFORM}-${VSCODE_ARCH}-min-ci" ... tar czf "../assets/${APP_NAME_LC}-reh-${VSCODE_PLATFORM}-${VSCODE_ARCH}-${RELEASE_VERSION}.tar.gz" . fi # 构建 reh-web（Web Host） if [[ "${SHOULD_BUILD_REH_WEB}" != "no" ]]; then echo "Building REH-web" npm run gulp minify-vscode-reh-web npm run gulp "vscode-reh-web-${VSCODE_PLATFORM}-${VSCODE_ARCH}-min-ci" ... tar czf "../assets/${APP_NAME_LC}-reh-web-${VSCODE_PLATFORM}-${VSCODE_ARCH}-${RELEASE_VERSION}.tar.gz" . fi

Alpine 平台的流程与之对称（见 build/alpine/package_reh.sh），仅构建目标名不同（vscode-reh-alpine-x64-min-ci/vscode-reh-alpine-arm64-min-ci），并且会先应用 patches/alpine/reh/00-build-docker.patch——该补丁通过docker run ... node:<version>-alpine从官方 Alpine Node 镜像中提取 node 二进制，以满足 musl 环境的依赖要求。

归档内的验证与校验

两个脚本在打包前都会运行 glibc 兼容性校验脚本verify-glibc-requirements.sh，例如：

EXPECTED_GLIBC_VERSION="${EXPECTED_GLIBC_VERSION}" \ EXPECTED_GLIBCXX_VERSION="${GLIBCXX_VERSION}" \ SEARCH_PATH="../vscode-reh-${VSCODE_PLATFORM}-${VSCODE_ARCH}" \ ./build/azure-pipelines/linux/verify-glibc-requirements.sh

打包完成后还会为每个归档生成 SHA-256 与 SHA-1 校验和文件（*.sha256、*.sha1），这解释了 Release 页面上每个 tar.gz 旁的校验文件来源。用户在下载归档后，可用校验和验证完整性。

远程服务器下载地址的注入

Remote-SSH / Remote-WSL 在远程主机上需要下载 reh 归档，该下载地址在构建期被注入到产品元数据中。补丁 patches/00-remote-add-url.patch 在build/gulpfile.reh.ts与build/gulpfile.vscode.ts中注入了如下模板：

json.serverDownloadUrlTemplate = 'https://github.com/!!ASSETS_REPOSITORY!!/releases/download/!!RELEASE_VERSION!!/!!APP_NAME_LC!!-reh-${os}-${arch}-!!RELEASE_VERSION!!.tar.gz';

即远程扩展下载的正是*-reh-<os>-<arch>-<version>.tar.gz归档，与上文构建产物命名严格对应。可以推断，${os}与${arch}在远程主机上被动态替换为实际平台值，从而精准命中对应架构的 reh 包。

CLI 对 reh-web 的下载依赖

codium serve-web本身由 CLI（Rust 编写的code二进制）驱动，它会按需下载并运行 reh-web 归档。补丁 patches/40-cli-use-reh-archive.patch 在cli/src/update_service.rs中给出了下载 URL 的完整拼装逻辑：

let download_url = format!( "{}/download/{}/{}-reh-web-{}-{}-{}.tar.gz", download_endpoint, release.name, app_name, release.platform.os(), release.platform.arch(), release.name, );

对应关系一目了然：codium serve-web下载的正是*-reh-web-<os>-<arch>-<version>.tar.gz，与官方文档中 "Web Host 是codium serve-web的服务器组件" 的定义完全吻合。同时该补丁还允许通过环境变量（VSCODE_CLI_APP_NAME、VSCODE_CLI_DOWNLOAD_ENDPOINT、VSCODE_CLI_UPDATE_ENDPOINT等）定制下载源，实际取值见 build_cli.sh：

export VSCODE_CLI_APP_NAME="$( echo "${APP_NAME}" | awk '{print tolower($0)}' )" export VSCODE_CLI_BINARY_NAME="$( node -p "require(\"../product.json\").serverApplicationName" )" export VSCODE_CLI_UPDATE_ENDPOINT="https://raw.githubusercontent.com/VSCodium/versions/refs/heads/master"

由此可见，reh 与 reh-web 并非孤立的"额外文件"，而是被深度集成进 CLI 下载链路（reh-web）与远程扩展下载链路（reh）的正式分发物。

如何获取与使用这些归档

获取方式

两种归档都随每次 VSCodium Release 一并发布，命名遵循统一模板：

• vscodium-reh-<os>-<arch>-<version>.tar.gz
• vscodium-reh-web-<os>-<arch>-<version>.tar.gz

其中<os>与<arch>的组合覆盖 x64、arm64、armhf 以及仓库支持的 ppc64le、riscv64、loong64、s390x 等架构（Linux 平台参见 build/linux/package_reh.sh 中各架构的构建分支，Alpine 平台参见 build/alpine/package_reh.sh）。每个归档都配套.sha256与.sha1校验文件，可用于下载后的完整性校验。

使用方式

• reh：无需手工部署。在本地 VSCodium 中通过 Remote-SSH / Remote-WSL 连接远程主机时，客户端会自动下载、解压并启动对应平台的 reh 归档。若需手动部署，可将归档上传到远程机器解压，按官方远程扩展的指引配置启动参数。
• reh-web：在已安装 VSCodium CLI 的机器上直接运行：

codium serve-web

服务启动后，用浏览器访问命令输出的本地地址即可获得完整的 VSCodium 编辑器界面。其底层下载、解压与启动 reh-web 归档的流程由 CLI 自动完成（见上文 patches/40-cli-use-reh-archive.patch 中的下载逻辑）。

平台与依赖注意事项

• Linux reh/reh-web 归档针对特定 glibc 版本构建（构建脚本中声明了GLIBC_VERSION与GLIBCXX_VERSION，并强制通过verify-glibc-requirements.sh校验），因此旧版 glibc 的发行版可能无法直接运行，这是部署到老旧服务器时最常见的坑；
• Alpine（musl）用户应选用alpine平台标记的归档，而非通用linux标记，因为两者依赖的 libc 不同；
• riscv64 等新架构需要额外的 Node.js 构建源（见 build/linux/package_reh.sh 中对riscv-forks/node-riscv仓库的引用），并非所有架构都有现成官方 Node 预编译产物。

总结

一句话概括二者的分工：reh 把远程机器变成可开发的"主机"，reh-web 把编辑器变成可浏览器访问的"网页"。在本仓库中，这两类归档由 build/linux/package_reh.sh 与 build/alpine/package_reh.sh 构建，通过 patches/00-remote-add-url.patch 接入远程扩展的下载链路，通过 patches/40-cli-use-reh-archive.patch 接入codium serve-web的下载链路。理解了这两条链路，也就理解了 VSCodium 在没有桌面客户端参与时，如何依然提供完整的远程与浏览器开发能力。

【免费下载链接】vscodiumbinary releases of VS Code without MS branding/telemetry/licensing项目地址: https://gitcode.com/gh_mirrors/vs/vscodium