code-server 部署需求与云服务器选型指南：最低硬件规格、WebSocket 前提与 GCP VM 搭建实践

本篇基于 docs/requirements.md 展开，系统讲解 code-server（浏览器版 VS Code）运行环境的最小硬件要求、WebSocket 通信这一硬性前提的底层原理，以及在 Google Cloud 上从零搭建 Debian VM 的完整步骤。读完后你可以评估现有机器是否满足运行条件、理解为什么代理必须放行 WebSocket，并独立在一台云端 Debian VM 上部署 code-server。

最低硬件规格

code-server 需要一台可以运行 Node.js 服务端的机器，既可以是你的物理机，也可以是 GCP/AWS 等云厂商的虚拟机。需求文档 给出的推荐最低配置为：

• 1 GB 内存（RAM）
• 2 个 CPU 核心

操作系统方面，任意 Linux 发行版都可以；官方文档的其余章节（如 使用指南、安装文档）默认假设你在 Google Cloud 上托管的 Debian 环境中操作，因此选择 Debian 可以让文档中的命令与示例直接可用。

说明：文档中提到的“新注册用户可获得 3 个月试用与 300 美元额度”属于 GCP 的注册政策，随时间可能变化，实际操作前请以 GCP 控制台显示为准。

从 安装脚本 可以看出，code-server 对主流发行版都有适配：Debian/Ubuntu/Raspbian 走 deb 包，Fedora/CentOS/RHEL/openSUSE 走 rpm 包，Arch 走 AUR，其余情况回退到 GitHub 发布版或 npm；这也印证了“任意 Linux 发行版均可”的说法，但发行版差异会体现在安装方式上而非运行需求上。

WebSocket 是硬性前提，而非可选项

需求文档 明确指出：你的环境必须启用 WebSockets，因为 code-server 依赖 WebSocket 完成浏览器与服务端之间的通信——编辑器界面加载后，终端 I/O、文件同步、扩展宿主通信等都走这条全双工通道。

这条要求在源码中有清晰体现。src/node/wsRouter.ts 中的 handleUpgrade 监听 HTTP 服务的 upgrade 事件，将升级请求交给 Express 处理；src/node/app.ts 的 createApp 中，每个 HTTP 服务都会额外挂一个独立的 WebSocket 路由（wsRouter），全局 wss 实例（src/node/wsRouter.ts）以 noServer: true 方式附着到同一个 HTTP 端口上。

这带来两个实操结论：

1. 端口层面：反向代理（Nginx、Caddy、云 LB 等）必须转发 Upgrade: websocket 请求，只放行普通 HTTP GET 会导致页面能打开但编辑器不可用。
2. 无需独立端口：从源码结构看，WebSocket 与 HTTP 共用同一监听端口，因此防火墙/安全组只需放行 code-server 的监听端口即可，不必单独配置 WS 端口。

在 Google Cloud 上搭建 Debian VM（完整步骤）

以下为 需求文档 中给出的 GCP Compute Engine 部署流程。文档同时说明：这些步骤只是示例，任何机器或云厂商都可以替代，但按此操作可保证与后续文档环境一致。

创建一个新的 GCP 项目后，按如下步骤创建 Compute Engine VM 实例：

1. 通过侧边栏进入 Compute Engine > VM Instances。
2. 点击 Create Instance。
3. 为新实例填写 name（名称）。
4. 选择离你最近的 region（可按 ping 延迟挑选，原文档推荐用 gcping 站点辅助选择）。
5. 选择一个 zone（任意均可）。
6. 从通用型（general-purpose family）中推荐选择 E2 series 机型。
7. 将机型改为 custom，至少配置 2 核 + 2 GB 内存；之后也可以随时调整资源。
8. （可选但强烈推荐）将持久磁盘切换为 SSD Persistent Disk 且容量至少 32 GB：点击 Boot Disk 下的 change，把类型改为 SSD、容量设为 32。磁盘日后也可以扩容。
9. 进入 Networking > Networking Interfaces，将现有接口编辑为使用静态内网 IP，点击 Done 保存。
10. 如果还没有项目级 SSH 密钥，进入 Security > SSH Keys 添加你的公钥。
11. 点击 Create 完成创建。

