ClawTank
所有文章
修復「OpenClaw Send Failed: Gateway Not Connected」錯誤（2026）

修復「OpenClaw Send Failed: Gateway Not Connected」錯誤（2026）

|4 分鐘閱讀

你傳了一則訊息給你的 OpenClaw 助理，結果收到：

send failed: error: gateway not connected

或者你的 Telegram 機器人完全沉默。訊息送出了但永遠不會有回覆。網頁介面顯示一個轉圈圈的載入動畫，永遠不會結束。

這個錯誤代表 OpenClaw 的客戶端（CLI、Telegram 或網頁介面）無法連上 gateway 程序。Gateway 不是已經崩潰、因為網路問題無法連上，就是正在運行但不接受連線。以下是系統性地找出問題並修復的方法。

第一步：檢查 Gateway 狀態

從基本的開始。Gateway 到底有沒有在運行？

openclaw status

健康的輸出：

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

不健康的輸出：

Gateway:    not connected

如果狀態顯示「not connected」，gateway 程序已經停止了。繼續第二步來找出原因。

如果 openclaw status 本身就卡住或逾時，問題可能在系統層面（OpenClaw 二進位檔無法與任何東西通訊）。直接跳到下面的「系統層面問題」章節。

第二步：查看日誌

日誌幾乎總是能揭示 gateway 停止的原因：

# 直接安裝
openclaw logs --tail 100

# Docker
docker logs <container_name> --tail 100

在輸出末尾找錯誤訊息。最常見的模式：

模式 A：OOM Kill

Killed

或在 dmesg 中：

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

系統記憶體耗盡，Linux 的 OOM killer 終止了 gateway 程序。這是低價 VPS 上「gateway not connected」的頭號原因[1]。

修復：

# 檢查目前記憶體
free -h

# 如果沒有 swap，新增一個
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

# 重啟 gateway
openclaw restart

Docker 的情況，設定記憶體限制並保留 swap 空間：

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

模式 B：連接埠已被佔用

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

另一個程序搶走了連接埠，或前一個 gateway 實例沒有正常關閉。

修復：

# 找出什麼在用這個連接埠
lsof -i :3001
# 或
ss -tlnp | grep 3001

# 終止衝突的程序
kill <PID>

# 或更換連接埠
openclaw config set gateway.port 3002
openclaw restart

模式 C：崩潰循環

[gateway] starting...
[gateway] error: <某個錯誤>
[gateway] starting...
[gateway] error: <某個錯誤>

Gateway 正在崩潰並在循環中自動重啟。具體的錯誤訊息會告訴你原因。常見的有：

  • SQLITE_CANTOPEN -- 資料庫檔案權限或磁碟已滿
  • ECONNREFUSED -- gateway 依賴的外部服務停止了
  • SyntaxError in config -- openclaw.json 格式錯誤

設定問題的修復：

# 驗證設定
openclaw config validate

# 如果無效，重設為預設值
openclaw config reset
# 然後重新設定
openclaw config set gateway.mode local

磁碟問題的修復：

# 檢查磁碟空間
df -h

# 檢查資料庫檔案權限
ls -la ~/.openclaw/data/

模式 D：Segfault 或非預期退出

Segmentation fault (core dumped)

或者日誌直接在沒有錯誤訊息的情況下結束。

這很少見，但可能發生在 Node.js 原生模組不相容的情況下，尤其是在 ARM 架構上。

修復：

# 重新安裝 OpenClaw
npm install -g openclaw --force

# 如果在 Docker 中，拉取最新映像檔
docker pull openclaw-stack:latest

第三步：網路和防火牆問題

如果 gateway 正在運行（你可以在程序列表中看到），但客戶端無法連線，問題在網路層面。

檢查 Gateway 是否在監聽

# 確認 gateway 連接埠有開啟
ss -tlnp | grep 3001

# 應該顯示類似：
# LISTEN  0  128  *:3001  *:*  users:(("node",pid=1234,fd=18))

如果什麼都沒顯示，gateway 啟動了但沒有在預期的連接埠上監聽。檢查設定的連接埠：

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）後面運行，port 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」，即使 gateway 本身完全健康。Caddy 的 --adapter caddyfile 旗標很重要——省略它會導致驗證靜默失敗[2]。

WebSocket 連線問題

Gateway 使用 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 連線。

第四步：Docker 專屬問題

容器停止或正在重啟

docker ps -a | grep openclaw

如果狀態顯示「Exited」或「Restarting」：

# 檢查為什麼停止
docker logs <container> --tail 50

# 用自動重啟策略重新啟動
docker run -d --restart=unless-stopped openclaw-stack

Volume 掛載問題

如果資料 volume 沒有正確掛載，gateway 無法存取它的資料庫：

# 確認 volume 掛載
docker inspect <container> | grep -A 5 "Mounts"

Gateway Token 重新產生

在 Docker 中，如果沒有設定 OPENCLAW_GATEWAY_TOKEN，gateway 每次重啟都會產生新的 token。已連線的客戶端仍然持有舊的 token，因此收到「not connected」錯誤[3]。

# 產生一個持久的 token
TOKEN=$(openssl rand -hex 32)

# 設定好後重啟
docker run -d \
  -e OPENCLAW_GATEWAY_TOKEN=$TOKEN \
  --restart=unless-stopped \
  -v openclaw_data:/data \
  openclaw-stack

第五步：完整診斷流程

當你不確定問題出在哪裡時，按照這個順序排查：

# 1. Gateway 程序還活著嗎？
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

監控 Gateway 健康狀態

# 簡單的 cron 監控（每 5 分鐘檢查一次）
*/5 * * * * curl -sf http://localhost:3001/health || openclaw restart

設定資源告警

如果你在 VPS 上，設定基本的監控來在 OOM 事件崩潰 gateway 之前就發現問題：

# 當可用記憶體低於 100MB 時告警
*/5 * * * * [ $(free -m | awk '/Mem:/ {print $7}') -lt 100 ] && echo "Low memory" | mail -s "OpenClaw Alert" you@example.com

當你除錯除到累了

伺服器維護不適合每個人，這完全沒什麼好丟臉的。如果「send failed」錯誤不斷干擾你的工作流程，透過 ClawTank 的託管服務能完全消除整個基礎設施問題的類別。Gateway 運行在有自動重啟、資源監控和正確反向代理設定的受管理容器上。

但如果你偏好自架——而很多人確實有很好的理由這麼做——本指南中的步驟涵蓋了所有已知的「gateway not connected」錯誤原因。把 openclaw doctor 放在你的工具箱裡，先看日誌。答案幾乎總是在那裡。

References

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

準備好部署 OpenClaw 了嗎？

不需要 Docker、SSH、DevOps。不到 1 分鐘即可部署。

免費開始使用