OpenClaw 'Send Failed: Gateway Not Connected' エラーの修正方法（2026年）

OpenClaw アシスタントにメッセージを送信すると、以下が返されます：

send failed: error: gateway not connected

または Telegram ボットが無反応になります。メッセージは配信されますが、返答がありません。Web インターフェースでは読み込みインジケーターが回り続けて完了しません。

このエラーは、OpenClaw クライアント（CLI、Telegram、または Web インターフェース）がゲートウェイプロセスに到達できないことを意味します。ゲートウェイがクラッシュしているか、ネットワークの問題で到達不能か、実行中だが接続を受け付けていない状態です。体系的に問題を見つけて修正する方法を説明します。

ステップ 1：ゲートウェイステータスの確認

まず基本から確認します。ゲートウェイは実際に実行されていますか？

openclaw status

正常な出力：

Gateway:    connected (v2.x.x)
Uptime:     3d 14h 22m
Port:       3001
Devices:    2 paired

異常な出力：

Gateway:    not connected

ステータスが "not connected" の場合、ゲートウェイプロセスが停止しています。ステップ 2 に進んで原因を調べてください。

openclaw status 自体がハングまたはタイムアウトする場合、問題はシステムレベルにある可能性があります（OpenClaw バイナリが何とも通信できない状態）。以下の「システムレベルの問題」セクションに進んでください。

ステップ 2：ログの確認

ログはほぼ必ずゲートウェイが停止した理由を明らかにします：

# 直接インストール
openclaw logs --tail 100

# Docker
docker logs <container_name> --tail 100

出力の末尾付近のエラーメッセージを探してください。最も一般的なパターン：

パターン A：OOM キル

Killed

または dmesg 内：

Out of memory: Killed process 1234 (node) total-vm:2048000kB

システムのメモリが不足し、Linux OOM キラーがゲートウェイプロセスを終了しました。これは格安 VPS インスタンスでの「gateway not connected」の最も一般的な原因です^[1]。

修正：

# 現在のメモリを確認
free -h

# スワップが存在しない場合、追加する
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# ゲートウェイを再起動
openclaw restart

Docker の場合、スワップ許容量付きでメモリ制限を設定します：

docker run -d --memory=512m --memory-swap=1g openclaw-stack

パターン B：ポートが既に使用中

Error: listen EADDRINUSE: address already in use :::3001

別のプロセスがポートを取得したか、以前のゲートウェイインスタンスが正しくシャットダウンされませんでした。

修正：

# ポートを使用しているものを確認
lsof -i :3001
# または
ss -tlnp | grep 3001

# 競合するプロセスを終了
kill <PID>

# またはポートを変更
openclaw config set gateway.port 3002
openclaw restart

パターン C：クラッシュループ

[gateway] starting...
[gateway] error: <some error>
[gateway] starting...
[gateway] error: <some error>

ゲートウェイがクラッシュと自動再起動をループしています。具体的なエラーメッセージが原因を教えてくれます。よくあるもの：

• SQLITE_CANTOPEN -- データベースファイルのパーミッションまたはディスクフル
• ECONNREFUSED -- ゲートウェイが依存する外部サービスがダウン
• 設定の SyntaxError -- 不正な openclaw.json

設定の問題の修正：

# 設定を検証
openclaw config validate

# 無効な場合、デフォルトにリセット
openclaw config reset
# その後再設定
openclaw config set gateway.mode local

ディスクの問題の修正：

# ディスク容量を確認
df -h

# データベースファイルのパーミッションを確認
ls -la ~/.openclaw/data/

パターン D：セグフォルトまたは予期しない終了

Segmentation fault (core dumped)

またはログがエラーメッセージなしで単に終了しています。

これはまれですが、特に ARM アーキテクチャでの Node.js ネイティブモジュールの非互換性で発生する可能性があります。

修正：

# OpenClaw を再インストール
npm install -g openclaw --force

# Docker の場合、最新のイメージをプル
docker pull openclaw-stack:latest

ステップ 3：ネットワークとファイアウォールの問題

ゲートウェイが実行中（プロセスリストで確認可能）だが、クライアントが接続できない場合、問題はネットワークレベルにあります。

ゲートウェイがリッスンしているか確認

# ゲートウェイポートが開いているか確認
ss -tlnp | grep 3001

# 以下のようなものが表示されるはず：
# LISTEN  0  128  *:3001  *:*  users:(("node",pid=1234,fd=18))

何も表示されない場合、ゲートウェイは起動したが期待されるポートでリッスンしていません。設定されたポートを確認してください：

openclaw config get gateway.port

ファイアウォールルールの確認

# UFW (Ubuntu)
sudo ufw status

# iptables
sudo iptables -L -n | grep 3001

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-ports

リバースプロキシ（Caddy、Nginx）の背後で実行している場合、ポート 3001 は localhost のみに開放すべきです。ただし、リバースプロキシのポート（80/443）は開いている必要があります：

