Linux VPSでOpenClawを常駐させると、障害は多くが「プロセスが戻らない」「localhostでは通るが外向きが死ぬ」「TLS／反代の取り違え」に収束します。当番向けに、L0＝systemdとjournal、L1＝openclaw logs、L2＝ポートとHTTPプローブの順で固定します。本番HTTPSとonboardはGateway本番Runbook、導入curlはLinux VPS実践FAQへ。
段階の決め方（L0→L2）
L0でRestart=やStartLimitIntervalSec、異常終了コードを確定し、journal肥大だけ先に止めます。L1で設定・権限・トークン系の自己完結エラーを拾い、L2で127.0.0.1／VPC IP／ドメインの三経路を分け、bind、UFWやSG、反代upstreamの取り違えを潰します。
L0：systemdとjournalctl
生存と再起動履歴を先に固定します（ユニット名は環境に合わせて読み替え）。
# 状態と直近の終了理由 systemctl status openclaw-gateway.service --no-pager -l # 直近30分の当該ユニットだけを追う journalctl -u openclaw-gateway.service --since "30 min ago" --no-pager
activatingが粘るときはDNS待ちや起動フックを疑い、journalctl先頭で停止点を拾います。
L1：openclaw logs
ユニットが生きていてもアプリ内部の失敗はここに出ます。CLIで直近だけ抜き、journalと二重追跡を避けます。
openclaw logs --tail 200
# 併せて doctor の出力を別端末で固定すると比較が速い
openclaw doctor
L2：ゲートウェイとポート探査
localhostは200で外向きだけ502なら、反代upstreamのポート違いかSNI／Host不一致が典型です。リッスン確定のあと素のHTTPで応答を見ます。
ss -tlnp | head curl -svS http://127.0.0.1:18789/healthz -o /dev/null curl -svS https://gateway.example.com/healthz -o /dev/null
| 症状 | まず疑う層 | 次の一手 |
|---|---|---|
すぐにinactiveへ落ちる |
L0 systemd | journalctlで例外を特定し、EnvironmentFileを確認 |
| 生存しているが外部だけタイムアウト | L2 ポート／SG | ssでbindが127.0.0.1限定かを見てupstreamと整合 |
| TLSは通るがアプリが拒否 | L1 ログ | openclaw logsでトークン失効やWebhook検証エラーを確認 |
クラウドMac miniでは「再現と観測」がさらに速い
Linux側の常駐ゲートウェイを安定させる一方で、クライアント開発やiOSビルドの主戦場はmacOSに置いた方が手戻りが少ない場面も多いです。Xcode・Homebrew・Dockerがネイティブに揃い、Unix系の操作感は本記事のCLI切り分けともそのまま噛み合います。Mac mini M4は待機電力が目安約4Wと低く、静音で長時間ログを追う作業にも向きます。
Apple Siliconの統合メモリとGPU／Neural Engineは、同価格帯の汎用PCよりローカル検証の体感速度で優位になりやすく、macOSの安定性とGatekeeper／SIPによる多層防御は長期運用の安心感につながります。筐体も小さく、デスク占有と冷却ノイズのトータルコストを下げられます。
ゲートウェイはLinux、開発の芯はクラウドMacへ分けるなら、VPSSparkのクラウドMac mini M4はコストパフォーマンスの良い出発点です——プランを今すぐ確認し、観測とビルドを同じリズムで回し始めてください。