#Health Check

1 messages · Page 1 of 1 (latest)

dull fieldBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

keen micaBOT
#

Ja, klar. Für einen sinnvollen Health Check brauche ich zuerst Version + Diagnose-Ausgaben — bitte keine .env, Tokens oder API Keys posten.

Wenn du Docker Compose nutzt, bitte im Compose-Verzeichnis ausführen:

docker compose run --rm openclaw-cli --version
docker compose ps
curl -fsS http://127.0.0.1:18789/healthz && echo
curl -fsS http://127.0.0.1:18789/readyz && echo
docker compose run --rm openclaw-cli status --all
docker compose run --rm openclaw-cli status --deep
docker compose run --rm openclaw-cli gateway status
docker compose run --rm openclaw-cli doctor
docker compose run --rm openclaw-cli channels status --probe
docker compose logs --tail=200 openclaw-gateway
#

Wichtig für VPS/Container prüfe ich dann besonders:

  • Gateway läuft stabil / Container nicht unhealthy
  • /healthz und /readyz sind ok
  • Auth ist aktiv, falls von außen erreichbar
  • gateway.bind ist sinnvoll für Docker/VPS
  • keine kaputten Channel-/Pairing-/Model-Routen
  • Logs ohne Restart-Loop, OOM, Permission- oder Plugin-Dependency-Fehler
  • Persistenz stimmt: Config/Workspace überleben Container-Neustarts

Docker-Docs: https://docs.openclaw.ai/install/docker
VPS-Docs: https://docs.openclaw.ai/vps
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

desert cedar
#

OpenClaw 2026.4.21
Docker Compose service: openclaw
Container port mapping: 127.0.0.1:45123->45123/tcp
Gateway internal status says: bind=loopback, port=18789
Gateway reachable: yes
Auth mode: token
Telegram: works
Config valid: true
Security audit: 0 critical, 1 warn, 1 info
WARN: gateway.trusted_proxies_missing
Browser control: enabled

Docker außen: 127.0.0.1:45123->45123/tcp
OpenClaw status: Dashboard http://127.0.0.1:18789/
Gateway target: ws://127.0.0.1:18789

Normaler UI-Zugriff erfolgt über SSH-Tunnel:
ssh -L 45123:127.0.0.1:45123 root@SERVER
danach Browser: http://localhost:45123

Traefik läuft auf dem VPS und es gibt redigierte Traefik-Labels für OpenClaw:
traefik.enable=true
entrypoints=websecure
rule=Host(REDACTED-DOMAIN)
tls.certresolver=letsencrypt
loadbalancer.server.port=45123

keen micaBOT
#

Das sieht größtenteils gesund aus: Gateway erreichbar, Token-Auth, Telegram works, Config valid, keine critical Security findings. 👍

Der einzige Punkt, der mich stutzig macht:

Port-/Proxy-Mix:

  • OpenClaw intern: 127.0.0.1:18789
  • Docker außen: 127.0.0.1:45123 -> 45123
  • Traefik: loadbalancer.server.port=45123

Für Traefik ist loadbalancer.server.port normalerweise der Port im Container, nicht der Host-Port. Wenn OpenClaw wirklich im Container nur auf 18789 hört, ist 45123 als Traefik-Ziel verdächtig — außer du hast absichtlich noch einen internen Proxy/Forwarder auf 45123.

Meine Empfehlung:

Wenn du nur per SSH-Tunnel zugreifen willst:
Dann würde ich Traefik für OpenClaw deaktivieren/entfernen. Dein SSH-Tunnel-Setup ist sicherer und die Warnung trusted_proxies_missing ist dann eher kosmetisch.

Wenn du die Domain über Traefik wirklich nutzen willst:

#

Dann sauber machen:

  • Traefik muss auf den tatsächlichen OpenClaw-Container-Port zeigen.
  • OpenClaw muss für den Proxy erreichbar sein, meist gateway.bind: "lan" statt loopback.
  • gateway.trustedProxies auf die konkrete Traefik-IP setzen — nicht ganzes Subnetz.
  • gateway.controlUi.allowedOrigins sollte die HTTPS-Domain enthalten.
  • WebSocket Upgrade muss durch Traefik funktionieren.
  • Token-Auth beibehalten, außer du setzt bewusst trusted-proxy mit Forward Auth auf.

Wichtig: Der Config-Key ist gateway.trustedProxies, nicht trusted_proxies.

Zum Verifizieren wäre der nächste gute Check:

curl -i http://127.0.0.1:45123/healthz
curl -i http://127.0.0.1:45123/readyz
#

Und dann einmal testen: Ist die Traefik-Domain von außen erreichbar? Falls ja: verlangt sie sauber Auth, oder kommst du direkt rein?

desert cedar
#

Local check on VPS:

curl -i http://127.0.0.1:45123/healthz
curl -i http://127.0.0.1:45123/readyz

Both returned HTTP/1.1 200 OK, but with the OpenClaw login HTML page, not a small health/readiness payload.

External check from Windows against the Traefik HTTPS domain:
curl timed out after 10 seconds.

Interpretation:
127.0.0.1:45123 is reachable locally and serves the OpenClaw login UI.
The external Traefik domain does not appear reachable from outside.

keen micaBOT
#

Ja — deine Interpretation passt. Zwei wichtige Schlüsse:

  1. 127.0.0.1:45123 ist nicht der echte Gateway-Health-Endpunkt.
    Wenn /healthz und /readyz HTML/Login-UI zurückgeben, hängt auf 45123 vermutlich die Control UI / ein Frontend-Fallback, nicht der Gateway-Port 18789.

  2. Die Traefik-Domain ist aktuell nicht nutzbar.
    Ein Timeout von außen deutet eher auf DNS/Firewall/Traefik-Entrypoint/Netzwerk hin, nicht auf OpenClaw-Auth.

Ich würde jetzt entscheiden:

Option A — SSH-Tunnel only, empfohlen

Dann ist dein Setup eigentlich gut/sicher. Entferne die Traefik-Labels für OpenClaw, damit keine halbe öffentliche Route existiert. Zugriff bleibt:

ssh -L 45123:127.0.0.1:45123 root@SERVER
#

Die trusted_proxies_missing-Warnung kannst du dann ignorieren bzw. sie verschwindet, wenn keine Proxy-Exposure-Konfiguration mehr aktiv ist.

Option B — Öffentliche Domain über Traefik

Dann ist es noch nicht sauber. Du müsstest prüfen:

docker compose ps
docker compose exec openclaw sh -lc 'ss -ltnp || netstat -ltnp'
docker compose logs --tail=100 traefik

Und dann sicherstellen:

  • Traefik und OpenClaw sind im selben Docker-Netzwerk.
  • traefik.http.services...loadbalancer.server.port zeigt auf den Container-Port, der wirklich OpenClaw/Gateway bedient.
  • Wenn Gateway-Port 18789 ist, ist 45123 als Traefik-Ziel wahrscheinlich falsch.
  • VPS-Firewall/Security Group erlaubt 443/tcp.