2026 クラウド Mac 上の OpenClaw Webhook 取り込みと TLS リバースプロキシ

OpenClaw を GitHub や Stripe、社内チケットに接続する自動化エンジニアは、SaaS ベンダーが HTTPS コールバックを必須にしていることにすぐ気づきます。香港やシンガポールのレンタル Mac mini 上のプレーン HTTP は拒否されます。2026 年の実用的パターンは、リバースプロキシ（Caddy または Nginx）で TLS を終端し、ローカルの OpenClaw リスナーへ転送し、共有シークレットや HMAC ヘッダを検証し、macOS の launchd で証明書更新を自動化することです。本稿ではエッジ構成を比較し、七ステップの Caddy 手順、シークレット運用、失敗モードの表、ゲートウェイが不安定なときのトラブルシュートへのリンクをまとめます。

Webhook の障害は DNS・証明書・ファイアウォール・上流キューが同時に絡みます。変更ごとに「エッジ設定の版」と「OpenClaw ビルド版」の組を残すと、ベンダー配送ログとローカル access_log の突合が速くなります。複数タイムゾーンでオンコールするチームは、プロキシ用とアプリ用の runbook を分けておくと、夜間に Caddy を戻したのに launchd ラベルが食い違う、といったミスを減らせます。

クラウド Mac で Webhook が TLS を要求される理由

パブリック Webhook は信頼できないネットワークを横断します。TLS は URL に埋め込まれたメタデータの機密性を保ち、キャプティブポータル等での単純な MITM リプレイを難しくし、ベンダーのコンプライアンスチェックリストを満たします。MacLogin ノードではスタックは主に自分で管理します。プロバイダは SSH と任意の VNC を提供し、リッスンポートと証明書は利用者の責任です。

ベンダーは TLS 1.2 以上と現代的な暗号スイートを求めるのが一般的です。サーバー間コールバックでは SNI なしの古いクライアントは稀ですが、オンプレのレガシ連携がある場合は例外として文書化してください。

何かを公開する前に、launchd トラブルシューティングガイドで OpenClaw ゲートウェイを安定させてください。プロセスがフラップしていると、原因が Node や plist にあっても最初に疑われるのはリバースプロキシです。

エッジパターン比較：インバウンド 443・トンネル・企業 LB

パターン	選ぶとき	運用コスト	TLS の所有
Mac ホストの公開 443	DNS とインバウンド FW を自分で握る	中——パッチと ACME 更新	自分（Let’s Encrypt ACME）
Cloudflare / ngrok 型トンネル	インバウンド不可	セットアップは低いがトンネル課金のことも	多くはコネクタ側エッジ
企業ロードバランサ	トラフィックがオンプレ DMZ に先に落ちる必要	高——ネットワークチーム調整	社内 PKI またはパブリック CA

OpenClaw 向け Caddy リバースプロキシ：七ステップ

1. リスナーポートを読む：OpenClaw 設定でループバックのアドレスとポートを確認（多くは 127.0.0.1 と環境固有のポート）。
2. Homebrew で Caddy：バージョンはピン留めし、アップグレードは変更窓で。
3. Caddyfile：公開ホスト名、自動 HTTPS、reverse_proxy 127.0.0.1:PORT、Webhook バースト向けフラッシュ間隔。
4. DNS A/AAAA：インスタンスの公開 IP を指す。切替中は TTL を 300 秒に。
5. FW：443/tcp をインターネットまたはトンネルピアのみ。22/tcp は SSH 方針どおりに制限。
6. launchd で Caddy：サービスユーザの LaunchDaemon / Agent。 sudo launchctl bootstrap を検証。
7. ベンダー煙テスト：ドキュメントどおりの署名ヘッダ付きでサンプル POST（例：curl と X-Signature）。OpenClaw ログが LAN 側転送で中央値 200 ms 前後で構造化受理を出すか確認。

Nginx 派なら proxy_pass と certbot フックに一対一で写せます。

高負荷では上流 keepalive プールを調整し、ベンダー再試行のたびに新規 TLS を張らないようにします。出発点としてワーカーあたりアイドル接続 32、アイドル 60 秒、ピーク時の p95 で調整。GitHub や Stripe が 1 秒に 50 イベント送る場合、OpenClaw のキュー深さとプロキシのボディ上限を文書の最大ペイロードに合わせ、413 を避けます。Caddy は request_body、Nginx は client_max_body_size を使います。

プロキシ層に、アプリログとは独立した構造化アクセスログを追加してください。ベンダー配送 ID を両方に載せると、「届いていない」というクレームでエッジが実際には 401（例：16:00 UTC のキーローテーション）を返していたケースをすぐ切り分けられます。

シークレットヘッダ、HMAC、リプレイ許容時間

URL の秘密だけに頼らないでください。Webhook シークレットは macOS キーチェーンかモード 0600 のファイルへ。タイムスタンプのずれはベンダー仕様がなければ 300 秒以内を目安に。四半期ごととエンジニア退職後にローテーション。

OpenClaw が子プロセスを起動するときは、そのワーカーの寿命だけ環境変数でシークレットを渡し、世界読み取り可能なシェル履歴に書かないようにします。署名検証失敗をログに残す場合は期待ダイジェストを伏せ、KMS が出すキーバージョン ID のみを出します。

Webhook 失敗モード表

症状	有力な原因	最初の手当て
エッジが HTTP 502	OpenClaw リスナー停止	ゲートウェイログ確認、launchctl で再起動
TLS ハンドシェイクエラー	期限切れ証明書や SNI 不一致	caddy validate と ACME ログ
200 だがエージェント動作なし	署名不一致	ベンダーダッシュボードのシークレット版を照合
米国 SaaS からだけタイムアウト	APAC ホストへの長い RTT	受信を近づけるか米国 MacLogin リージョンを追加

よくある質問

OpenClaw を 0.0.0.0 にバインドすべき？ 強い理由がなければループバック＋プロキシを推奨。pf のルールがずれたときの誤公開を減らせます。

同じ証明書を SSH に再利用？ 実質的な関連はありません。SSH はホスト鍵、HTTPS は X.509。独立にローテーション。

IPv6 は？ AAAA があるなら Caddy がデュアルスタックで聞いているか、FW も IPv6 に合わせてください。

本番 DNS 前にテストするには？ スプリット DNS か curl --resolve でステージング中の vhost に当て、緑になったら TTL を下げる。

Mac mini M4 on MacLogin が Webhook エッジに向く理由

Webhook はスパイキーです。TLS、JSON、エージェント扇出が同じ秒に重なります。Mac mini M4 のユニファイドメモリは同時 TLS セッションと Node ワーカーをスワップ少なく常駐させやすいです。香港・日本・韓国・シンガポール・米国ホスティングで開発者と主要 SaaS の出口の両方に寄せられます。

Webhook 用ホストと対話的 Xcode 作業を分ければ、証明書ミスがビルドを止めにくくなります。想定 RPS に合わせコアと RAM を 料金ページ で選び、SSH と任意の VNC を ヘルプ に記載し、複数タイムゾーンのオペレータが追えるようにしてください。