#OpenClaw Web Control UI - WebSocket Connection Failed (1006)

1 messages · Page 1 of 1 (latest)

rain plaza Mar 11, 2026, 12:30 PM

Ich sende dir meine Anfrage in mehreren Teilen. Bitte bearbeite sie, wenn alle Teile empfangen sind und ich "DONE" schreibe!

OpenClaw Web Control UI - WebSocket Connection Failed (1006)

ZIEL

OpenClaw Web Control UI soll über Reverse Proxy (Apache) mit Authentik OIDC-Auth funktionieren.
Architektur:

User → Apache (TLS + Authentik OIDC) → OpenClaw Gateway (loopback:60200)

Auth-Mode: token (nicht trusted-proxy)

Gateway-Token in openclaw.json konfiguriert
CLI TUI funktioniert ✅
Web Control UI schlägt fehl ❌

PROBLEM

Symptom

Authentik-Login erfolgreich
Redirect zu /chat?session=main
Control UI lädt kurz
Dann: "disconnected (1006): no reason"

Chrome DevTools

WebSocket connection to 'wss://<domain>/' failed:
connect @ gateway.ts:154

Gateway Log

[ws] closed before connect conn=... remote=127.0.0.1 ... code=1006 reason=connect failed

Keine "unauthorized" oder "pairing required" Fehler!

KONFIGURATION

openclaw.json (Gateway)

{
  "gateway": {
    "port": 60200,
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "<gateway-token>"
    },
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true,
      "dangerouslyDisableDeviceAuth": true
    }
  }
}

olive cobaltBOT Mar 11, 2026, 12:32 PM

Alles klar — ich warte auf die weiteren Teile und bearbeite es erst, wenn du DONE schreibst.

Schick bitte in den nächsten Teilen idealerweise noch:

Apache vHost/Proxy-Konfig (inkl. ProxyPass/ProxyPassReverse, RewriteRule, WebSocket-Handling, relevante Header)
Wie Authentik davor hängt (ForwardAuth/oidc-proxy? welche Headers/Cookies weitergereicht werden)
Control UI URL, die du aufrufst (ohne Token) + ob du #token=... im Fragment nutzt
Gateway-Version (openclaw --version) und ob Control UI direkt auf http://127.0.0.1:60200 lokal funktioniert

Noch kein DONE gesehen — ich warte weiter.

Das letzte “dsds” wirkt wie ein Platzhalter; sobald du soweit bist, poste bitte die fehlenden Teile (vor allem die Apache Reverse-Proxy-Konfig inkl. WebSocket-Upgrade und Authentik-Setup/ForwardAuth/OIDC-Proxy). Ohne die kann man den 1006-Disconnect leider kaum eingrenzen.

rain plaza Mar 11, 2026, 12:36 PM

