2026年 OpenClaw Gateway 同機 Nginx／Caddy リバースプロキシはどう選ぶ？TLS 終端、WebSocket アップグレード、allowedOrigins と trusted-proxy を独占リモート Mac（SSH ヘッドレス）で再現するデプロイメントマトリクス＋FAQ
インターネット側の TLS とブラウザ制約をリバースプロキシに任せ、OpenClaw Gateway はループバックで HTTP のまま束ねる構成が一般的です。本稿では Nginx と Caddy の選定、WebSocket、allowedOrigins、trusted-proxy を SSH だけで再現できる表とチェックリストに落とします。
ゲートウェイ常駐や systemd／launchd の観点は OpenClaw クロスプラットフォーム導入とゲートウェイ自動起動の FAQ と併読すると、同機リバプロを載せたあとの再起動順序まで含めて設計しやすくなります。境界設計の大枠は OpenClaw 安全デプロイ比較（セルフホスト vs クラウド） も参照してください。
1. 同機リバースプロキシで解くべき課題
独占リモート Mac では、(1) 証明書の更新と OCSP、(2) HTTP/2 や HTTP/1.1 の下流互換、(3) 長寿命 WebSocket、(4) ブラウザ拡張や別オリジン UI から来る Origin 検証、(5) レート制限やアクセスログの一元化、をプロキシ層に寄せるのが運用コスト対効果が高いです。OpenClaw 本体は 127.0.0.1 にだけバインドし、外向きポートは 443 のみ開けるパターンが再現性に優れます。
2. Nginx と Caddy の意思決定（要点）
| 観点 | Nginx | Caddy |
|---|---|---|
| TLS 自動更新 | certbot 等と組み合わせて定番。設定は明示的。 | 組み込み ACME が薄くて速い。単一サイト向きに強い。 |
| 設定の可搬性 | 企業内テンプレが豊富。include 分割しやすい。 | Caddyfile が短く読みやすい。小チームに好まれる。 |
| WebSocket | Upgrade／Connection を map で明示する定石。 |
多くのケースで自動透過。例外時だけ header_up。 |
| 細かい制御 | location 粒度、カスタムヘッダ、WAF 連携に強み。 | 十分だが巨大ルールは Nginx 寄りの現場も。 |
ざっくり：社内標準が Nginx なら Nginx。個人／小規模で「まず動かす」なら Caddy。どちらも OpenClaw の upstream は http://127.0.0.1:<gateway-port> に固定し、プロキシだけが 443 を握る形に揃えると切り分けが楽です。
3. TLS 終端と upstream の契約
TLS をプロキシで終端すると、OpenClaw には平文 HTTP で届きます。アプリが HTTPS URL を生成する場合は X-Forwarded-Proto: https と X-Forwarded-Host を必ず付与し、下流の trusted-proxy 設定とセットで有効化します。HSTS はプロキシ側で付与し、開発用ドメインでは短い max-age から始めると巻き戻しが容易です。
3.1 ヘッドレス Mac での運用メモ
- 証明書ストアとプロセスユーザー（_www／caddy 等）の読み取り権限を launchd の
UserNameと揃える。 - 更新後は
nginx -s reloadまたは Caddy の graceful reload を launchd のRunAtLoadとは別に手動検証。 - HTTP/2 下流で詰まる SDK がある場合は upstream を HTTP/1.1 のみに落とす実験を用意する。
4. WebSocket アップグレード
Nginx では map $http_upgrade $connection_upgrade と proxy_set_header Upgrade $http_upgrade; Connection $connection_upgrade; が教科書です。タイムアウトは proxy_read_timeout をチャット用途に合わせて延ばします。Caddy は reverse_proxy が多くのフレームワーク互換パターンを吸収しますが、独自ヘッダを剥がすミドルウェアがあるときは header_up で上書き確認が必要です。
5. allowedOrigins（ブラウザと管理 UI）
ブラウザから別オリジンの管理コンソールや拡張を載せる場合、OpenClaw 側の allowedOrigins（または同等の CORS／Origin ホワイトリスト）に実際の Origin 文字列（スキーム＋ホスト＋ポート）を列挙します。リバプロのホスト名だけ合わせても、開発時の http://localhost:5173 のような値が漏れるとサイレント失敗します。本番はワイルドカードを避け、ステージング用サブドメインを別エントリに分けるのが安全です。
6. trusted-proxy と X-Forwarded-*
レート制限・監査ログ・地理制御で「クライアント IP」を使うなら、プロキシが付ける X-Forwarded-For を OpenClaw が解釈する前提で trusted-proxy（実装名はドキュメント準拠）に127.0.0.1 だけを入れるのが同機構成の基本形です。二段プロキシ（CDN 手前など）にするときだけ、手前の固定 egress を追加し、それ以外のヘッダは信じない方針にします。誤設定すると IP スプーフィングに近い挙動になるため、SSH での設定差分レビューではこのキーを必ず diff 対象にしてください。
7. 再現デプロイメントマトリクス
| シナリオ | TLS | WS | Origin／Proxy |
|---|---|---|---|
| 単一ドメイン・CLI のみ | プロキシ終端＋HSTS 短め | 既定タイムアウトで可 | allowedOrigins 最小／trusted-proxy は 127.0.0.1 |
| ブラウザ UI 併用 | 証明書 SAN に UI ドメイン | read_timeout 延長 | UI の実 Origin を列挙 |
| 社内 VPN 後ろだけ公開 | 社内 CA または mTLS 検討 | VPN MTU 問題を切り分け | VPN 側の固定 IP をログ用に forward |
| 二段 CDN | CDN で TLS、Mac 側はオリジン証明書 | CDN の WS サポート確認 | trusted-proxy に CDN の署名付きヘッダ設計 |
8. FAQ
Q1. WebSocket は 101 になるがすぐ切れる
中間の read_timeout／アイドルタイム、または下流が HTTP/2 だけを期待しているケースを疑います。プロキシと OpenClaw の両方のログ時刻を突き合わせ、Upgrade ヘッダが欠落していないかを確認します。
Q2. allowedOrigins を変えたのに反映されない
プロセス再起動漏れ、環境変数と設定ファイルの二重定義、別インスタンスが別ポートで生きている、の三点をチェックします。launchd の ProgramArguments と実際の ps を突合してください。
Q3. 全員が同じ送信元 IP に見える
trusted-proxy が効いておらずソケット直結の IP が記録されている可能性が高いです。X-Forwarded-For の付与とアプリ側の信頼範囲を同じ変更 PR にまとめます。
9. なぜこの構成は Mac mini／macOS と相性がよいか
443 を常時開けつつローカルで Gateway を束ねる構成は、証明書ファイルの権限、ログローテーション、低遅延のループバック通信が安定していることが重要です。macOS は launchd と統合されたログ周りが扱いやすく、Apple Silicon の Mac mini は待機電力が約 4W 級と言われ、ヘッドレスのリバプロ＋OpenClaw を昼夜回しても電気代と騒音の負担が小さいです。Unix 系ツールチェーンと Homebrew により Nginx／Caddy のどちらも導入パスが短く、SSH だけで設定差分のレビューと再現ドリルが回せます。
セキュリティ面では Gatekeeper や SIP により実行ファイルの改ざん検知がしやすく、プロキシとアプリの境界を運用ルールで守り込みやすいのも利点です。長期運用の総コストでは、静音・省スペース・クラッシュ率の低さを兼ね備えた Mac mini M4 は、専用エッジノードとして現実的な第一選択になります。
TLS と WebSocket、Origin 検証まで一枚岩にしたいチームは、まず一台の信頼できる Mac mini にスタックを集約し、本稿のマトリクスに沿って表をそのまま Runbook に貼るのが最短です。プラン選定は SSHMac の Mac mini ライン から確認できます。