TLS 终结 · WebSocket · allowedOrigins · Docker 上线可复核
已经在 VPS 上用 Docker 跑起 OpenClaw、准备挂上真实域名与 HTTPS的工程师，往往卡在「Gateway 该监听哪里、TLS 由谁终结、浏览器里 Control UI 为何报跨源或不安全回落」。本文用决策表对比「仅本机回环 + 边缘反代」与「容器端口直出公网」，给出Caddy 与 Nginx 最小反代片段、WebSocket 与 X-Forwarded 头字段、以及与 allowedOrigins 协同的验收顺序；OOM 与首轮 WASM 等话题留在Docker VPS 排障长文。安装总览见v2026.4 安装指南，生产暴露面清单见多通道加固文，镜像回滚见钉扎与回滚文。
Docker 场景下，真正上线还包括宿主机防火墙、Publish 只绑 127.0.0.1、证书链是否完整、通道回调 URL 是否已随 https 切换。下面列表用于值班分诊，细粒度参数仍以你当前版本的官方文档为准。
0.0.0.0 习惯：把 Gateway 直接暴露在公网接口上却未配套 WAF、频率限制与审计，攻击面陡增。
WebSocket 半程：反代未透传 Upgrade / Connection，表现为面板瞬时 502 或握手失败。
Host 与 Origin 漂移：浏览器访问域名 A，配置仍写死 IP 或内网别名，触发 Control UI 与 API 的跨源保护。
证书与 DNS 顺序：先于 DNS 生效申请证书、或混用自签与公网链，移动端与自动化客户端表现不一致。
磁盘与日志：反代与容器双路访问日志若未轮转，小盘 VPS 在高峰周把 inode 打满导致「假死」。
升级窗口：无钉扎镜像时在反代后做滚动切换，若未对齐预发布与回滚顺序，会出现新旧 Gateway 行为分叉。
提示：若当前阻塞是 OOM、Exit 137、首轮 WASM 等待或 Control UI allowedOrigins 设备配对，请优先对照排障对照表，本文不重复内存画像段落。
下列矩阵写给「第一次把 OpenClaw 从试验品推到域名下」的评审：目标是让 HTTPS、会话通道与可观测性在同一叙事下可验收。
| 维度 | 127.0.0.1 Gateway + 反代 TLS | 容器端口直绑公网 |
|---|---|---|
| 最小暴露 | 公网只触达 443，上游仅本机回环 | 需独立网络 ACL 与持续端口审计 |
| 证书维护 | 集中在 Caddy / Nginx / ACME 一条链路 | 应用内或 sidecar 各自维护，易漂移 |
| WebSocket | 由成熟反代模块处理升级与超时 | 易漏头，直连调试掩盖问题 |
| 可观测 | 边缘与上游日志可分段关联 request_id | 需自建等价聚合与告警 |
生产第一性原理：让「能登录面板」与「通道能回头连到你公布出去的 https 主机名」在同一个验收表上同时打勾。
18789）若与你本地 overrides 不一致，请全文搜索配置与 compose，禁止只改反代不改容器监听。allowedOrigins 需覆盖浏览器实际访问的 https 源；修改后按排障文顺序冷启验证，避免缓存误判。下列顺序假设 Docker compose 已在仅本机可达的端口上拉起 Gateway；若尚未完成安装，请先收敛交互向导与 compose 基线文。
冻结主机名：在证书申请前确认 A/AAAA 记录指向当前 VPS，TTL 与运维窗口写清。
确认 Gateway 绑定：宿主机上 ss -lntp 或等价命令核实监听是否仅在 127.0.0.1 目标端口。
选择反代：单机极简优先 Caddy 自动 HTTPS；需要与存量 Nginx 生态拼接时用 Nginx stream/location 模板。
套用最小片段：见下方块；将上游替换为文档端口与真实主机名。
对齐通道回调：IM 或 Webhook 类通道的外部 URL 必须使用同一公网主机名与路径前缀。
记一条 golden path：从「浏览器打开 https 域名」到「触发一次无害心跳或 doctor」写进内部 playbook，便于换班复核。
openclaw.example.com {
encode gzip
reverse_proxy 127.0.0.1:18789
}
server {
listen 443 ssl http2;
server_name openclaw.example.com;
ssl_certificate /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:18789;
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-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 600s;
}
}
把下列表当作值班便签：每一行都应能指向具体日志字段或命令输出，避免「感觉网络有问题」式结论。
| 症状 | 更可疑层次 | 第一动作 |
|---|---|---|
| 仅 https 报错、http 直连上游正常 | 证书链或 SNI | 用可信客户端校验链；核对 server_name 与证书 CN/SAN |
| 页面静态可开、实时通道秒断 | WebSocket 反代超时 | 提高 read timeout；确认 Upgrade 头未被清洗 |
| 控制台报跨源或 blocked origin | allowedOrigins 未含 https 源 | 改写源列表并全量重启相关进程 |
| 外网 curl 502、本机 curl 200 | 反代 upstream 指向旧端口或容器未监听 127.0.0.1 | 对照 compose 与 publish 映射逐跳 traceroute |
注意：在未读完多通道加固清单前，不要把 Dashboard 或调试口临时改成 0.0.0.0 「方便演示」。
下列数字为VPS 单实例常见观察区间，用于估算磁盘与超时，不作为厂商 SLA。
proxy_read_timeout 或 Caddy 等价项建议不低于 600 秒；更短会造成假性断开。df 与 inode。| 角色 | 特征 | 落地建议 |
|---|---|---|
| 个人侧验 | 流量低、可接受短暂维护 | 单 Caddy 节点 + 单 compose 栈 + 手工变更窗口 |
| 小团队生产 | 日间多通道在线 | 镜像钉扎 + 预发布 compose + 反代与 Gateway 分段回滚 |
| 需要接力 Mac / CI | 长任务与签名并存 | Gateway 固定 VPS，构建移交共享 Mac 池，矩阵见前文互链 |
把家用出口或不稳定云机当唯一入口，会叠加动态 IP、端口风控与不可预期休眠；纯自建机房则拉长 TLS 与多地域冗余热备的建设周期，难以给通道方提供可复述的公网入口。
若你需要可持续对外公布 https 入口、并把长心跳 Agent 与 iOS CI 资源池拆开治理，VpsMesh 的 Mac Mini 云端租赁与始终在线 VPS 组合通常是更稳的工程答案：计算与签名负载可落在合同化节点，Gateway 与边缘证书仍由你方按本文 Runbook 收敛，避免「一套机器扛全世界」的隐性单点。