注意第 7 步的 2 GB 内存高于“最低 1 GB”的要求：这是文档为云端实例给出的更稳妥的推荐值，最低规格仅用于评估已有机器能否跑起来。

部署注意事项（来自原文档的 Notes）

• 控制成本：不用时关机（shut down）即可停止大部分计费。
• 优先使用 gcloud cli：文档建议尽量用 gcloud 命令行替代 GCP Dashboard，便于脚本化与复现。
• HTTPS 方案：若要通过 HTTPS 提供 code-server，推荐搭配一个外部域名 + Let's Encrypt 签发证书。这一点在 code-server 端有原生支撑——src/node/cli.ts 定义了 --cert、--cert-key、--cert-host 参数，且“未提供证书时会自动生成自签名证书”；src/node/app.ts 中，当 args.cert 存在时会用 httpolyglot 直接创建 TLS 服务，因此 Let's Encrypt 签发的证书可以不经反向代理直接交给 code-server 使用。

VM 就绪后的安装与监听地址

VM 创建完成后，可按 README 与 安装文档 使用安装脚本：

# 预览安装过程（不实际执行）
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run

# 正式安装
curl -fsSL https://code-server.dev/install.sh | sh

安装完成后，服务默认监听地址在 src/node/cli.ts 的 bindAddrFromAllSources 中定义：

默认：localhost:8080

与“网络环境”相关的几个要点，均来自 src/node/cli.ts 的参数解析逻辑：

配置方式	说明
--bind-addr host:port	指定监听地址；支持 $PORT 占位符覆盖端口
--bind-addr host（不带端口）	从源码注释看，会默认落到 80 端口而非 code-server 默认的 8080，这是 URL 解析规则决定的，远程部署时建议显式写端口
环境变量 PORT / CODE_SERVER_HOST	分别覆盖端口 / 主机名，便于容器化部署
--host / --port	已被 bind-addr 取代的旧参数（源码中标记为 deprecated）
--socket / --socket-mode	改用 Unix socket 监听，此时 bind-addr 被忽略（见 src/node/app.ts 的 listen 实现）

对于“从浏览器远程访问”这一典型场景，推荐显式使用 --bind-addr 0.0.0.0:8080 并配合 使用指南 中的鉴权与反代配置；仅监听 localhost（默认值）时，只能在本机或 SSH 隧道内访问。

需求核对清单

部署前可用以下清单对照 需求文档 逐条验证：

• 机器内存 ≥ 1 GB，CPU ≥ 2 核（云端推荐 2 GB 起）；
• 操作系统为 Linux（Debian 与文档环境完全一致）；
• 浏览器到服务的网络链路支持 WebSocket 升级（反向代理已配置 Upgrade/Connection 头透传）；
• 防火墙/安全组放行了 code-server 监听端口（HTTP 与 WS 共用该端口）；
• 需要公网访问时已准备域名与证书（Let's Encrypt），并可通过 --cert / --cert-key 交给 code-server；
• 有 SSH 访问权限（GCP 项目级密钥或实例密钥），便于后续安装与排障。

小结

code-server 的运行门槛并不高——1 GB 内存 + 2 核 CPU 的 Linux 机器即可启动，真正的“硬需求”只有两条：足够跑起 VS Code 服务端的资源，以及一条放行了 WebSocket 的网络链路。需求文档 给出的 GCP VM 流程（E2 自定义机型、2 核 2 GB、32 GB SSD、静态内网 IP、SSH 密钥）是一套可直接复制的云端基线，再结合安装脚本的 --dry-run 预览与 --bind-addr 的显式监听配置，就能在任意 Linux 环境上稳定跑起浏览器版 VS Code。更多使用细节可继续参考 使用指南 与 FAQ。