1. 项目概述：在 Ubuntu 18.04 上部署一个真正可用的 code-server 云 IDE 平台

你是不是也遇到过这样的场景：临时要改一段 Python 脚本，但手边只有公司配的 Windows 笔记本，装 Anaconda 卡在防火墙；或者带学生做嵌入式开发，每人配一台树莓派成本太高，远程桌面又卡得像幻灯片；又或者团队里前端、后端、测试都在用不同系统的电脑，共享一套调试环境成了运维噩梦。code-server 就是为解决这类问题而生的——它不是简单的 VS Code 远程插件，而是把整个 VS Code 编辑器完整运行在服务端，通过浏览器访问，所有计算、编译、调试都在服务器上完成，客户端只要能打开 Chrome 或 Edge 就行。我第一次在客户现场用它给三位不同部门的同事同时演示一个 Node.js 微服务调试流程，三个人分别用 iPad、MacBook 和 Windows 台式机，连上同一个地址，各自开终端、装依赖、打断点，全程零卡顿，连他们自己都惊讶：“这真的是在跑 VS Code？不是网页版简化版？”

标题里“So richten Sie die Code-Server-Cloud-IDE-Plattform unter Ubuntu 18.04 ein”是德语，直译是“如何在 Ubuntu 18.04 上配置 code-server 云 IDE 平台”。但实际落地远不止“配置”二字。Ubuntu 18.04 是一个已进入 ESM（扩展安全维护）阶段的老版本，官方不再提供常规更新，这意味着你不能直接套用最新版 code-server 的一键安装脚本，也不能指望apt install nginx装出来的就是支持 HTTP/2 和现代 TLS 的版本。更关键的是，“云 IDE”三个字背后藏着真实生产环境的硬性要求：必须支持 HTTPS 加密传输（否则浏览器会拦截剪贴板、终端、调试器等核心功能）、必须能反向代理隐藏端口、必须能处理多用户隔离或子域名路由、必须能稳定运行超过 72 小时不崩溃。网络热词里反复出现的 “code-server is being accessed in an insecure context” 就是典型症状——当你用http://ip:8080直连时，Chrome 会直接禁用navigator.clipboardAPI，导致复制粘贴失效；而webview组件加载失败，则会让 Jupyter 插件、Markdown 预览、甚至部分语言服务器彻底瘫痪。这不是 bug，是现代浏览器对非安全上下文的主动防御。所以，这个项目本质是一次面向生产环境的全栈加固：从底层系统兼容性判断，到 Nginx 反向代理的精确参数控制，再到 Certbot 自动证书续期的守护机制，每一步都绕不开 Ubuntu 18.04 这个特定基座的约束条件。它适合三类人：一是需要快速搭建教学/培训沙箱的高校教师或企业内训师；二是管理老旧物理服务器但又想提供现代化开发体验的中小公司运维；三是喜欢折腾、愿意花 90 分钟亲手打磨一个稳定工具链的技术爱好者。如果你只是想试试 code-server 长什么样，docker run -it -p 8080:8080 -v "$PWD:/home/coder/project" codercom/code-server一行命令就够了；但如果你想让它真正扛住每天 20 人的并发编辑、持续运行三个月不重启、还能让学生在课堂上顺滑地复制粘贴代码片段——那接下来这五千字，就是你绕不开的实操地图。

2. 整体架构设计与关键决策逻辑

2.1 为什么必须放弃 Docker 方案，坚持原生部署？

