2026 OpenClaw 本番ドメイン：
Caddy または Nginx リバプロ + TLS と Gateway ローカルバインドチェックリスト（Docker VPS）

六つの典型ペイン：localhost の curl が通っても公開ホスト名とは限らない理由

Docker で本番化するときはホスト防火壁、127.0.0.1 の publish だけ、チェーン全体の証明書、HTTPS 切替に追随したチャネルコールバック URLもセットです。以下はオンコール用の一次分類で、細かいフラグは利用中バージョンの公式ドキュメント参照です。

1. 01

   0.0.0.0 筋肉記憶：WAF・レート制限・監査なしで Gateway を公網インターフェースに出すと爆風半径が一気に広がります。

2. 02

   WebSocket 半端：プロキシが Upgrade / Connection を通さずパネルが一瞬 502 やハンドシェイク失敗に見える。

3. 03

   Host と origin のズレ：ブラウザはホスト名 A、設定は IP や内部エイリアスのままで Control UI と API のクロスオリジンガードに引っかかる。

4. 04

   証明書と DNS の順序：DNS 反映前に発行したり自己署名と公開チェーンを混ぜるとモバイルと自動化クライアントで挙動がばらつく。

5. 05

   ディスクとログ：プロキシとコンテナ双方のアクセスログをローテしないと小型 VPS の inode が忙しい週に満杯になりフリーズに見える。

6. 06

   アップグレード窓：イメージ固定なしでプロキシ背後をローリングするとステージングとロールバック順を飛ばした新旧 Gateway の挙動分岐が起きる。

六ステップ Runbook：DNS からプロキシ断片までの複製順

手順は compose が Gateway をループバック専用ポートで既に起動している前提です。インストール未完なら先にウィザードと compose 基線記事を閉じてください。

1. 01

   ホスト名を凍結：証明書発行前に A/AAAA がこの VPS を指すことを確かめ、TTL とメンテ窓を明記。

2. 02

   Gateway バインド確認：ホストで ss -lntp 等を使い待受が 127.0.0.1 の対象ポートのみか検証。

3. 03

   プロキシ選択：単一ノード最小構成なら Caddy 自動 HTTPS。既存 Nginx 資産へは stream/location テンプレで接合。

4. 04

   最小断片適用：下のブロック参照。上流はドキュメントポートと実ホスト名へ差し替え。

5. 05

   チャネルコールバック整合：IM や webhook の外部 URL は同一公網ホスト名とパス接頭辞を使う。

6. 06

   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;
    }
}

定量化ベースラインと規模対応（変更票に記載）

下の数値は単一 VPS でよく見る観測帯で、ディスクとタイムアウト見積り用でありベンダ SLA ではありません。

• プロキシ read タイムアウト：長命セッションと一部チャネルは数分単位。エッジの proxy_read_timeout か Caddy 相当を600 秒以上に。短いと切断に見える擬似障害になる。
• 証明書更新余裕：自動 ACME は期限 ≥14 日前に失敗アラートが来るように。手動更新チームは cron 出力を既存 on-call 経路へ。
• ログ増加：デフォルト info でプロキシ＋コンテナが週数百 MBは小規模チームでも普通。初週は df と inode を実測。

家庭回線や不安定な小規模クラウドだけを入口にすると動的 IP・ポートリスク制御・予期せぬスリープが重なる。純自前 DC だけに振ると TLS と多地域 DR に時間がかかりパートナーへ説明可能な公網入口を出しにくい。

持続可能な公開 https フロントと長寿命エージェントを iOS CI プールから分離したいなら、VpsMesh のクラウド Mac mini レンタルと常時 VPS の組み合わせが現実的な解になりがちです。計算と署名は契約ノードへ、Gateway とエッジ証明書は本 Runbook のまま自前運用でき、「一台が全部」という隠れ SPOF を避けられます。