### Apache VHost
```apache
<VirtualHost *:443>
  ServerName <domain>
  
  # TLS
  SSLEngine on
  
  # Authentik OIDC
  OIDCProviderMetadataURL https://<authentik>/application/o/<slug>/.well-known/openid-configuration
  OIDCClientID <client-id>
  OIDCClientSecret <client-secret>
  OIDCRedirectURI https://<domain>/redirect_uri
  
  # WebSocket Proxy
  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} websocket [NC]
  RewriteCond %{HTTP:Connection} upgrade [NC]
  RewriteRule ^/?(.*) "ws://127.0.0.1:60200/$1" [P,L]
  
  ProxyPass / http://127.0.0.1:60200/
  ProxyPassReverse / http://127.0.0.1:60200/
</VirtualHost>

CLI TUI (funktioniert)

export OPENCLAW_GATEWAY_TOKEN=<gateway-token>
openclaw agent -m "Ping"
# ✅ Works

BEREITS VERSUCHTE MASSNAHMEN

Token in URL: Redirect zu /?token=<gateway-token>
- Web UI lädt aber WebSocket verbindet nicht ❌
Token als Fragment: HTML-Redirect zu /#token=<gateway-token>
- 404 not found ❌
Device Pairing: CLI TUI ist gepaired
- Web UI immer noch disconnected ❌
dangerouslyDisableDeviceAuth: true
- Keine Änderung ❌

BEKANNTES VERHALTEN

CLI TUI: ✅ Funktioniert einwandfrei
Gateway: ✅ Läuft, hört auf 127.0.0.1:60200
WebSocket Proxy: ⚠️ Konfiguriert aber connection failed

OFFENE FRAGEN

WebSocket Token-Übergabe: Wie übergibt Web Control UI das Token an WebSocket?
- CLI: Umgebungsvariable OPENCLAW_GATEWAY_TOKEN
- Web: URL-Fragment? LocalStorage? WebSocket-Header?
Browser-Console: Woher kommt das Token für WebSocket-Verbindung?
Gateway Log: Warum kein "unauthorized" wenn Token fehlt?

SUPPORT-ANFRAGE

Wie muss das Gateway-Token für Web Control UI konfiguriert werden?

CLI nutzt: OPENCLAW_GATEWAY_TOKEN env
Web UI nutzt: ???
Muss das Token:
In der URL sein (#token= oder ?token=)?
In LocalStorage gespeichert sein?
Als WebSocket-Header gesendet werden?
Im Gateway als Cookie konfiguriert sein?
Bitte Dokumentation oder Beispiel-Config für Web Control UI mit Reverse Proxy.

DONE

olive cobaltBOT Mar 11, 2026, 12:40 PM

Hab jetzt auch die Apache-VHost-Config + die “bereits versucht”-Liste — damit kann ich’s sauber auseinandernehmen.

Bevor ich loslege: bitte poste noch kurz

openclaw --version
den exakten WebSocket-Request aus DevTools (Network → WS / Headers), also die komplette URL inkl. Pfad + Query (nicht nur wss://<domain>/)
und dann schreib DONE (erst dann antworte ich mit der Diagnose + Fix-Schritten, wie gewünscht).

Das Gateway-Token wird in der Web Control UI nicht per Cookie/Header “automatisch” übernommen (Authentik/OIDC ist dem Gateway in auth.mode: "token" komplett egal).

Wie die Web UI das Token nutzt (korrektes Modell)

Aus den OpenClaw-Dokus:

Auth passiert beim WebSocket-Handshake über
connect.params.auth.token (bzw. .password)
Die UI lässt dich das Token im Settings-Panel eintragen und speichert es dann im localStorage (persistiert pro Browser-Origin).
Quelle: https://docs.openclaw.ai/web/control-ui , https://docs.openclaw.ai/web/dashboard

Heißt praktisch: UI öffnen → Settings → Token einfügen → Connect.
Kein Cookie, kein spezieller Apache-Header.

Warum du “disconnected (1006)” siehst (sehr wahrscheinlich)

Bei Reverse Proxy ist der Browser-Origin https://<domain> (nicht loopback). Dafür verlangt OpenClaw explizit eine Origin-Allowlist:

Non-loopback Control UI deployments must set gateway.controlUi.allowedOrigins explicitly.

Wenn das fehlt, wird der WS-Connect sehr früh abgewürgt → im Browser oft nur 1006 “no reason”.

Fix in openclaw.json:

{
  "gateway": {
    "port": 60200,
    "bind": "loopback",
    "auth": { "mode": "token", "token": "<gateway-token>" },
    "controlUi": {
      "enabled": true,
      "allowedOrigins": ["https://<domain>"]
    }
  }
}

Danach Gateway neu starten.

Wichtiger Hinweis zur Architektur

Wenn du wirklich willst, dass Authentik/OIDC die einzige Auth ist (ohne Gateway-Token im Browser), dann ist der passende Modus gateway.auth.mode: "trusted-proxy" (mit gateway.trustedProxies + Header-Konfig). Mit token-Mode musst du den Token zusätzlich in der UI hinterlegen.

Docs dazu:

Trusted proxy auth: https://docs.openclaw.ai/gateway/trusted-proxy-auth
Control UI / allowedOrigins: https://docs.openclaw.ai/web/control-ui
Config reference (Gateway/controlUi): https://docs.openclaw.ai/gateway/configuration-reference

Wenn du magst, paste noch openclaw --version + den vollen WS-URL aus DevTools (mit Pfad/Query), dann kann ich dir auch sagen, ob dein Apache-WebSocket-Tunnel die Query sauber durchreicht – aber allowedOrigins ist bei deinem Setup der typische “1006 hinter Reverse Proxy”-Killer.

rain plaza Mar 11, 2026, 12:45 PM

openclaw --version
OpenClaw 2026.3.8 (3caab92)

HEADLESS TEST ERGEBNISSE
Gateway funktioniert lokal!

Auf alfa01 testen:

1. HTTP Endpoint

curl -s http://127.0.0.1:60200/

✅ Status 200 - Control UI HTML wird geladen!

2. Port Listening

ss -tlnp | grep 60200

✅ Gateway hört auf 127.0.0.1:60200

3. CLI TUI

openclaw agent --session-id main -m "Ping"

✅ Works

FAZIT
Component Status
Gateway (local) ✅ OK
HTTP (local) ✅ OK
CLI TUI ✅ OK
WebSocket via Apache ❌ FAILS (1006)

AKTUALISIERTE SUPPORT-FRAGE
Das Problem ist spezifisch der WebSocket Proxy durch Apache!
Die Support-Anfrage oben ist aktualisiert mit:

✅ Headless Test-Ergebnissen
✅ Klarer Eingrenzung: Nur WebSocket Proxy fails
✅ Spezifischer Frage zur Apache WebSocket Config

olive cobaltBOT Mar 11, 2026, 12:49 PM

Danke — 2026.3.8 passt, da sind die relevanten controlUi.* Felder genauso vorhanden.

Wenn du genau so (Browser → Apache → loopback-Gateway) fährst, ist der nächste Schritt ziemlich eindeutig:

1) `allowedOrigins` setzen (sonst fliegt der WS-Connect raus → 1006)

Dein Browser-Origin ist https://<domain>, auch wenn Apache dann zu 127.0.0.1 weiterleitet. Dafür brauchst du eine explizite Allowlist:

{
  "gateway": {
    "port": 60200,
    "bind": "loopback",
    "auth": { "mode": "token", "token": "<gateway-token>" },
    "controlUi": {
      "enabled": true,
      "allowedOrigins": ["https://<domain>"]


      // optional: lass die beiden erstmal weg/false, weil du eh HTTPS machst
      // "allowInsecureAuth": false,
      // "dangerouslyDisableDeviceAuth": false
    }
  }
}

Gateway danach neu starten.

2) Token-Flow in der Web UI (kurz & wichtig)

Bei auth.mode: "token" musst du zusätzlich in der Web UI das Token einmal hinterlegen:

UI → Settings → Token einfügen → Connect
das landet in localStorage und wird dann beim WS-Handshake als connect.params.auth.token geschickt.

OIDC/Authentik ersetzt das nicht (außer du wechselst auf trusted-proxy).

3) Falls es danach immer noch 1006 ist: Apache-WebSocket wirklich verifizieren

In Chrome DevTools → Network → WS:

Erwartet ist HTTP 101 Switching Protocols für den WS-Upgrade.
Wenn du dort 200/302/403 siehst, ist der WS-Tunnel nicht korrekt oder OIDC funkt dazwischen.

Dann poste bitte einmal die komplette WS-URL inkl. Pfad+Query aus DevTools (nicht nur wss://<domain>/) + den Statuscode/Response-Header — damit kann man Apache-seitig sehr zielgenau sagen, ob proxy_wstunnel/Rewrite/QSA etc. passt.

Wenn allowedOrigins das fixt: bitte die Lösung hier im Thread als “Mark Solution” setzen, damit AnswerOverflow es sauber indexen kann.

Deine Headless-Tests sind super hilfreich — und sie zeigen genau das typische Muster bei OpenClaw:

HTTP lädt immer (du bekommst HTML via GET / → 200)
Auth + Origin-Checks passieren beim WebSocket-Handshake
wenn der WS-Handshake abgewürgt wird, sieht der Browser oft nur 1006, obwohl HTTP “geht”

Das heißt: selbst wenn Apache “fast richtig” ist, kann OpenClaw den WS sofort schließen (Origin/Auth) → und dann wirkt es wie ein Proxy-Problem.

A) Erstes “Must-have” für Reverse Proxy: `allowedOrigins`

Wenn der Browser über https://<domain> kommt, ist der Origin Header nicht loopback. Dafür brauchst du:

{
  "gateway": {
    "port": 60200,
    "bind": "loopback",

    "auth": { "mode": "token", "token": "<gateway-token>" },
    "controlUi": {
      "enabled": true,
      "allowedOrigins": ["https://<domain>"]
    }
  }
}

Ohne das kann HTTP 200 OK sein, aber WS fällt (1006) – passt zu deinem Symptom.

Doku: https://docs.openclaw.ai/web/control-ui (Abschnitt allowedOrigins)

B) Apache: “known-good” WebSocket-Tunnel-Config (für OpenClaw)

Deine Rewrite-Idee ist grundsätzlich richtig. Ich würde sie so “härten”:

# Module check: proxy, proxy_http, proxy_wstunnel, rewrite, headers, ssl

<VirtualHost *:443>
  ServerName <domain>
  SSLEngine on

  ProxyPreserveHost On
  RequestHeader set X-Forwarded-Proto "https"
  RequestHeader set X-Forwarded-Port "443"

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteCond %{HTTP:Connection} upgrade [NC]
  RewriteRule ^/(.*)$ ws://127.0.0.1:60200/$1 [P,L,QSA]

  ProxyPass        / http://127.0.0.1:60200/ nocanon retry=0
  ProxyPassReverse / http://127.0.0.1:60200/
</VirtualHost>

Wichtig hier:

proxy_wstunnel muss wirklich geladen sein, sonst wird ws:// nicht sauber getunnelt
QSA stellt sicher, dass die Query (?EIO=...&transport=websocket...) sicher mitkommt
ProxyPreserveHost + X-Forwarded-Proto helfen bei Host/Scheme-abhängigen Checks/Links

C) Wie du sicher erkennst, ob Apache der Übeltäter ist

In Chrome DevTools → Network → WS den Handshake anklicken:

Wenn du nicht 101 Switching Protocols siehst → Apache/OIDC blockt/redirected den Upgrade.
Wenn du 101 siehst, aber es schließt sofort → sehr oft OpenClaw Origin/Auth (also allowedOrigins/Token in UI).