2026年 OpenClaw 複数チャネルゲートウェイの再現トラブルシュート：openclaw doctor、ヘルスプローブと Telegram／Discord 接続失敗——openclaw.json ホットリロード、18789 ポート競合とリモート物理 Mac Runbook（FAQ）
コロケーションやレンタル物理 Mac 上で Telegram と Discord を同時に載せたとき、「片方だけ死ぬ」「ヘルスがフラップする」症状を、設定・ポート・ネットワークのどれかに固定する手順です。openclaw doctor とプローブを軸に、症状→初手の意思決定マトリクス、7 ステップの Runbook、SLO 文書に貼れる数値、FAQ まで一通り揃えています。Compose 側のヘルス設計は リモート Mac の Docker／Compose とヘルスプローブの整理、クライアント側の到達性は Windows／Linux から macOS ゲートウェイへ接続する Runbook と併用すると切り分けが速くなります。
1. 複数チャネルで繰り返す三つの詰まりどころ
1) ホットリロードの境界が曖昧：openclaw.json を書き換えても、Webhook 秘密、TLS 証明書パス、ボットトークンなどが古いプロセスに残り、ファイル上は正しいのにログだけ古いエラーを吐き続けるパターンです。
2) ポート 18789 と二重起動：ローカル診断／管理用 HTTP（本稿では多くの環境で使われる 18789 を例にします。実際のポートは設定に合わせて読み替えてください）が、別の Gateway インスタンス・古い launchd ジョブ・対話シェルからの起動と衝突します。プローブは connection refused と 503 のバーストを交互に踏み、Telegram／Discord 障害に見えてしまいます。
3) チャネル非対称の失敗：Telegram はロングポーリング、Discord は WebSocket と REST が混在しがちです。企業イグレス・システムプロキシ・HTTP(S)_PROXY が、ログインシェルと launchd の非対話環境で食い違うと、「一方だけ常にタイムアウト」という見かけ上の一次障害が起きます。
チャネル設定を書き換える前に、ベンダー推奨ディレクトリと CLI の版が揃っているか確認してください。版のズレは doctor の出力をネットワーク障害と誤読させる最速経路です。
2. 症状→初手の意思決定マトリクス（再起動ループの前に）
openclaw doctor とプローブ結果を下表に当てはめ、「三回再起動してから原因を聞く」を避けます。
| 観測 | 最初にやること | 想定ルート原因バケツ |
|---|---|---|
doctor でローカル HTTP が down、127.0.0.1:18789 への curl が失敗 |
リスナーマップ→古い PID を停止→install-daemon で plist を再適用 | ポート競合／未リッスン |
| 両チャネル赤、doctor のネットワーク系がまとめて失敗 | 非対話シェル相当の環境で DNS・プロキシ・アウトバウンド FW を検証 | イグレス／プロキシ |
| Discord のみ失敗、Telegram は OK | トークン＋インテント→launchd と同一ユーザーで discord.com への TLS／SNI プローブ | 資格情報／権限／API 経路 |
| JSON 変更が「半分だけ」効いている | キーをコールドスタート必須とホットリロード可に分類し、doctor で挙動差分を確認 | リロード対象外フィールド |
3. リモート物理 Mac 向け 7 ステップ Runbook（プレイブックに貼れる）
- ベースライン取得：
openclaw doctorの全文トランスクリプトと Gateway のセマンティックバージョン、openclaw.jsonのハッシュ（例：shasum）を保存し、ロールバック差分を一発で取れるようにする。 - ヘルスプローブの安定化：Readiness URL を 3 秒間隔で最低 10 回。1 回だけ緑でも復旧とはみなさない。launchd の KeepAlive バックオフとも突き合わせる。
- 18789 リッスンマトリクス：
lsof -nP -iTCP:18789 -sTCP:LISTEN（ポートが違う場合は置換）。OpenClaw 関連 PID が複数なら、主インスタンスは 1 つに絞る。 - チャネル別スモーク：Telegram は軽量の getMe 相当、Discord はログ上のシャード／ソケット状態または最小 REST の HEAD。単一の「全体 healthy」フラグの裏に片チャネル失敗を隠さない。
- ホットリロード vs コールドスタート：各 JSON キーをランタイム更新可／再起動必須にタグ付け。後者は SIGHUP 連打より制御された再起動を優先。
- 制御された再起動：
launchctlまたはプロジェクトのinstall-daemonフローで停止→リスナーゼロを確認→起動→構造化ログの先頭 200 行を tail。 - インシデントクローズ：30 分以内に doctor・プローブ・各チャネルで実ユーザーメッセージ 1 通ずつ。チケットにスクショ 3 枚あればクローズ十分です。
launchd・install-daemon・openclaw health の対応関係をさらに深く見る場合は、既存の 7×24 Gateway デーモン向け記事と手順を積み上げ、プローブ間隔と KeepAlive の言い回しを運用ドキュメントで揃えると現場が迷いません。
4. 引用用の閾値とチェックリスト（SLO 文書向け）
- プローブ間隔：ゲートウェイ級 Readiness は 30〜60 秒程度。15 秒未満だと GC スパイクで誤検知しやすい。
- 連続成功ルール：HTTP 2xx を 5 回連続以上確認してから「healthy」と宣言する。
- 回帰ウィンドウ：設定変更後 30 分以内に 両チャネルでエンドツーエンドのメッセージを通す——インシデントクローズの最低ライン。
5. FAQ
openclaw.json を編集したあと、必ず Gateway を再起動すべき？
チャネル資格情報・Webhook・TLS 関連は通常フル再起動が必要です。非リスナー系トグルだけホットリロードされるビルドもありますが、本番では openclaw doctor で確認し、半初期化リスナーを避けるため制御された再起動を推奨します。
ポート 18789 の取り合いは現場でどう見える？
管理／診断 HTTP のバインド失敗や劣化、プローブの connection refusal。lsof で所有者を特定し、古いジョブを止めてポートが空いたら一回だけ立ち上げ直す。
Telegram は動くが Discord だけ——最初に見る三つの設定バケツは？
ボットトークンとインテント、Discord API エンドポイントのプロキシ許可リスト、launchd が使う同一アカウント文脈での discord.com の DNS 解決。curl -I とチャネル別 doctor を組み合わせ、TLS／DNS とアプリ不具合を切り分けます。
6. このゲートウェイ構成に Mac mini／macOS が向く理由
複数チャネルの切り分けは、対話シェルではインターネットに出られるのに launchd ジョブだけプロキシや社内 CA が効かない、といった環境差で崩れやすいです。Apple Silicon 上の macOS は、長時間稼働する Node プロセスのメモリ挙動が読みやすく、ユニファイドメモリで深夜トラフィック時の謎のスパイクを抑えやすい傾向があります。Mac mini M4 の待機電力はおおよそ 4W 前後で、クローゼット／ラックに置く常時接続ゲートウェイに向き、Gatekeeper・SIP・FileVault により、一般的な Windows ユーティリティホストより攻撃面を小さく保ちやすいです。
Telegram と Discord をグローバルユーザー向けに扇状に広げるなら、監査可能でリージョン固定された物理 Mac プールにゲートウェイを載せ、単一リージョンのイグレスドラマや「ノートでは再現するがサーバでは再現しない」議論を減らせます。
静かで熱設計に余裕があり、長期運用の予測可能性が高いハードでこの Runbook を回すなら、コスト対安定性の入口として Mac mini M4 は有力な選択肢です。ZoneMac の物理ノードで macOS 本番相当の観測から doctor とプローブを揃え、今日から運用品質を上げましょう。
OpenClaw ゲートウェイを 24/7 で回す物理 Mac が必要ですか？
ZoneMac ではリージョン選択可能な Mac mini 容量を、常時稼働ゲートウェイ・CI・コンプラ志向の運用向けに提供しています。