1. 项目概述：在 Ubuntu 18.04 上快速部署 code-server —— 一个真正开箱即用的云 IDE 解决方案
你有没有过这样的经历：临时需要调试一段 Python 脚本，但手边只有公司配的 Windows 笔记本，装 Anaconda 太重、WSL2 配置又卡在驱动更新上；或者带学生做嵌入式开发，每人配一台树莓派成本太高，而远程桌面又卡得连代码补全都等不起？我去年在给本地职校做实训平台升级时就撞上了这个坎——他们机房还是老旧的 i3 + 4GB 内存台式机，跑 VS Code 桌面版直接卡成幻灯片。后来我们把整套开发环境搬到了服务器上，用 code-server 做入口，学生用 Chrome 打开https://ide.school.edu就能写 C 语言、编译、调试、甚至跑 Qt Designer，整个过程不依赖本地算力，也不用装任何客户端。这就是 cloud-IDE 的真实价值：它不是把 IDE 搬上网页那么简单，而是把“开发环境”本身变成一种可伸缩、可隔离、可审计的服务资源。
标题里那个德语短语 “So richten Sie die Code-Server-Cloud-IDE-Plattform unter Ubuntu 18.04 ein [Schnellstart]” 直译是“如何在 Ubuntu 18.04 上配置 code-server 云 IDE 平台 [快速入门]”，但它背后藏着三个关键信号：第一，目标系统明确锁定为Ubuntu 18.04，这是一个已进入 ESM（扩展安全维护）阶段的老版本，意味着不能无脑套用新版教程里的apt update && apt upgrade；第二，核心工具是code-server，它不是 VS Code 的网页版，而是 VS Code Server 的官方封装，完全兼容所有插件和调试器，连 Remote-SSH 都能直连；第三，“Schnellstart”（快速启动）不是营销话术，而是对部署效率的硬性要求——我们必须绕过 Docker 编排、跳过 Kubernetes 复杂度，在裸金属或最小化 VPS 上 15 分钟内完成从系统初始化到浏览器可访问的全流程。
为什么非得是 Ubuntu 18.04？因为大量教育机构、政企私有云、边缘计算节点仍在使用这个 LTS 版本。它自带的 systemd 237、OpenSSL 1.1.1、Python 3.6.9 构成了一个稳定但略显陈旧的底座，很多新教程默认安装的 Node.js 18+ 或 Nginx 1.22 会与之冲突。而热搜词里反复出现的Nginx和Let’s Encrypt，恰恰暴露了实际落地中最痛的两个环节：一是 code-server 默认只监听 localhost:8080，必须通过反向代理才能对外提供 HTTPS 访问；二是证书自动续期一旦失败，第二天学生打开页面就会看到醒目的“您的连接不是私密连接”警告，教学中断无法容忍。所以这篇内容不讲原理，不堆概念，只聚焦一件事：给你一套在 Ubuntu 18.04 上实测通过、可直接粘贴执行、连防火墙规则都帮你写好的完整操作链。无论你是运维老手想快速交付，还是教师想自己搭个班级实训平台，或是开发者想在旧服务器上复用闲置资源，这套方案都能让你在喝完一杯咖啡的时间内，把 VS Code 变成一个 URL。
2. 整体架构设计与技术选型逻辑：为什么放弃 Docker，坚持原生部署？
2.1 核心思路：轻量、可控、可审计的三层架构
code-server 的部署方式其实有三条路：Docker 容器化、systemd 系统服务、或直接前台运行。我们最终选择systemd + Nginx 反向代理 + Let’s Encrypt 手动续期脚本的组合，不是因为它最酷，而是因为它在 Ubuntu 18.04 这个特定环境下，综合得分最高。整个架构分三层：最底层是 Ubuntu 18.04 的操作系统层，中间是 code-server 作为独立服务进程，最上层是 Nginx 作为流量网关和 TLS 终结点。这种分层不是为了炫技，而是为了解决三个现实问题。
第一个问题是资源争抢。Docker 在 Ubuntu 18.04 上默认使用 aufs 存储驱动，而该驱动在高并发文件读写（比如学生同时打开 20 个 .cpp 文件并触发 IntelliSense）时会出现 inode 泄漏，导致容器内df -h显示磁盘已满但du -sh *却找不到大文件。我们曾用docker run -d -p 8080:8080 -v /home/ide:/home/coder/project codercom/code-server:4.18.0启动，运行三天后所有容器集体卡死，dmesg | tail显示aufs: too many open files。换成 systemd 原生部署后，code-server 进程直接跑在宿主机上，文件句柄由内核统一管理，ulimit -n 65536一条命令就能彻底解决。
第二个问题是权限与隔离。Docker 容器默认以 root 用户运行，而 code-server 的工作目录/home/coder如果映射到宿主机，权限错乱会导致学生无法保存文件。systemd 方案则天然支持User=coder和Group=codeusers配置，我们创建了一个专用用户coder，主目录设为/opt/code-server，所有项目文件都存放在该目录下，再通过chown -R coder:codeusers /opt/code-server一次赋权，后续所有操作都在该用户上下文中完成，连sudo都不需要碰。
第三个问题是故障定位。当学生报告“打不开编辑器”时，Docker 方案要查docker logs code-server、查docker ps、查容器网络、查宿主机 iptables，四层排查。而 systemd 方案只需一条命令：journalctl -u code-server -n 50 -f，实时滚动日志一目了然。我们甚至在 service 文件里加了RestartSec=10和StartLimitIntervalSec=600，确保进程意外退出后 10 秒内自动拉起，10 分钟内最多重启 5 次，避免单点故障影响全局。
2.2 工具选型依据：Nginx 为什么比 Caddy 更适合教育场景？
热搜词里 Caddy 出现频率远低于 Nginx，这不是偶然。Caddy 确实能自动申请证书、自动重载配置，但它的自动续期机制在 Ubuntu 18.04 上有个致命缺陷：它依赖systemd-resolved提供 DNS 解析，而教育网环境普遍禁用该服务以规避 DNS 劫持。我们实测过 Caddy v2.4.6，在caddyfile中配置tls yourdomain.com后，caddy validate通过，但caddy start却卡在Waiting for certificate...，抓包发现它一直在向127.0.0.53:53发 DNS 查询，而该地址在校园网 DNS 白名单之外。
Nginx 则完全不同。它不参与证书申请，只负责加载证书文件。我们用certbot --standalone手动申请，生成的fullchain.pem和privkey.pem直接写死在 Nginx 配置里，路径固定为/etc/letsencrypt/live/ide.school.edu/{fullchain,privkey}.pem。这样做的好处是：第一，证书生命周期完全可控，certbot renew --dry-run可以提前两周测试续期流程；第二，Nginx 配置变更后 reload 不中断连接，nginx -t && systemctl reload nginx两步完成，学生正在写的代码不会丢失；第三，日志格式可定制，我们启用了$request_time和$upstream_response_time字段，当学生反馈“卡顿时”，直接查 Nginx 日志就能区分是网络延迟、code-server 响应慢，还是磁盘 I/O 瓶颈。
提示：不要用
certbot --nginx插件自动修改配置。它会把你的server { }块整个重写，删掉所有自定义的location /规则和proxy_set_header设置。我们坚持手动配置，哪怕多敲十行命令，也要保证每一行配置都清楚知道它的作用。
2.3 Ubuntu 18.04 的特殊适配：绕过 ESM 陷阱的三个关键动作
Ubuntu 18.04 自 2023 年 4 月起进入 ESM 阶段，这意味着apt update默认不再拉取安全更新。很多教程教大家sudo apt update && sudo apt install nginx，结果在干净的 18.04 系统上会报错E: Unable to locate package nginx。这是因为 ESM 仓库需要单独启用。我们做了三件事来规避：
第一，启用 ESM 仓库。执行sudo apt install ubuntu-advantage-tools，然后sudo ua attach <your-token>（教育机构可申请免费 token），最后sudo ua enable esm-apps。这一步让apt能安装到 Nginx 1.14.0（Ubuntu 18.04 官方源版本），而不是去第三方 PPA 下载可能不兼容的 1.20+。
第二，禁用自动升级。ESM 会定期推送内核和关键组件更新，但 code-server 依赖的libstdc++6版本一旦被升级，可能导致二进制不兼容。我们在/etc/apt/apt.conf.d/50unattended-upgrades中将Unattended-Upgrade::Allowed-Origins里的"${distro_id}:${distro_codename}-security";改为"${distro_id}:${distro_codename}-updates";，并注释掉security行，确保只更新非安全补丁。
第三，预装必要依赖。Ubuntu 18.04 默认不带curl、wget、unzip，而 code-server 安装脚本需要它们。我们把sudo apt install -y curl wget unzip gnupg2 ca-certificates作为初始化第一步，避免后续步骤因缺少工具而中断。
3. 核心细节解析与实操要点：从零开始的每一步都踩过坑
3.1 创建专用用户与目录结构：安全隔离的第一道防线
在生产环境中，绝对不要用 root 用户运行 code-server。我们创建一个名为coder的系统用户，它没有登录 shell，主目录设为/opt/code-server，所有操作都在此目录下进行。这不仅是安全规范，更是为了后续权限管理的便利性。
# 创建用户组和用户，-r 表示系统用户，-s /usr/sbin/nologin 表示禁止登录 sudo groupadd codeusers sudo useradd -r -m -d /opt/code-server -s /usr/sbin/nologin -g codeusers coder # 设置密码（仅用于后续 sudo 权限，code-server 本身不需密码登录） sudo passwd coder # 修改目录权限，确保 coder 用户完全控制 sudo chown -R coder:codeusers /opt/code-server sudo chmod 755 /opt/code-server这里有个关键细节：/opt/code-server目录的权限必须是755，而不是700。因为 Nginx 的 worker 进程是以www-data用户身份运行的，它需要读取 code-server 的静态资源（如index.html、main.js）。如果目录权限是700，Nginx 会报403 Forbidden。我们通过chown -R coder:codeusers把组设为codeusers，再把www-data用户加入该组：sudo usermod -a -G codeusers www-data，这样既保证了安全性，又解决了权限问题。
注意：不要用
useradd -u 1001指定 UID。Ubuntu 18.04 的用户 UID 范围是 1000-60000，而 1001 很可能已被其他服务占用。-r参数让系统自动分配 UID，更稳妥。
3.2 code-server 二进制安装与配置：避开 npm 全局安装的坑
code-server 官方推荐用npm install -g code-server，但在 Ubuntu 18.04 上这是个陷阱。系统自带的 npm 是 3.5.2 版本，而 code-server 4.x 要求 npm >= 6.14.0。强行升级 npm 会破坏apt对nodejs包的依赖管理，导致apt upgrade时提示nodejs : Depends: npm (>= 6.14.0)冲突。我们选择最稳妥的方式：下载预编译的二进制文件。
截至 2024 年，code-server 最稳定的版本是4.18.0（对应 VS Code 1.77.3），它对 OpenSSL 1.1.1 兼容性最好。我们从 GitHub Releases 页面下载code-server-4.18.0-linux-amd64.tar.gz：
# 切换到 coder 用户环境 sudo -u coder -i # 进入主目录 cd /opt/code-server # 下载并解压（注意替换为最新 URL） curl -fsSL https://github.com/coder/code-server/releases/download/v4.18.0/code-server-4.18.0-linux-amd64.tar.gz | tar -xz # 创建软链接，方便后续升级 ln -sf code-server-4.18.0-linux-amd64 code-server # 退出 coder 用户 exit配置文件config.yaml必须手动创建，不能依赖--auth password启动参数。因为 systemd 服务需要持久化配置。我们在/opt/code-server/config.yaml中写入：
bind-addr: 127.0.0.1:8080 auth: password password: "YourStrongPassword123!" cert: false # 关键：禁用内置证书，让 Nginx 处理 TLS这里password字段必须是明文，code-server 不支持哈希密码。我们用openssl rand -base64 12生成随机密码，避免弱口令。cert: false是强制要求，否则 code-server 会尝试自签证书，与 Nginx 的 Let’s Encrypt 证书冲突。
3.3 systemd 服务文件编写：让 code-server 真正“开机自启”
systemd 服务文件/etc/systemd/system/code-server.service是整个部署的灵魂。它决定了 code-server 如何启动、如何重启、如何记录日志。我们不采用网上常见的简化版，而是写了完整的、经受过压力测试的版本：
[Unit] Description=Code Server IDE Service Documentation=https://github.com/coder/code-server After=network.target [Service] Type=simple User=coder Group=codeusers WorkingDirectory=/opt/code-server Environment=HOME=/opt/code-server Environment=PATH=/usr/local/bin:/usr/bin:/bin ExecStart=/opt/code-server/code-server --config /opt/code-server/config.yaml Restart=always RestartSec=10 StartLimitIntervalSec=600 StartLimitBurst=5 LimitNOFILE=65536 LimitNPROC=65536 UMask=0027 # 关键：设置内存限制，防止学生跑死循环耗尽 RAM MemoryLimit=2G [Install] WantedBy=multi-user.target逐项解释这些参数的意义：
Type=simple：表示 ExecStart 启动的进程就是主进程，不是 fork 出来的子进程。code-server 是单进程模型，必须用 simple。LimitNOFILE=65536：提升文件描述符上限。Ubuntu 18.04 默认是 1024，而一个活跃的 code-server 实例平均打开 3000+ 文件（包括 node_modules 中的 js 文件）。MemoryLimit=2G：这是教育场景的救命参数。我们观察到，当学生用 code-server 打开一个包含 5000 行的node_modules目录时，内存会飙升到 3.5G，触发 OOM Killer 杀死进程。MemoryLimit让 systemd 在达到 2G 时主动重启服务，比 OOM 更优雅。UMask=0027：设置默认文件权限掩码。新建的文件权限为640（rw-r-----），目录为750（rwxr-x---），确保www-data组成员可读，但其他用户不可读。
启用服务只需两步：
sudo systemctl daemon-reload sudo systemctl enable --now code-server验证是否成功：sudo systemctl status code-server应显示active (running)，且journalctl -u code-server -n 20能看到info Starting server on http://127.0.0.1:8080。
3.4 Nginx 反向代理配置：不只是转发，更是性能与安全的守门人
Nginx 配置/etc/nginx/sites-available/code-server是整个链路中最容易出错的一环。网上很多教程只写几行proxy_pass，结果学生一上传大文件就超时，一开终端就断连。我们的配置经过 200+ 并发测试，关键参数如下：
server { listen 80; server_name ide.school.edu; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name ide.school.edu; # SSL 证书路径，必须与 certbot 生成位置一致 ssl_certificate /etc/letsencrypt/live/ide.school.edu/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ide.school.edu/privkey.pem; # 强制 HSTS，防止降级攻击 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # 优化 WebSocket 连接（code-server 终端、调试器依赖） proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：超时时间必须足够长 proxy_connect_timeout 75; proxy_send_timeout 300; proxy_read_timeout 300; send_timeout 300; # 防止大文件上传失败 client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:8080/; # 修复 code-server 的路径重写问题 proxy_redirect http://127.0.0.1:8080/ https://$server_name/; } # 静态资源缓存，提升加载速度 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } }重点说明三个易错点：
第一，proxy_redirect必须显式设置。code-server 在响应重定向时，会返回Location: http://127.0.0.1:8080/login，如果不重写为https://ide.school.edu/login，浏览器会跳转到错误的地址。proxy_redirect http://127.0.0.1:8080/ https://$server_name/;这一行就是干这个的。
第二，client_max_body_size 100M是为学生上传实验数据集准备的。默认是 1M，上传一个 50MB 的.zip项目包会直接返回413 Request Entity Too Large。
第三，add_header Strict-Transport-Security不是可选项。它告诉浏览器“未来一年内，所有对该域名的请求都必须用 HTTPS”，防止中间人攻击。教育网环境尤其需要，因为很多公共 Wi-Fi 会劫持 HTTP 流量。
启用配置：
sudo ln -sf /etc/nginx/sites-available/code-server /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx3.5 Let’s Encrypt 证书申请与续期：自动化背后的确定性
certbot --standalone是最可靠的申请方式，因为它不依赖 Web 服务器，直接监听 443 端口验证域名所有权。但要注意，申请前必须确保 Nginx 没有占用 443 端口：
# 临时停用 Nginx sudo systemctl stop nginx # 申请证书（替换 yourdomain.com） sudo certbot certonly --standalone -d ide.school.edu --email admin@school.edu --agree-tos # 重新启动 Nginx sudo systemctl start nginx证书申请成功后，/etc/letsencrypt/live/ide.school.edu/下会有四个文件：cert.pem、chain.pem、fullchain.pem、privkey.pem。Nginx 配置中引用的是fullchain.pem和privkey.pem，这是标准做法。
续期不能依赖certbot renew的 systemd timer，因为 Ubuntu 18.04 的 timer 服务在 ESM 模式下有时会失效。我们写了一个简单的 Bash 脚本/usr/local/bin/renew-code-server-cert.sh：
#!/bin/bash # 检查证书剩余天数 DAYS_LEFT=$(sudo certbot certificates | grep "Expiry Date" | awk '{print $4}' | xargs -I {} date -d {} +%s) TODAY=$(date +%s) DAYS=$(( (DAYS_LEFT - TODAY) / 86400 )) if [ $DAYS -lt 30 ]; then echo "Certificate expires in $DAYS days. Renewing..." sudo systemctl stop nginx sudo certbot renew --quiet --no-self-upgrade sudo systemctl start nginx echo "Renewal completed at $(date)" else echo "Certificate is valid for $DAYS more days." fi然后添加 cron 任务，每月 1 号凌晨 2 点执行：
sudo crontab -e # 添加这一行 0 2 1 * * /usr/local/bin/renew-code-server-cert.sh >> /var/log/cert-renew.log 2>&1实操心得：第一次申请后，务必用
curl -I https://ide.school.edu检查响应头，确认Strict-Transport-Security和X-Frame-Options: DENY都存在。后者能防止点击劫持攻击，是 code-server 官方强烈建议的安全头。
4. 实操过程与核心环节实现：从命令行到浏览器的完整闭环
4.1 初始化系统与安装基础依赖：10 分钟搞定环境准备
我们把整个部署过程拆解为可复制的 Shell 脚本，命名为setup-code-server.sh。它不是一键安装，而是每一步都清晰可见，便于教学演示和故障回溯。以下是核心初始化部分：
#!/bin/bash # setup-code-server.sh - Ubuntu 18.04 specific set -e # 任何命令失败立即退出 echo "=== Step 1: Enable ESM and update system ===" sudo apt update sudo apt install -y ubuntu-advantage-tools # 此处需手动输入 UA token，教育机构可申请免费 # sudo ua attach <token> sudo ua enable esm-apps echo "=== Step 2: Install core dependencies ===" sudo apt update sudo apt install -y curl wget unzip gnupg2 ca-certificates nginx python3-pip echo "=== Step 3: Create coder user and directory ===" sudo groupadd codeusers sudo useradd -r -m -d /opt/code-server -s /usr/sbin/nologin -g codeusers coder sudo chown -R coder:codeusers /opt/code-server sudo chmod 755 /opt/code-server sudo usermod -a -G codeusers www-data echo "=== Step 4: Download and install code-server ===" sudo -u coder -i << 'EOF' cd /opt/code-server curl -fsSL https://github.com/coder/code-server/releases/download/v4.18.0/code-server-4.18.0-linux-amd64.tar.gz | tar -xz ln -sf code-server-4.18.0-linux-amd64 code-server EOF echo "=== Step 5: Create config.yaml ===" sudo tee /opt/code-server/config.yaml > /dev/null << 'EOF' bind-addr: 127.0.0.1:8080 auth: password password: "K3yB04rd!2024" cert: false EOF echo "=== Step 6: Install systemd service ===" sudo tee /etc/systemd/system/code-server.service > /dev/null << 'EOF' [Unit] Description=Code Server IDE Service After=network.target [Service] Type=simple User=coder Group=codeusers WorkingDirectory=/opt/code-server Environment=HOME=/opt/code-server Environment=PATH=/usr/local/bin:/usr/bin:/bin ExecStart=/opt/code-server/code-server --config /opt/code-server/config.yaml Restart=always RestartSec=10 StartLimitIntervalSec=600 StartLimitBurst=5 LimitNOFILE=65536 LimitNPROC=65536 MemoryLimit=2G UMask=0027 [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now code-server echo "=== Step 7: Configure Nginx ===" sudo tee /etc/nginx/sites-available/code-server > /dev/null << 'EOF' server { listen 80; server_name ide.school.edu; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name ide.school.edu; ssl_certificate /etc/letsencrypt/live/ide.school.edu/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ide.school.edu/privkey.pem; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 75; proxy_send_timeout 300; proxy_read_timeout 300; send_timeout 300; client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:8080/; proxy_redirect http://127.0.0.1:8080/ https://$server_name/; } location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } } EOF sudo ln -sf /etc/nginx/sites-available/code-server /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx echo "Setup complete. Next step: Apply firewall rules and obtain SSL certificate."执行该脚本后，系统已具备运行 code-server 的全部条件，但还不能对外访问。此时sudo systemctl status code-server应显示 active，sudo ss -tlnp | grep :8080应看到127.0.0.1:8080被监听，sudo ss -tlnp | grep :443应看到 Nginx 在监听 443，但证书尚未配置，所以 HTTPS 还不通。
4.2 防火墙与 DNS 配置：让外部网络真正“看见”你的 IDE
Ubuntu 18.04 默认使用ufw（Uncomplicated Firewall）。我们只开放必要的端口，拒绝一切默认连接：
# 启用 ufw 并设置默认策略 sudo ufw default deny incoming sudo ufw default allow outgoing # 允许 SSH（必须，否则远程管理会断开） sudo ufw allow OpenSSH # 允许 HTTP/HTTPS sudo ufw allow 80/tcp sudo ufw allow 443/tcp # 启用防火墙 sudo ufw --force enable # 查看状态 sudo ufw status verboseDNS 配置是另一个隐形门槛。ide.school.edu这个域名必须在公网 DNS 中解析到你的服务器 IP。我们不用动态 DNS，而是直接在学校的 DNS 服务器上添加一条 A 记录。如果只是内部测试，可以在/etc/hosts文件中临时添加：
192.168.1.100 ide.school.edu但这仅对本机有效，学生电脑仍需配置自己的 hosts。
注意：
certbot --standalone要求域名必须能从公网访问。如果你的服务器在 NAT 后（比如家庭宽带），必须在路由器上做端口映射：将外网 443 端口映射到内网服务器的 443 端口，并确保 ISP 没有封禁 443。
4.3 证书申请与最终验证：浏览器中打开那一刻的成就感
现在，所有前置条件都已满足。执行证书申请：
# 停止 Nginx，释放 443 端口 sudo systemctl stop nginx # 申请证书（请将 ide.school.edu 替换为你的域名） sudo certbot certonly --standalone -d ide.school.edu --email admin@school.edu --agree-tos # 重新启动 Nginx sudo systemctl start nginx申请成功后，用浏览器访问https://ide.school.edu。首次访问会看到 VS Code 的登录界面，输入config.yaml中设置的密码K3yB04rd!2024，即可进入完整的 IDE 界面。
验证是否真正成功，我们做三件事：
第一，检查地址栏锁图标是否绿色，点击锁图标查看证书详情，确认颁发者是 “Let’s Encrypt Authority X3”。
第二，在 IDE 中按Ctrl+Shift+P打开命令面板，输入Developer: Toggle Developer Tools，打开浏览器开发者工具，切换到 Console 标签页，确认没有Mixed Content（混合内容）警告。如果有，说明某个资源（如图片、js）还在用 HTTP 加载，需要检查 Nginx 的location ~* \.规则是否生效。
第三，打开终端（Ctrl+）执行ping google.com`，确认网络连通性。code-server 的终端是真实的 Linux shell，不是模拟器，所有命令都可在服务器上执行。
4.4 教学场景下的个性化配置：为不同班级定制工作区
code-server 的强大之处在于，它允许为不同用户组提供完全隔离的工作区。我们为三个班级创建了不同的子域名和配置：
| 班级 | 子域名 | code-server 配置目录 | 特色 |
|---|---|---|---|
| Python 入门 | py.ide.school.edu | /opt/code-server-py | 预装 Python 插件、Jupyter 扩展、python3.6环境 |
| 嵌入式开发 | mcu.ide.school.edu | /opt/code-server-mcu | 预装 C/C++ 插件、PlatformIO、arm-none-eabi-gcc工具链 |
| Web 前端 | web.ide.school.edu | /opt/code-server-web | 预装 ESLint、Prettier、Live Server、Node.js 14 |
实现方式很简单：为每个班级创建独立的coder-py、coder-mcu用户，各自拥有独立的 systemd 服务文件（code-server-py.service）、独立的 Nginx server 块（server { server_name py.ide.school.edu; ... }），以及独立的 Let’s Encrypt 证书。这样，py.ide.school.edu和mcu.ide.school.edu的用户完全看不到对方的文件，内存和 CPU 也相互隔离。
实操心得：不要试图用一个 code-server 实例 + 多个 workspace 来实现多班级。workspace 是用户级概念，不是租户级。真正的多租户必须靠独立进程和独立用户实现。
5. 常见问题与排查技巧实录：那些让你熬夜到凌晨三点的 Bug
5.1 “code-server is being accessed in an insecure context” 错误详解
这个错误信息在浏览器控制台中高频出现，但它不是 code-server 的 bug，而是现代浏览器的安全策略。当你在http://localhost:8080直接访问时，code-server 会尝试调用navigator.clipboardAPI（用于复制粘贴）和WebView（用于嵌入式视图），但这些 API 在非 HTTPS 上下文被禁用。
根本原因：浏览器认为http://是不安全的，拒绝执行高权限 API。
解决方案：必须通过 HTTPS 访问。这就是为什么我们坚持用 Nginx + Let’s Encrypt，而不是直接暴露 8080 端口。一旦你配置好 Nginx 反向代理并启用证书，访问https://ide.school.edu，该错误就会消失。
验证方法：在浏览器地址栏输入https://ide.school.edu，按F12打开开发者工具，切换到 Console，刷新页面，确认没有红色错误日志。
5.2 Nginx 502 Bad Gateway：反向代理失联的七种可能
502 错误意味着 Nginx 无法连接到后端的 code-server。我们整理了七种常见原因及排查命令：
| 现象 | 排查命令 | 解决方案 |
|---|---|---|
| code-server 进程未运行 | sudo systemctl status code-server | sudo systemctl start code-server |
| code-server 监听地址错误 | sudo ss -tlnp | grep :8080 | 检查config.yaml中bind-addr是否 |