看到标题和热词里频繁出现 “docker安装nginx”，你可能会下意识想：用 Docker 不是更简单？打包好 code-server + Nginx + Certbot，一条docker-compose up -d全部搞定。我试过三次，全部在第三天崩溃。根本原因在于 Ubuntu 18.04 的内核版本（4.15.x）与 Docker 默认的 overlay2 存储驱动存在已知兼容性问题，表现为容器内文件系统随机只读（Read-only file system错误），尤其在 code-server 高频写入.vscode配置目录或node_modules缓存时触发。更致命的是，Docker 容器内的systemd无法正常启动 Certbot 的自动续期定时任务（certbot.timer），因为容器默认不启用--privileged模式，而systemd在非特权容器中无法接管timer单元。我曾用crontab -e手动添加0 2 * * 1 /usr/bin/certbot renew --quiet --post-hook "/usr/sbin/nginx -s reload"，结果发现 Certbot 续期日志里反复报错Failed to connect to localhost port 80: Connection refused——因为容器网络模型导致 Certbot 的 HTTP-01 挑战请求根本无法被 Nginx 容器正确捕获。最终解决方案是回归原生部署：code-server 以系统服务方式运行（systemctl start code-server@coder），Nginx 作为主机级反向代理（/etc/nginx/sites-available/code-server），Certbot 直接操作主机 Nginx 配置。这样所有组件共享同一套文件系统、网络栈和定时任务调度器，规避了容器抽象层带来的不可控因素。当然，代价是部署步骤变多，但换来的是可预测的稳定性——在我维护的 7 台 Ubuntu 18.04 教学服务器上，这套方案平均无故障运行时间已达 142 天。

2.2 为什么选择 Nginx 而非 Caddy 或 Traefik？

热词列表里有大量 Nginx 相关关键词，但也有开发者会问：Caddy 自动 HTTPS 更省事，Traefik 支持服务发现更云原生。答案很现实：Ubuntu 18.04 的软件源里，Caddy 仅提供 0.10.x 版本（发布于 2017 年），不支持 WebSockets 的upgrade头透传，而 code-server 的终端和调试器严重依赖 WebSocket 长连接；Traefik 则需要 Go 1.11+ 环境，而 Ubuntu 18.04 默认的golang-go包是 Go 1.10，手动编译 Traefik 1.7+ 会触发undefined: sync.Map编译错误（sync.Map在 Go 1.9 才引入）。Nginx 是唯一在 Ubuntu 18.04 官方源中提供 1.14.0+ 版本（nginx-full包）且原生支持proxy_set_header Upgrade $http_upgrade的成熟方案。更重要的是，Nginx 的配置语法高度确定：location /块里的proxy_pass http://127.0.0.1:8080;这一行就决定了流量走向，没有隐式行为，排查问题时nginx -t语法检查 +tail -f /var/log/nginx/error.log日志追踪，路径清晰。我见过太多 Caddy 用户在reverse_proxy规则里漏掉header_up Host {host}导致 code-server 重定向到localhost:8080，最后在浏览器地址栏里看到http://localhost:8080/login?redirect=%2F这种诡异跳转——这种问题在 Nginx 里，加一行proxy_set_header Host $host;就解决，无需理解中间件生命周期。

2.3 为什么 Certbot 必须申请泛域名证书，而非单域名？

热词里明确提到 “certbot申请泛域名证书”，这不是炫技，而是 code-server 的 URL 结构决定的。当你访问https://ide.example.com时，code-server 实际会发起多个子资源请求：/static/...加载前端 JS、/terminals/...建立终端 WebSocket、/api/...调用后端 API。如果只申请ide.example.com的单域名证书，这些子路径请求在 TLS 握手时完全没问题。但问题出在浏览器安全策略：当 code-server 页面通过https://ide.example.com加载后，其内嵌的iframe或webview组件尝试访问https://ide.example.com/terminals/123时，若该路径返回的响应头中Content-Security-Policy包含frame-ancestors 'self'，而当前页面协议、域名、端口三者不完全匹配，就会触发跨域拦截。更隐蔽的是，code-server 的--auth=none模式下，它会生成一个随机 token 作为 session 标识，该 token 会出现在 URL 查询参数中（如?tkn=abc123），而某些旧版 Certbot 的--standalone模式在验证 HTTP-01 挑战时，会占用 80 端口导致 Nginx 无法监听，进而让 code-server 的健康检查失败。泛域名证书（*.example.com）一劳永逸：无论你后续增加docs.example.com（文档站）、api.example.com（后端 API）、还是ide-staging.example.com（测试环境），证书都通用。申请命令certbot certonly --manual --preferred-challenges=dns -d example.com -d *.example.com中的--manual强制你手动添加 DNS TXT 记录，虽然多点操作，但换来的是证书私钥完全可控、无第三方 CA 临时端口监听风险。我在某次金融客户部署中，就因客户安全审计要求“禁止任何外部服务监听内部网络端口”，最终放弃了--standalone，全程用 DNS 手动验证，耗时 12 分钟，但审计报告里这一项直接打勾通过。

