A Tour of Go 简体中文版正式上线之后，我原本以为代码运行这一块已经基本稳定了。
生产环境中的课程页面由阿里云服务器提供，用户点击“运行”或“格式化”时，浏览器把请求发送给生产 Go Tour 服务，再由 Go Tour 访问 Go 官方提供的 Playground 接口。
最初的执行链路大致是：
浏览器
→ EdgeOne
→ 阿里云 Nginx
→ Go Tour
→ go.dev Playground
这套架构本身没有明显问题，而且生产服务器并不会在本机执行用户提交的 Go 代码。
但是实际运行一段时间后，我发现了另一个问题：
阿里云服务器访问 Go 官方 Playground 的网络链路并不总是稳定。
这最终促使我把代码执行流量从页面服务中拆出来，为 Playground 单独搭建一个美国执行转发节点。
这篇文章主要记录这个执行节点是怎么搭建起来的。
至于 A Tour of Go 前端如何从原来的阿里云同源接口切换到这个新节点，以及生产发布过程中遇到的 EdgeOne 缓存问题，我会放到下一篇继续整理。
一、问题不是 Go 代码执行，而是远程 Playground 网络链路
生产环境之前已经为 Playground 请求增加过诊断日志。
一次实际故障中，可以看到：
operation=compile
duration=10.112...
error="Post \"https://go.dev/_/compile\": net/http: TLS handshake timeout"
也就是说，请求等待了大约 10 秒以后，并没有进入正常的 Playground 编译响应，而是在 TLS 握手阶段就失败了。
这里需要特别说明一下。
这不是 A Tour of Go 自身编译代码失败，也不是阿里云服务器上的 Go 环境有问题。
生产服务器实际上根本不执行用户提交的代码。
问题发生在：
阿里云 Go Tour
→ go.dev
这段公网访问链路上。
因此，如果只是继续增加 Go 服务端重试、调整超时时间，最多只能缓解表面现象，并没有真正改变网络路径。
我更倾向于直接把 Playground 出口换到一个与官方服务连接更加稳定的位置。
二、为什么选择现有的 ZgoCloud 服务器
我手上本来就有一台位于美国的 ZgoCloud VPS。
这台服务器原本已经承担了一些长期运行的网络服务，目前资源为：
3 CPU
3 GB 内存
30 GB 存储
1500 GB 月流量
200 Mbps 带宽
从历史使用量看，每个月实际只消耗几十 GB 流量。
而 Playground 的一次编译或格式化请求，本质上只是少量 Go 源码和 JSON 响应。
因此，没有必要为了这个功能再单独购买一台服务器。
更合理的方式是：
在现有 ZgoCloud 节点上增加一个非常轻量的固定 Playground 反向代理。
这台服务器原本已经运行：
WireGuard
Wstunnel
所以新的 Playground 服务必须满足一个重要前提：
不能影响服务器上已经稳定运行的网络服务。
三、先比较 play.golang.org 与 go.dev
确定服务器之后，还有一个问题：
新的代理最终应该连接哪个官方入口？
原生产代码使用的是：
https://go.dev/_/compile
https://go.dev/_/fmt
但 Go Playground 本身还有更加直接的接口：
https://play.golang.org/compile
https://play.golang.org/fmt
因此我在 ZgoCloud 上进行了真实编译请求测试。
为了减少“先测试一个、再测试另一个”造成的时间顺序偏差，我最终采用了交替测试方式，对两个入口各进行了 100 次真实 compile 请求。
结果如下。
play.golang.org：
请求总数：100
HTTP 200：100/100
请求失败：0
平均耗时：0.133 s
中位耗时：0.120 s
P95： 0.254 s
最短耗时：0.105 s
最长耗时：0.286 s
go.dev：
请求总数：100
HTTP 200：100/100
请求失败：0
平均耗时：0.167 s
中位耗时：0.158 s
P95： 0.267 s
最短耗时：0.120 s
最长耗时：0.545 s
这里我并不想得出：
play.golang.org永远比go.dev更快。
因为在前面另一轮测试中，两者的延迟差距其实很小，甚至短时间内 go.dev 还略快过一次。
更重要的结论是：
从 ZgoCloud 出发，两套官方入口当前都能稳定完成真实编译请求。
而 play.golang.org 本身就是 Playground 的直接接口，因此最终我决定让新代理直接使用：
https://play.golang.org/compile
https://play.golang.org/fmt
这样执行链路也更加容易理解。
四、ZgoCloud 上继续使用 OneinStack
因为我的阿里云服务器本来就长期使用 OneinStack，所以这台 ZgoCloud 我也希望尽量保持相似的 Nginx 管理方式。
不过这次并没有直接复制阿里云当前正在运行的 OneinStack 目录。
生产服务器中的目录已经混入：
编译产物
安装日志
src 缓存
生产环境运行文件
直接复制并不适合作为新的服务器安装源。
因此我重新从干净的 OneinStack 基线恢复了之前的定制：
PHP 8.5.9
Imagick 3.8.1
随后又根据这次 ZgoCloud 的需求，把 Nginx 编译使用的 OpenSSL 调整为：
OpenSSL 3.5.7
最终在 ZgoCloud 上安装得到：
nginx/1.31.0
OpenSSL 3.5.7
这次服务器并不需要运行 WordPress，也没有准备部署 PHP 网站。
OneinStack 对我来说更多是为了：
- 保持熟悉的 Nginx 目录结构；
- 保持服务器操作习惯一致；
- 后续证书和虚拟主机管理更加方便。
五、最麻烦的问题：443 已经被现有网络服务占用
如果这是一台全新的 Web 服务器，Playground 代理直接监听 HTTPS 443 就可以了。
但是这台 ZgoCloud 服务器原本已经运行 Wstunnel：
0.0.0.0:443
→ Wstunnel
WireGuard 则使用：
UDP 51820
因此不能简单地让 Nginx 再监听：
443 ssl
否则就会与已有服务产生端口冲突。
我最终没有为了“必须使用标准 443”去增加额外的端口复用或复杂分流机制，而是采用了更加简单的方案：
443 → Wstunnel
8443 → Nginx Playground
51820 → WireGuard
Playground 正式地址因此确定为：
https://play.go-dev.shuijingwanwq.com:8443
这种设计虽然多了一个端口号，但它有一个很大的优点：
不改变服务器原有网络服务的运行架构。
对于当前这个低流量、固定用途的执行 API，我认为简单、稳定和可恢复性比“URL 看起来更漂亮”更加重要。
六、完整初始化 OneinStack 后，原有网络服务保持正常
OneinStack 的完整初始化并不只是安装 Nginx。
它还可能涉及：
apt 包更新
sysctl
limits
rsyslog
SSH 服务
UFW
系统初始化
而这台服务器本身已经运行 WireGuard 和 Wstunnel，所以执行完整初始化之前，我先备份了：
/etc/wireguard/wg0.conf
Wstunnel systemd 配置
Wstunnel TLS 证书和私钥
sshd 配置
sysctl 配置
iptables / ip6tables
路由与 rule
端口监听状态
同时确认 ZgoCloud 控制台还提供 VNC 和 Rescue，以便出现异常时进行恢复。
之后才执行完整的 OneinStack Nginx 安装。
安装成功后，又通过 ZgoCloud 控制台完成了一次真正的系统重启。
最终三个服务全部正常恢复：
nginx: active
wstunnel: active
wireguard: active
端口也完全符合预期。
截图里可以看到：
Nginx 1.31.0
OpenSSL 3.5.7
80 → Nginx
443 → Wstunnel
8443 → Nginx
51820 → WireGuard
这一步很重要。
因为它证明我们并不是为了增加 Playground 服务，把原来已经稳定工作的网络环境重新设计了一遍。
新的 Nginx Playground 服务只是作为一个额外的 Web 服务加入现有环境。
七、单独为 Playground 域名签发 HTTPS 证书
Playground 使用的域名为：
play.go-dev.shuijingwanwq.com
DNS 直接解析到 ZgoCloud：
154.21.196.249
这里没有再套 CDN。
首先通过 OneinStack 建立了一个 HTTP 虚拟主机：
/data/wwwroot/play.go-dev.shuijingwanwq.com
HTTP 80 主要用于 ACME 验证。
因为 OneinStack 的 HTTPS 虚拟主机流程默认会监听 443，而当前 443 已经被现有服务使用，所以证书没有通过 vhost.sh 的自动 HTTPS 流程创建。
我直接复用了服务器上的 acme.sh，通过 Webroot 模式签发 Let’s Encrypt 证书。
最终证书安装到：
/usr/local/nginx/conf/ssl/play.go-dev.shuijingwanwq.com.crt
/usr/local/nginx/conf/ssl/play.go-dev.shuijingwanwq.com.key
然后单独给这个域名增加：
8443 ssl
这样：
https://play.go-dev.shuijingwanwq.com:8443
就拥有了正常的 HTTPS。
八、这个代理不应该成为一个“任意代理”
新的执行节点虽然只是一个简单的 Nginx 反向代理，但我不希望它变成一个能够任意指定目标地址的通用转发入口。
最终只开放两个精确接口：
/compile
/fmt
它们分别固定转发：
/compile
→ https://play.golang.org/compile
以及：
/fmt
→ https://play.golang.org/fmt
没有开放：
/socket
/share
任意 upstream 参数
任意 URL 转发
本地 Go 执行
其他路径全部返回：
404
这样可以把这个节点的职责严格限制在：
为 A Tour of Go 提供固定的 Playground 编译和格式化转发能力。
九、CORS 只允许正式 A Tour of Go 站点
因为下一阶段要让浏览器直接从：
https://go-dev.shuijingwanwq.com
跨域请求：
https://play.go-dev.shuijingwanwq.com:8443
所以必须处理 CORS。
当前只允许：
Origin: https://go-dev.shuijingwanwq.com
正常支持：
POST
OPTIONS
并经过实际验证：
正确 Origin POST → 200
OPTIONS → 204
错误 Origin → 403
GET /compile → 405
未知路径 → 404
这比简单返回：
Access-Control-Allow-Origin: *
更符合这个服务的用途。
它本来就不是一个供任意第三方网页调用的公共 Playground API，而是为当前正式站点提供固定的执行转发能力。
十、还需要过滤上游返回的 HSTS 和 Alt-Svc
调试过程中还遇到了一个容易忽略的小问题。
play.golang.org 会返回：
Strict-Transport-Security
Alt-Svc
如果 Nginx 原样转发这些响应头，那么浏览器看到的域名却是：
play.go-dev.shuijingwanwq.com:8443
这可能产生与当前部署方式不一致的浏览器行为。
尤其是 HSTS。
当前这个域名的标准 443 并不是 Playground HTTPS 服务，而是服务器上的另一项既有网络服务。
如果浏览器以后把：
http://play.go-dev.shuijingwanwq.com
自动升级到：
https://play.go-dev.shuijingwanwq.com:443
就不会进入我们预期的 Playground 服务。
因此最终明确隐藏了上游：
Strict-Transport-Security
Alt-Svc
让这个 8443 API 不向浏览器传播不适用于当前域名部署方式的 HTTPS 策略。
十一、最终 Playground 代理验收
完成 Nginx 配置以后，我重新进行了完整验收。
结果如下。
/compile：
HTTP 200
ZGOCLOUD_COMPILE_OK
/fmt：
HTTP 200
ZGOCLOUD_FMT_OK
CORS 预检：
HTTP 204
旧路径：
/_/compile
→ HTTP 404
这也意味着新的公开 API 已经正式确定为：
https://play.go-dev.shuijingwanwq.com:8443/compile
https://play.go-dev.shuijingwanwq.com:8443/fmt
而不是继续模仿 go.dev 的：
/_/compile
/_/fmt
十二、最终架构
完成这一阶段以后，新的 Playground 节点结构已经非常简单：
A Tour of Go 浏览器
│
│ HTTPS :8443
▼
play.go-dev.shuijingwanwq.com
│
│ Nginx 固定反向代理
▼
play.golang.org
其中：
/compile → play.golang.org/compile
/fmt → play.golang.org/fmt
服务器原有网络服务保持原来的端口：
443/TCP → Wstunnel
51820/UDP → WireGuard
新的 Playground 服务则使用：
8443/TCP → Nginx
各服务使用不同端口，不需要修改原来的运行方式。
十三、这一阶段解决的只是“执行节点”
做到这里，其实还没有完成整个 A Tour of Go Playground 迁移。
因为生产网站原来的 JavaScript 仍然请求：
/_/compile
/_/fmt
也就是说，即使新的 ZgoCloud 节点已经准备好了，浏览器还不会自动使用它。
下一阶段还需要修改 go-tour-i18n：
Run
→ https://play.go-dev.shuijingwanwq.com:8443/compile
Format
→ https://play.go-dev.shuijingwanwq.com:8443/fmt
并且必须做到：
- 本地 preview 的
SocketTransport不受影响； - production
/socket继续禁用； - 旧阿里云
/_/compile、/_/fmt暂时保留用于兼容和回滚； - production bundle、自动部署脚本和 release manifest 同步更新；
- 最终通过真实浏览器验证，而不只是服务器
curl测试。
实际上线时，我还遇到了一个很典型的问题：
新 production release 已经部署成功，但浏览器仍然请求旧的
/_/compile。
最后发现并不是代码或部署失败，而是 EdgeOne 仍然缓存着旧的：
/tour/script.js
刷新这一个资源后，新的执行链路立即生效。
这一部分很适合单独再写一篇。
总结
这次调整最初只是因为生产环境偶尔出现：
TLS handshake timeout
但真正处理下来，我没有继续在阿里云 Go Tour 服务端增加更多重试，而是把问题拆成了两个独立部分：
页面服务
≠
代码执行服务
页面仍然由：
EdgeOne
→ 阿里云
→ Go Tour
提供。
代码执行则准备迁移到：
浏览器
→ ZgoCloud
→ play.golang.org
这样做带来的几个直接变化是：
- 阿里云不再需要承担正常 Playground 请求的远程转发；
- ZgoCloud 到 Playground 的真实请求当前延迟较低且连续测试稳定；
- 服务器原有 WireGuard 与 Wstunnel 网络服务无需重新设计；
- 执行代理只有两个固定接口；
- production 服务器依然不执行用户提交的 Go 代码；
- 将来如果需要调整 Playground 出口，也不必重新改变页面服务架构。
下一篇，我会继续整理：
如何修改 A Tour of Go 前端，让 Run / Format 真正绕过阿里云，直接访问 ZgoCloud，以及生产上线过程中 EdgeOne 缓存为什么让旧执行链路一度继续生效。
这部分完成之后，整个 Playground 执行链路迁移才算真正闭环。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ Brazilian Portuguese — Português (Brasil)
✅ Dutch — Nederlands
✅ French — Français
✅ German — Deutsch
✅ Italian — Italiano
✅ Japanese — 日本語
✅ Korean — 한국어
✅ Simplified Chinese — 简体中文
✅ Spanish — Español
✅ Turkish — Türkçe
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
项目正在持续扩展更多语言版本，并长期维护翻译质量、生产发布与后续更新。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。