# UFW の場合
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

リバースプロキシのステータス確認

ドメイン名経由で OpenClaw にアクセスしている場合：

# Caddy
systemctl status caddy
caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile

# Nginx
systemctl status nginx
nginx -t

停止または設定が間違っているリバースプロキシは、ゲートウェイ自体が正常でも「gateway not connected」を引き起こします。Caddy では --adapter caddyfile フラグが重要です。省略すると検証がサイレントに失敗します^[2]。

WebSocket 接続の問題

ゲートウェイは永続的な接続に WebSocket を使用します。一部のリバースプロキシや CDN は WebSocket のアップグレードを適切に処理しません。

症状： 最初のページ読み込みは動作するが、メッセージの送信に失敗します。数秒後に接続が切断されます。

Caddy の修正（通常は自動的に処理されますが、確認してください）：

yourdomain.com {
    reverse_proxy localhost:3001
}

Nginx の修正：

location / {
    proxy_pass http://localhost:3001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400;
}

proxy_read_timeout は重要です。デフォルトの60秒タイムアウトでは、アイドル状態の WebSocket 接続が切断されます。

ステップ 4：Docker 固有の問題

コンテナが停止または再起動中

docker ps -a | grep openclaw

ステータスが "Exited" または "Restarting" の場合：

# 停止理由を確認
docker logs <container> --tail 50

# 自動再起動ポリシー付きで再起動
docker run -d --restart=unless-stopped openclaw-stack

ボリュームマウントの問題

データボリュームが正しくマウントされていない場合、ゲートウェイはデータベースにアクセスできません：

# ボリュームマウントを確認
docker inspect <container> | grep -A 5 "Mounts"

ゲートウェイトークンの再生成

Docker で OPENCLAW_GATEWAY_TOKEN が設定されていない場合、ゲートウェイは再起動のたびに新しいトークンを生成します。接続されたクライアントはまだ古いトークンを保持しており、「not connected」エラーを受け取ります^[3]。

# 永続的なトークンを生成
TOKEN=$(openssl rand -hex 32)

# トークンを設定して再起動
docker run -d \
  -e OPENCLAW_GATEWAY_TOKEN=$TOKEN \
  --restart=unless-stopped \
  -v openclaw_data:/data \
  openclaw-stack

ステップ 5：完全な診断シーケンス

問題の場所がわからない場合、このシーケンスを実行してください：

# 1. ゲートウェイプロセスは生きているか？
openclaw status

# 2. ログは何を示しているか？
openclaw logs --tail 100

# 3. 自動診断を実行
openclaw doctor

# 4. ポートは開いているか？
ss -tlnp | grep 3001

# 5. ローカルで到達できるか？
curl -s http://localhost:3001/health

# 6. リバースプロキシは動作しているか？
curl -s https://yourdomain.com/health

# 7. システムリソースを確認
free -h && df -h

# 8. OOM イベントを確認
dmesg | tail -20

答えはほぼ必ずステップ 2（ログ）またはステップ 7（リソース）で見つかります。

今後の「Send Failed」エラーの予防

自動再起動のセットアップ

# systemd の場合
openclaw service install
systemctl enable openclaw

# Docker の場合
docker run -d --restart=unless-stopped openclaw-stack

# PM2 の場合
pm2 start openclaw -- start
pm2 save
pm2 startup

ゲートウェイの健全性監視

# シンプルな cron ベースの監視（5分ごとにチェック）
*/5 * * * * curl -sf http://localhost:3001/health || openclaw restart

リソースアラートの設定

VPS を使用している場合、OOM イベントがゲートウェイをクラッシュさせる前にキャッチするための基本的な監視を設定してください：

# 空きメモリが 100MB 以下になった場合にアラート
*/5 * * * * [ $(free -m | awk '/Mem:/ {print $7}') -lt 100 ] && echo "Low memory" | mail -s "OpenClaw Alert" you@example.com

デバッグに疲れたら

サーバーメンテナンスは万人向けではありません。「send failed」エラーがワークフローを妨げ続ける場合、ClawTank でのマネージドホスティングは、インフラ問題のカテゴリ全体を排除します。ゲートウェイはマネージドコンテナ上で自動再起動、リソース監視、適切なリバースプロキシ設定が済んだ状態で実行されます。

ただし、セルフホスティングを好む場合（そして多くの人が素晴らしい理由でそうしています）、このガイドの手順は「gateway not connected」エラーのすべての既知の原因をカバーしています。openclaw doctor をツールキットに入れて、まずログを確認してください。答えはほぼ必ずそこにあります。

参考資料

1. Linux OOM Killer Explained
2. Caddy Reverse Proxy Configuration
3. OpenClaw Docker Environment Variables
4. OpenClaw CLI Reference -- status and doctor