2.4 为什么 code-server 必须以系统用户模式运行，而非 root？

标题里没提用户权限，但这是最容易踩坑的环节。很多教程教你在 root 下执行code-server --bind-addr 0.0.0.0:8080，看似省事，实则埋雷。code-server 启动后会创建~/.local/share/code-server目录存放扩展缓存、用户设置、工作区历史，若以 root 运行，该目录属主为 root，后续普通用户（如coder）无法写入，导致插件安装失败、设置无法保存。更严重的是，code-server 的终端功能会调用pty（伪终端），而 Linux 内核对 root 用户的 pty 创建有额外限制，表现为终端窗口打开后立即显示The terminal process failed to launch: Path to shell executable "bash" does not exist.。正确做法是创建专用系统用户coder：sudo adduser --disabled-password --gecos "" coder，然后用sudo -u coder code-server --bind-addr 127.0.0.1:8080 --auth=password --password=your_secure_password启动。这里--bind-addr 127.0.0.1:8080是关键——只监听本地回环，避免外部直接访问未加密的 8080 端口，所有流量必须经由 Nginx 反向代理，既满足安全要求，又解耦了网络暴露面。我曾帮一个初创公司排查连续三天的 code-server 崩溃问题，最后发现是开发人员用sudo code-server启动，导致/root/.local/share/code-server目录被 root 占用，而他们的 CI 脚本又试图用coder用户写入同一路径，Permission denied错误被静默吞掉，表现为服务启动后 5 分钟自动退出。改成系统用户模式后，问题消失。

3. 核心细节解析与实操要点

3.1 Ubuntu 18.04 系统预检：确认内核、包管理器与时间同步状态

在敲任何命令前，先执行三步诊断，避免后续所有操作白费：

# 1. 检查内核版本是否 >= 4.15（Ubuntu 18.04 最低要求） uname -r # 正常输出应为 4.15.0-xx-generic，若低于此值（如 4.4.x），需先升级内核： # sudo apt update && sudo apt install linux-image-generic-hwe-18.04 # 2. 验证 APT 包索引是否完整（Ubuntu 18.04 的源在 2023 年已迁移至 old-releases） grep -r "archive.ubuntu.com\|security.ubuntu.com" /etc/apt/sources.list* # 若输出包含上述域名，说明源已失效，必须替换为 old-releases： sudo sed -i 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list sudo apt update # 3. 强制时间同步（code-server 的 JWT token 和 Certbot 的证书有效期都依赖系统时间） sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd timedatectl status | grep "System clock synchronized" # 输出必须为 "yes"，否则 Certbot 会报错 "Certificate not yet valid"

这三步看似简单，却是我踩过最多坑的环节。有一次在客户机房，timedatectl status显示System clock synchronized: no，手动sudo ntpdate -s time.nist.gov后仍不同步，最后发现是 BIOS 电池没电导致每次重启时间重置为 2000 年。这种硬件级问题，不提前检查，你会在 Certbot 申请证书时收到urn:acme:error:badNonce错误，然后花两小时排查 ACME 协议，而真相只是主板电池该换了。

3.2 Nginx 安装与基础配置：绕过 Ubuntu 18.04 的源限制

Ubuntu 18.04 官方源中的 Nginx 版本是 1.14.0，虽能满足基本需求，但缺少stream模块（用于 TCP/UDP 代理）和ngx_http_v2_module（HTTP/2 支持），而 code-server 的 WebSocket 流量在 HTTP/2 下表现更优。因此，我们采用官方预编译包安装：

# 添加 Nginx 官方签名密钥 curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - # 添加官方源（注意：Ubuntu 18.04 对应 bionic） echo "deb [arch=amd64] http://nginx.org/packages/ubuntu/ bionic nginx" | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update # 安装完整版（包含 stream 和 http_v2 模块） sudo apt install nginx-full # 验证模块加载 nginx -V 2>&1 | grep -o "http_v2\|stream" # 应输出 "http_v2 stream"

安装后，必须禁用默认站点，否则http://server-ip会返回 Nginx 欢迎页，干扰 code-server 的健康检查：

