代理上线后三类典型故障（以及常被忽略的连带坑）
第一，来源不一致触发浏览器安全策略。本地 http://127.0.0.1:18789 与线上 https://agents.example.com 不同源；Fetch/EventSource 与 allowedOrigins 逐项比对，缺协议、多斜杠、漏预发名都会假 403。各环境独立维护来源清单并做端到端验收。
第二，WebSocket 升级在代理层被「吃掉」。OpenClaw 控制台与部分通道桥依赖 HTTP/1.1 升级路径。从静态站抄来的反代片段若缺少 proxy_set_header Upgrade $http_upgrade; 与 Connection "upgrade"，会出现握手看似成功、随即被中间层缓冲或错误降级而断开。若同一监听端口强开 HTTP/2 又未给升级留出口，也会表现为「连上闪断」。实操上先用回环直连验证 WebSocket，再对公网域名做对比抓包或 curl -v，能快速判断问题在边缘还是应用。
第三，双重 TLS 或信任链混乱拖垮排障节奏。有人在 Node 内再开 HTTPS，同时 Nginx 也终结证书，容易出现协议或证书链不匹配；也有人做 TLS 透传却未按 SNI 分流，导致 ACME 校验失败。推荐单一故事线：公网客户端只与反向代理谈 TLS，代理到本机用明文回环（除非你在私有网格里刻意做 mTLS）。这样 renew、限速与访问日志都集中在边缘，运维心智负担最低。
威胁模型：为什么生产更推荐「代理在前、网关在环回」
生产应在边缘完成证书续期、TLS 策略、请求体上限与集中访问日志，再让流量进环回网关。Nginx 适合已有栈：map、错误页、限速成熟；Caddy 自动 HTTPS 上手快，仍需实测 WebSocket 与头部透传。
监听限回环；兼容令牌与通道密钥分存；X-Forwarded-For 仅信代理一跳；Webhook 先验签。多环境拆分 server 与 allowedOrigins；日志带统一请求 ID。
选型对比表：Nginx 与 Caddy 谁更划算
| 边缘方案 | 最适合 | WebSocket 体验 | 运维备注 |
|---|---|---|---|
| Nginx + certbot | 已有 Nginx 承载 API 与静态资源 | 需手写 Upgrade；同端口 HTTP/2 要谨慎 | 自行维护 renew 与 nginx -t 流水线 |
| Caddy 自动 HTTPS | 小团队想压低证书与配置 ceremony | 多数场景顺滑；自定义传输层要复测 | 注意默认头行为与 Nginx 习惯差异 |
| 云负载均衡 + Nginx | 多可用区与 LB 健康检查 | LB 空闲超时可能要上调 | 记录「双层超时」的计算方式 |
| Node 直接 TLS | 内网网格 + mTLS | 升级路径原生，但失去统一 WAF 钩子 | 对 Node 加密栈补丁节奏要求更高 |
选定边缘后，按 网关运维指南 的分层顺序演练：回环健康、网关 HTTP、doctor JSON、再测通道。跳过前面几步直接测 Telegram，常在 Nginx 已 502 时浪费数小时。
最小片段：回环上游、WebSocket 头、长读超时
替换主机名与联系邮箱；部署后用 curl -I https://你的域名/health 做一键验收的公网探活。注释留在 Git 里，避免后人「优化超时」把夜间看板静默打断。
# --- Nginx（示意 server 块）---
# proxy_pass http://127.0.0.1:18789;
# proxy_http_version 1.1;
# proxy_set_header Host $host;
# proxy_set_header X-Forwarded-Proto $scheme;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header Upgrade $http_upgrade;
# proxy_set_header Connection "upgrade";
# proxy_read_timeout 3600s;
# proxy_send_timeout 3600s;
# --- Caddy（示意）---
# reverse_proxy 127.0.0.1:18789 {
# header_up X-Forwarded-Proto {scheme}
# header_up X-Forwarded-For {remote_host}
# }
# # 保持 WebSocket 透传；按需调 transport read_timeout
超时、缓冲与可观测性基线
承载交互 WebSocket 或长轮询的路由，建议 proxy_read_timeout 与 proxy_send_timeout 至少 3600 秒；照抄短 REST 默认值会误杀健康会话。纯 HTTP 兼容接口可维持六十到一百二十秒以便快速暴露卡死上游。
请求体上限要与 webhook、媒体拉取策略一致：若加固文将出站媒体抓取限制在二十兆字节量级，入站也应同量级封顶，防止恶意大包在网关解析前就耗尽磁盘。
常见问题、内链汇总与托管远程 Mac 何时更省心
doctor 全绿但浏览器仍 403，先看哪里？
查代理访问日志里返回 403 的路径：若 Nginx 已记一笔，响应多半未触及 OpenClaw；若仅应用日志出现 403，再核对 allowedOrigins 与鉴权头。
OpenAI 兼容路由要不要单独 server_name？
不强制，但许多团队把 /v1 流量拆到独立虚拟主机，以便对兼容 API 设不同限速与 WAF，而不影响运营控制台。
云 FAQ 里的防火墙段落能照搬吗？
作为基线使用，再补上代理 80/443、健康检查源 IP 与供应商 IPv6 范围即可。
小结：代理终结 TLS、显式 WebSocket 头、allowedOrigins 对齐真实来源；分层排障配合 doctor、加固、云 FAQ。
边界：证书、代理与网关版本仍由你维护；若团队更在意 Apple 原生工具链与稳定入口、并希望把 SFTP 投递与长驻网关放在同一运维故事线，托管远程 Mac 常比自建每一跳网络更省时。
SFTPMAC 提供带运维照料的远程 Mac 容量，工程师可专注 OpenClaw 工作流；同一台机器也可承接 SFTP 产物与长驻网关，上行与在线率更可预期。
若希望用托管远程 Mac 统一网关入口与文件投递，可了解 SFTPMAC 方案与线路规格。