Webhook 経路：上流 → 署名 → Gateway
生ボディへ署名し OpenClaw で検証してから Gateway へ渡します。リバプロがボディを触ると不一致になります。受信ログと検証前 4xx を分けます。
署名検証の切り分け
GitHub と GitLab
X-Hub-Signature-256 と X-Gitlab-Token を混同しないこと。片系だけ秘密更新で 401 が続きます。配信履歴と Mac 時刻で重複も確認します。
注意
プロキシでの gzip 展開や JSON 整形は署名を壊します。透過転送にし、調整するのは読み取りタイムアウトに限定してください。
Gateway のタイムアウトと 502／504
重い連携ではクライアントはタイムアウト・サーバは継続の非対称が出ます。read timeout と再送間隔を揃え、長処理は即 202。詳しくは：Gateway 疎通とパス切り分け
再試行と冪等
再送は前提なので Delivery ID 等で冪等にします。短時間キャッシュで二重ワーカーにも耐え、五拠点は NTP と TZ を揃えます。
五リージョン × メモリ帯の目安
五リージョンでは出口と RTT の差でタイムアウト率が変わります。軽量受信のバースト目安です。
| 構成 | 軽量同時 | 常駐＋CI |
|---|---|---|
| 16GB（M4） | 4〜6 | 1〜2 |
| 24GB（M4） | 6〜10 | 2〜3 |
| M4 Pro＋大容量 SSD | 10〜16 | 本番軸 |
チェックリスト
- 署名：秘密・ヘッダ名・生ボディをマスク付きで突合。
- タイムアウト：上流再送より長く取りすぎない。長処理は非同期。
- 冪等：Delivery ID で重複排除。
よくある質問
200 なのに二重実行される
上流が応答遅れで再送しています。TTFB と冪等キーを見直し、米西のみ失敗が多いときは read timeout と TLS p95 を確認してください。
macOS と Mac mini で運用しやすい理由
常駐 Gateway には安定した OSと統合メモリが効きます。Gatekeeper／SIP で無人運用の改ざん耐性が高く、Mac mini M4 はアイドル約 4W・静音で待受に向きます。
署名・タイムアウト・再試行はログと再現性が勝ちます。本番相当の安定性を固めるなら、Mac mini M4 にワークスペースと Gateway を集約するのが手早く、今すぐ導入を検討する価値があります。