sudo rm /etc/nginx/sites-enabled/default sudo systemctl restart nginx curl -I http://127.0.0.1 # 应返回 404 Not Found，而非 200 OK

提示：nginx -t是你的第一道防线。每次修改/etc/nginx/nginx.conf或sites-available下的配置后，务必执行此命令。我见过太多人因少打一个分号;或错位一个大括号}导致nginx -s reload失败，服务中断。nginx -t的输出会精确到第几行第几个字符，比如nginx: [emerg] invalid number of arguments in "proxy_set_header" directive in /etc/nginx/sites-available/code-server:12:23，直接定位问题。

3.3 Certbot 安装与泛域名证书申请：DNS 验证的实操细节

Ubuntu 18.04 的python3-certbot-nginx包版本过旧（0.31.x），不支持 ACME v2 协议的泛域名申请。必须使用 pip3 安装最新版：

sudo apt install python3-pip sudo pip3 install --upgrade certbot certbot-nginx # 验证版本 certbot --version # 应输出 certbot 2.8.0 或更高

申请泛域名证书的核心是 DNS TXT 记录验证。假设你的域名是example.com，需要添加两条 TXT 记录：

注意：第二条记录的主机名留空（即@），部分 DNS 控制台显示为example.com或直接写@。Certbot 会提示你添加哪条，严格按提示操作。我曾在一个使用 Cloudflare 的客户环境里，因未关闭 Cloudflare 的代理（橙色云朵），导致 Certbot 的 DNS 查询被 CDN 缓存，TXT 记录始终查不到，卡在验证环节。解决方案是暂时将_acme-challenge记录的代理状态改为灰色（DNS only），验证通过后再切回。

执行申请命令：

sudo certbot certonly --manual --preferred-challenges=dns \ -d example.com -d *.example.com \ --server https://acme-v02.api.letsencrypt.org/directory

Certbot 会交互式提示你添加 TXT 记录，并等待你输入Enter继续验证。关键技巧：在按下回车前，务必用dig -t txt _acme-challenge.example.com @8.8.8.8命令在 Google DNS 上查询记录是否生效。因为本地 DNS 缓存可能延迟，而 Certbot 默认只查本地 resolver。我通常会等dig返回正确的 TXT 值两次（间隔 30 秒），再按回车，确保 100% 通过。

3.4 code-server 二进制安装与系统服务化：解决 Ubuntu 18.04 的 glibc 兼容性

code-server 官网提供的.deb包基于较新 glibc，与 Ubuntu 18.04 的 glibc 2.27 不兼容。必须下载预编译二进制：

# 创建专用目录 sudo mkdir -p /opt/code-server cd /opt/code-server # 下载与 Ubuntu 18.04 兼容的版本（v4.18.0 是最后一个明确支持 glibc 2.27 的版本） sudo wget https://github.com/coder/code-server/releases/download/v4.18.0/code-server-4.18.0-linux-amd64.tar.gz sudo tar xzf code-server-4.18.0-linux-amd64.tar.gz sudo chown -R root:root code-server-4.18.0-linux-amd64 # 创建软链接便于升级 sudo ln -sf code-server-4.18.0-linux-amd64 code-server

创建系统服务文件/etc/systemd/system/code-server@.service：

[Unit] Description=code-server service for %i After=network.target [Service] Type=simple User=%i WorkingDirectory=/home/%i ExecStart=/opt/code-server/code-server --bind-addr 127.0.0.1:8080 --auth=password --password=your_secure_password --disable-telemetry Restart=always RestartSec=10 # 关键：设置内存限制，防止 OOM killer 杀死进程 MemoryLimit=2G # 关键：设置文件描述符上限，应对高并发 WebSocket LimitNOFILE=65536 [Install] WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload sudo systemctl enable code-server@coder.service sudo systemctl start code-server@coder.service # 检查状态 sudo systemctl status code-server@coder.service # 应显示 "active (running)"

注意：--disable-telemetry参数必须添加。code-server 默认会向telemetry.coder.com发送匿名使用数据，而 Ubuntu 18.04 的systemd-resolved在某些网络环境下会解析失败，导致启动超时。禁用后，服务启动时间从 45 秒降至 2 秒。

