2026 OpenClaw Linux VPS ヘッドレス運用：systemd 常駐、リバースプロキシ TLS、ゲートウェイ CLI トリアージラダー

01. 痛み分類：0.0.0.0 バインド、スーパーバイザ無し、プロキシヘッダ不備

1) 全インターフェース待ち受けのデフォルト。ラボ向けクイックスタートは制御面をインターネットに晒してもよい場合がありますが、パブリック VPS では許容しにくいです。127.0.0.1 に Gateway を置き、443 はリバースプロキシだけに任せます。マルチノードと SecretRef の境界は リモート Gateway ガイド に任せ、シェル履歴へ秘密を複製しないでください。

2) 長時間 SSH が運用のふりをする。ノート PC を閉じた瞬間に死ぬプロセスはサービスではなくデモです。systemd は再起動ポリシー、network-online との依存順序、構造化ログを与え、単一 VPS では Kubernetes 税を払わずに済みます。

3) WebSocket を意識しないリバースプロキシ。間欠 502、チャネルがつながるが返信しない、再接続ストームがモデル障害に見える、といった束は proxy_read_timeout の既定が原因であることがあります。エッジを直してから API クレジットを消費してください。

さらに、日本向けクラウドでは帯域課金とセキュリティグループの粒度が運用負荷に直結します。ループバックへ寄せるほど、スキャン雑音と誤アラートが減り、オンデマンドでしか見ないダッシュボードより実務が楽になります。変更管理チケットに「バインド確認」と「プロキシタイムアウト値」を必須フィールドにすると、再発率が下がりやすいです。

チーム開発では、開発者各自のラップトップで動いていた設定がそのまま VPS に持ち込まれることがあります。ローカルでは動いても、ヘッドレス環境では X11 もキーチェーンもないため、認証まわりは SecretRef とファイル権限の設計からやり直す必要があります。その差分を文書化しておくと、新人オンボーディングでも同じ轍を踏みにくくなります。

02. systemd 対 Docker 対 Kubernetes

すでにクラスタ運用が標準化されている組織では、Ingress と cert-manager の上に Gateway を載せるのは自然な拡張です。一方、2 vCPU の安価インスタンスだけを借りている個人は、Helm を噛ませる前にユニットファイル一枚で挙動を固めた方が学習曲線が短いことが多いです。本稿の読者像は後者に寄せています。

03. ファイアウォールとリスナーの基準

開けるのは原則 22、80、443 だけにします（ACME HTTP-01 なら 80 が要ります）。Gateway の管理ポートが ss -lntp の 0.0.0.0 に出てはいけません。デバッグで一時開放するなら送信元 IP 制限か WireGuard で包み、同じチケットで閉じます。

運用では「ファイアウォール」「リスナー一覧」「証明書の残日数」を週次チェックに束ねると抜け漏れが減ります。いずれかだけ緑でも、別軸が劣化しているとインシデントは起きます。分散チームでは結果をチケットに残し、個人メモに閉じない方がバス係数が下がります。

04. 公開 TLS までの 7 ステップ

1. OS を整える：セキュリティ更新、curl・git・ca-certificates、インストールガイド の Node 行列との整合。
2. CLI を入れる：公式スクリプトか単一の npm グローバル。npm・pnpm・手解凍 tarball を同一ユーザーで混ぜないか、混ぜるなら which openclaw の勝者を README に書く。
3. onboard：~/.openclaw/openclaw.json を生成し、キーは Gateway ドキュメント の SecretRef パターンで注入する。
4. ループバック強制：起動後に ss -lntp で確認。WAN 側から見えるのはプロキシだけ。
5. systemd 登録：openclaw gateway install が使えるなら利用。無ければ Restart=on-failure と適切な StartLimitIntervalSec でユニットを書き、クラッシュループでプロバイダを叩かない。
6. Nginx か Caddy：証明書取得、HSTS は意図を持って、長寿命接続向けに read／send タイムアウトを調整。
7. 外向きスモーク：公開ホスト名で curl、チャネルプローブ、チケットにはマスク済みログ要約。

