Cloudflare Tunnel＋反向代理：收斂外網入口的骨架
2026 年實務上建議TLS 在 Cloudflare 終止、源站只暴露 loopback：在遠端 Mac 安裝 cloudflared，以私網驗證綁定本機反向代理（Nginx／Caddy）再轉到 OpenClaw Gateway；公開 DNS 僅指向 Tunnel，避免把機房公網 443 直接掛服務。日韓港新與美西的操作相同，差在骨幹與 RTT：日韓利於東北亞回源；港新利於亞太互聯；美西貼近北美雲與多數 SaaS API。若你已用叢集收斂過 Gateway，可對照
K8s 與反向代理下的 Gateway 暴露面與健康檢查，把同一套路徑映射到單機 Tunnel。
日韓港新美西：建議部署順序
①子域與路由表預排 → ② Cloudflare 建立 Tunnel、下發 token → ③ cloudflared 以 launchd 常駐並寫明日誌路徑 → ④ 反代只聽 127.0.0.1，區分 /webhook 與 Gateway 路徑，開啟 WebSocket／HTTP2 升級與合理 proxy_read_timeout → ⑤ 從該區邊緣 VPS對外公網域名跑 curl -vI 驗證 SNI 與首包。需要多活時每區獨立 Tunnel，再用加權或故障轉移，但後端狀態仍應區域隔離。
Webhook 與 Gateway：連通性排錯鏈路
先判層級：DNS 是否只指 Tunnel；憑證鏈是否完整；反代是否轉發 X-Forwarded-Proto/For 以免 Gateway 誤判內網來源。Webhook 常見為 413／超時：檢反代 body 上限與上游讀取逾時；Gateway 若報連線重設，多半是上游埠漂移或本機防火牆阻擋 loopback 轉發。建議在 Mac 上同序跑：cloudflared 日誌 → 反代 access log → OpenClaw Gateway 日誌，三邊對齊時間戳。節點若還要鎖 Xcode／SDK 小版本，可延伸閱讀
遠端 Mac 建置基線與 SDK 一致性，避免「網路通了、建置卻漂」。
M4 16GB／24GB 與 M4 Pro：併發承載對照（示意）
以下為單機同時承載 OpenClaw Gateway、輕量索引與常駐 Webhook 的經驗檔位，實際仍受模型大小、外掛數與磁碟 I/O 影響；數字代表「舒適併發區間」，非硬上限。
| 檔位 | 典型 Gateway 連線 | Webhook＋輕任務 | 備註 |
|---|---|---|---|
| M4 · 16GB | 1–2 條穩定長連 | 低頻事件為主 | 易因索引／快取與 GUI 同機爭用記憶體頻寬，建議嚴格佇列 |
| M4 · 24GB | 2–3 條 | 中頻＋少量並行工具呼叫 | 較能容錯背景同步與日誌爆量，仍須限制外掛熱載入 |
| M4 Pro | 3–5 條 | 中高頻 Webhook＋多代理 | 更高記憶體頻寬與 GPU／ANE 餘裕，適合 7×24 與多通道並行 |
上線前核對清單
- 邊界：公網僅 Tunnel；管理面走 VPN 或 SSH 跳板。
- 逾時與重試：反代、Tunnel、Gateway 三層逾時遞增，避免短逾時造成重試風暴。
- 觀測：統一時區與日誌格式，尖峰時段各區各跑一次端到端探測。
常見問題
curl 直打 loopback 對照經 Tunnel 的路徑。在 Mac mini 上，把外網入口跑得更省心的理由
Tunnel 與反代把暴露面縮小了，但7×24 穩定與低維護仍取決於硬體與系統：macOS 提供原生 Unix 工具鏈與 Gatekeeper、SIP、FileVault 等多層防護，長期掛服務時整體崩潰率低於一般桌面環境；Apple Silicon M 系列在能效上遠勝同價位傳統 PC，Mac mini M4 待機功耗可低至約 4W，卻能支撐多代理、Webhook 與本機輔助推論對記憶體頻寬的需求。對需要日韓港新美西多節點的團隊，把每台遠端 Mac 當成邊緣閘道＋建置節點一體機，總擁有成本往往優於分散的 NUC＋Linux 組合。
若你希望 OpenClaw 這類堆疊在靜音、省電、可長時運行的前提下仍保留升級餘裕，Mac mini M4 會是 2026 年極具性價比的落點——現在就入手，讓 Tunnel、反代與 Gateway 在同一套生態裡順暢銜接。