4. 实操过程与核心环节实现

4.1 Nginx 反向代理配置详解：解决 WebSocket、剪贴板与跨域三大痛点

创建/etc/nginx/sites-available/code-server：

upstream code-server-backend { server 127.0.0.1:8080; } server { listen 443 ssl http2; server_name ide.example.com; # SSL 证书路径（Certbot 自动生成） ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # 强制 HTTPS 重定向（可选，但推荐） if ($scheme != "https") { return 301 https://$host$request_uri; } # 核心：WebSocket 支持 location / { proxy_pass http://code-server-backend; 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_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; # 关键：解决剪贴板被禁用问题 add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self' ws: wss:; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';" always; # 关键：解决跨域问题（code-server 内部 API 调用） add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"; add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization"; add_header Access-Control-Expose-Headers "Content-Length,Content-Range"; # 关键：超时设置，防止长连接断开 proxy_read_timeout 86400; proxy_send_timeout 86400; proxy_connect_timeout 7d; } # 健康检查端点（供负载均衡器使用） location /healthz { return 200 "OK"; add_header Content-Type text/plain; } }

启用配置并测试：

sudo ln -sf /etc/nginx/sites-available/code-server /etc/nginx/sites-enabled/code-server sudo nginx -t # 必须通过！ sudo systemctl reload nginx

这段配置解决了三个核心问题：

• Upgrade $http_upgrade和Connection "upgrade"让 Nginx 识别并透传 WebSocket 升级请求，code-server 终端才能建立长连接；
• Content-Security-Policy头明确允许connect-src 'self' ws: wss:，告诉浏览器ws://ide.example.com/terminals/123是可信的 WebSocket 地址，从而解锁剪贴板 API；
• Access-Control-Allow-*头允许前端代码跨域调用https://ide.example.com/api/...接口，避免fetch请求被拦截。

4.2 Certbot 自动续期守护：编写健壮的 post-hook 脚本

Certbot 的--renew-hook在证书续期成功后执行，但默认的nginx -s reload可能失败（如配置语法错误、磁盘满）。我们编写一个带校验的守护脚本/usr/local/bin/renew-code-server.sh：

#!/bin/bash # 检查 Nginx 配置语法 if ! nginx -t; then echo "Nginx config test failed. Aborting reload." | logger -t certbot-renew exit 1 fi # 检查磁盘空间（至少预留 1GB） if [ $(df / | awk 'NR==2 {print $4}') -lt 1048576 ]; then echo "Low disk space on /, aborting nginx reload." | logger -t certbot-renew exit 1 fi # 执行平滑重载 systemctl reload nginx # 验证 Nginx 是否仍在运行 if ! systemctl is-active --quiet nginx; then echo "Nginx reload failed, attempting restart." | logger -t certbot-renew systemctl restart nginx fi # 通知管理员（可选） echo "Code-server certificate renewed and nginx reloaded at $(date)" | mail -s "Code-server Cert Renewal" admin@example.com

赋予执行权限并注册到 Certbot：

sudo chmod +x /usr/local/bin/renew-code-server.sh # 编辑 Certbot 的 renewal 配置 sudo nano /etc/letsencrypt/renewal/example.com.conf # 在 [renewalparams] 段落末尾添加： renew_hook = /usr/local/bin/renew-code-server.sh

实操心得：我最初用certbot renew --dry-run测试时，发现renew_hook脚本里的mail命令因未配置 MTA（邮件传输代理）而失败，导致整个续期流程中断。后来改用logger记录到系统日志，再用journalctl -u certbot.timer -n 50查看，问题一目了然。记住：在生产环境，任何外部依赖（邮件、短信、Webhook）都应设为可选，核心逻辑（reload nginx）必须保证成功。

4.3 code-server 用户管理与安全加固：密码、HTTPS 与网络隔离

code-server 默认只支持单用户密码认证（--auth=password），但生产环境需更细粒度控制。我们通过 Nginx 实现基础认证：

# 生成密码文件（用户 coder，密码 your_secure_password） sudo htpasswd -c /etc/nginx/.htpasswd coder # 输入密码两次

修改 Nginx 配置，在location /块内添加：

auth_basic "Code-Server Authentication"; auth_basic_user_file /etc/nginx/.htpasswd;

然后重启 Nginx。这样，访问https://ide.example.com时，浏览器会弹出标准 HTTP Basic Auth 对话框，输入coder和密码才能进入。这比 code-server 自带的密码更安全，因为认证发生在 Nginx 层，code-server 进程完全不知道密码，且可轻松扩展为多用户（htpasswd -b /etc/nginx/.htpasswd user2 pass2）。

网络层面加固：Ubuntu 18.04 的ufw防火墙默认关闭，必须启用：

sudo ufw enable sudo ufw default deny incoming sudo ufw allow OpenSSH sudo ufw allow 'Nginx Full' # 开放 80,443 # 确保 code-server 的 8080 端口仅限本地访问 sudo ufw allow from 127.0.0.1 to any port 8080 sudo ufw status verbose

注意：ufw allow from 127.0.0.1这一行至关重要。它确保只有 Nginx（运行在本机）能访问 code-server 的 8080 端口，外部攻击者即使扫描到 8080 端口，也会被防火墙拒绝。我曾用nmap -sT -p 8080 server-ip验证，输出为8080/tcp filtered http-proxy，证明端口对外不可见。

4.4 全流程验证与压力测试：模拟真实用户场景

部署完成后，必须进行四层验证：

1. 基础连通性：
   在任意设备浏览器访问https://ide.example.com，应看到 code-server 登录页，输入密码后进入 VS Code 界面。打开开发者工具（F12），切换到 Console 标签页，确认无Mixed Content或Blocked clipboard access报错。

2. 核心功能测试：

   • 新建文件test.py，输入print("Hello World")，按Ctrl+Shift+P打开命令面板，输入Python: Run Python File in Terminal，确认终端输出正确结果；
   • 在命令面板中输入Developer: Toggle Developer Tools，打开 DevTools，切换到 Network 标签页，刷新页面，筛选ws协议，应看到terminals/xxx的 WebSocket 连接状态为101 Switching Protocols；
   • 复制一段代码，粘贴到编辑器中，确认无报错。

3. HTTPS 安全验证：
   点击浏览器地址栏左侧的锁图标，查看证书详情，确认颁发者为Let's Encrypt，有效期为 90 天，且域名匹配*.example.com。

4. 压力测试：
   使用ab（Apache Bench）模拟 10 个并发用户持续请求：

   ab -n 100 -c 10 https://ide.example.com/ # 关注 "Time per request"（应 < 500ms）和 "Failed requests"（应为 0）

   我在一台 4C8G 的 Ubuntu 18.04 服务器上，ab -n 500 -c 20测试结果为：平均响应时间 320ms，失败请求数 0，CPU 使用率峰值 65%，内存占用稳定在 1.2G。这证明配置足以支撑小型团队日常开发。

5. 常见问题与排查技巧实录

5.1 问题速查表：高频故障与一键修复命令

5.2 独家避坑技巧：那些文档里不会写的细节

• 技巧一：Nginx 日志分级调试
  当遇到504 Gateway Timeout时，不要只看error.log。在 Nginx 配置的server块内添加：

  error_log /var/log/nginx/code-server-error.log debug; access_log /var/log/nginx/code-server-access.log;

  然后sudo nginx -t && sudo systemctl reload nginx，再复现问题。debug级别日志会详细记录每次proxy_pass的连接、超时、重试过程，比如*1000 upstream timed out (110: Connection timed out) while connecting to upstream，直接定位是 code-server 启动慢还是网络延迟高。

• 技巧二：code-server 内存泄漏应急处理
  Ubuntu 18.04 的systemd支持内存使用监控。在code-server@.service的[Service]段落添加：

  MemoryMax=2G MemoryHigh=1.5G ExecStartPost=/bin/sh -c 'echo "Memory usage: $(systemctl show -p MemoryCurrent code-server@%i.service \| cut -d= -f2)" \| logger -t code-server-memory'

  这样当内存接近 1.5G 时，systemd会自动触发MemoryHigh事件（可配置OnMemoryHigh=执行清理脚本），并在日志中记录实时用量，方便你判断是否需要调整 `