HTTPS を有効にした直後に表面化する三つの失敗モード
第一に、オリジン不一致。 http://127.0.0.1:18789 と https://agents.example.com は別物。Fetch／EventSource は allowedOrigins と厳密比較し、スキーム欠落や末尾スラッシュで 403 になりがち。
第二に、Upgrade 欠落。 proxy_set_header Upgrade と Connection "upgrade" を忘れると WebSocket が即切断。HTTP/2 同一ポートでは経路に注意。
第三に、TLS 二重終端。 Nginx と Node の両方で HTTPS にしない。公開→プロキシで TLS、裏はループバック HTTP が扱いやすい。
脅威モデル：本番で OpenClaw の前にリバースプロキシを置く理由
本番はエッジで ACME・TLS 方針・リクエスト上限 と集中ログを処理し、ループバックへ渡す。Nginx は既存運用向け、Caddy は自動 HTTPS 向け。WebSocket は実測必須。
待受はループバック優先。互換トークンとチャネル秘密は分離。X-Forwarded-For は直前プロキシのみ信頼。Webhook は先に認証。環境別 allowedOrigins と共通リクエスト ID。
判断マトリクス：OpenClaw ゲートウェイ向けに Nginx と Caddy をどう選ぶか
| エッジ | 向いている場合 | WebSocket の扱い | 運用上の注意 |
|---|---|---|---|
| Nginx ＋ certbot | 既に nginx で API と静的配信を運用している | Upgrade を明示。同一ポートの http2 に注意 | 更新フックと設定テストは自前で管理 |
| Caddy 自動 HTTPS | TLS の儀式を最小化したい小チーム | 概ね素直。カスタム transport は実測で確認 | Nginx 時代のヘッダー前提と差分確認 |
| クラウド LB ＋ nginx | ヘルスチェック付きマルチ AZ | LB のアイドルタイムアウトを WebSocket 向けに延ばす | 二段のタイムアウトを数式で文書化 |
| Node 直接 TLS | mTLS 前提の厳密な内部メッシュ | Node が素直に Upgrade 処理。WAF フックは失われやすい | Node 暗号スタックのパッチ運用が重くなる |
最小断片：ループバック上流、WebSocket 用ヘッダー、長い読み取り
ホスト名を差し替え、公開後 curl -I https://例/health で確認。例示はコメントのみです。
# --- Nginx（例示 server ブロック）---
# proxy_pass to 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 API 向けの短い既定値のままだと、健全なセッションまで切られます。HTTP のみの互換エンドポイントでは、詰まった上流を早く失敗させるため 60〜120 秒に留める、という切り分けも有効です。
ボディサイズ上限は、受け入れる Webhook やメディアの最大ペイロードに合わせます。強化記事で外向き取得を 20MB 前後に抑えるなら、インバウンドも同オーダーに揃え、ギガバイト級 POST でディスクを枯らされる前にエッジで落とせるようにします。
FAQ、相互リンク、ホスト型リモート Mac が効く場面
doctor は緑なのにブラウザだけ 403 になる場合、最初にどこを見ますか？
403 を返したパスについてプロキシのアクセスログを確認します。nginx に記録があるなら OpenClaw は応答していません。アプリログにだけ 403 があるなら、allowedOrigins と認証ヘッダを再確認します。
OpenAI 互換ルート用にサーバ名を分ける必要はありますか？
必須ではありませんが、多くのチームは /v1 互換トラフィックを別バーチャルホストに分け、オペレータ向けダッシュボードに触れずにレート制限と WAF だけを調整します。
クラウド FAQ のファイアウォール節をそのまま流用してよいですか？
ベースラインとして使い、プロキシの 80／443、ヘルスチェック送信元 IP、プロバイダが公開する IPv6 レンジを追記します。詳細は クラウドデプロイ FAQ を参照してください。
まとめ： プロキシで TLS 終端、Upgrade 明示、allowedOrigins 整合、層別切り分け。
限界： 証明書とプロキシは自前。管理リモート Mac でイングレスと運用負荷を下げる選択もあります。
SFTPMAC の リモート Mac で接続保守とゲートウェイ／SFTP をまとめられます。
ゲートウェイとファイル配送のイングレスを、管理されたリモート Mac ノードでまとめたい場合は、SFTPMAC のプランをご覧ください。