# サービス健全性（ユニット名は版により異なる）
systemctl status openclaw-gateway.service
journalctl -u openclaw-gateway.service -n 200 --no-pager

7 番目は疎通確認として軽視されがちですが、企業プロキシやモバイルキャリアの TLS 検査のせいでローカル curl だけでは再現しない差分が出ます。チェック項目表をリリーステンプレに埋め込むと rollback の根拠も残ります。

05. トリアージラダーとメトリクス

ラダーに従い、インシデント票に貼るのは要約でありフルシークレットではありません。

1. openclaw status
2. openclaw gateway status
3. openclaw logs --follow または journalctl
4. openclaw doctor／openclaw doctor --fix
5. openclaw channels status --probe

コマンド FAQ へ文字列マッチさせると、JSON5 のずれやプラグイン ABI 不一致がネットワーク障害に見えるケースを短時間で切り分けられます。

• メトリクス 1：初週の自ホスト Gateway インシデントのおよそ 28%–41% がリスナーまたはファイアウォール設定に起因し、モデル API ではなかったという内部振り返りがあります。
• メトリクス 2：Gateway を 127.0.0.1 にし 443 のみ外向きにすると、無関係なポートスキャンノイズがプロバイダ背景放射の違いで 60%–85% 減ることがあります。
• メトリクス 3：ログローテーション無しだと、小ディスク VPS の 18%–27% が 7–14 日で journal を満杯にしたというサンプルがありました。サイズ上限か外部転送を設定してください。

数値は SLA ではなくオーダー感です。チャネル数やモデル fan-out、プラグイン数でブレます。しきい値をダッシュボードの初期ラインにし、超えたらまずネットワークとディスクを疑う、という運用が実用的です。

06. ログ、ローテーション、SecretRef の規律

openclaw.json をインフラ as コードとして扱い、プルリクエストとレビュアー、SecretRef 間接参照を徹底し、トークンをチャットに貼らない。ローテーション手順には二重資格情報の重複期間、切替タイムスタンプ、検証プローブを含めます。Docker 中心のチームは Docker ガイド に沿ってイメージパイプラインへ同じ検査を埋め込みます。

大きなアップグレードの前は捨てられるマシンでリハーサルします。手元に Mac が無い場合は短期レンタルで検証してから VPS に昇格させ、手順は 日割り Mac の落とし穴 を参照します。四半期ごとに、ボールトとユニット定義から 1 時間以内に復元できる演習を推奨します。

可観測性の足し算：プロセス生存や最後に成功したチャネルプローブ時刻など、最低限のヘルスを既存スタックへ。cron での合成チェックへの curl でも推測よりましです。Gateway 再起動と OOM を相関させ、小型 VPS では Node ヒープのスパイクに注意し、swap は慎重に。

変更管理：本番 openclaw.json に Git SHA や設定版コメント（形式が許せば）を載せ、オンコールがどのドキュメント版に合わせるか分かるようにする。ロールバック手順として、直前のユニットと npm 版をボールト項目の横にテキストで残す。

07. トレードオフと macOS リハーサルを借りる場合

ノート PC 上の Gateway は PoC には足りますが、スリープや移動体 Wi‑Fi、ダイナミック DNS が可用性の話を壊します。WSL2 や devcontainer は開発に効きますが、主権的なインターネットエンドポイントとしてはぎこちないことが多いです。SSH と標準 TLS と予測可能な請求が欲しいソロ運用者には、Linux VPS と systemd がバランス良いです。

一方で、GUI 重視のデバッグや Safari 特有の挙動、Apple ツールチェーンとの近接性では macOS が依然として楽です。本番に触る前に隔離された場所で壊したいなら、Mac ハードのレンタルが資本リスクを下げつつネイティブツールを保てます。容量は 価格ページ、接続は リモートアクセスガイド を参照し、VPS の横にリハーサル能力を足してください。

最後に、本番とステージングでディレクトリ構造と環境変数名を揃えるほど、人為の取り違えが減ります。対称な足場づくりに少し時間を使う方が、インシデント当日の探索コストを大きく削れます。