2026 OpenClaw Docker Compose: Konnektivität & Pairing – 1006 vs 1008, eine Tokenquelle, Unix‑Sockets & gemeinsame Namespaces

Fünf „wie Netzwerk“-Ursachen bei Compose‑Trennung

1. Fest eingetragene 127.0.0.1: Loopback meint nur den aktuellen Container; Compose‑DNS verwenden (z. B. http://openclaw-gateway:18789).
2. Doppelte Tokenquellen drift: OPENCLAW_GATEWAY_TOKEN kann Dateikonfiguration überschreiben — wirkt dann wie sporadisches 401/1008‑Flippen.
3. Unix‑Socket nicht gemeinsam gemountet: liegt gateway.sock vor, brauchen beide Seiten denselben Host‑Pfad und passende UID/GID.
4. 1006 als „zuckend“ missverstehen: 1006 markiert meist abnormes Schließen (Crash, Timeout, Proxy‑Retry) — Gateway‑Restarts vor Pairing‑Knopf drehen.
5. Loopback‑Parität ohne Architekturentscheid: ggf. network_mode: service:<gateway> dokumentieren oder konsequent TCP per DNS — keine hybriden Env‑Boluses pro Ticket.

Alle fünf müssen erledigt sein, bevor Image‑Tags gekippt werden; Namespace-/Token-Verträge first.

Bei geschlossenen Sockets Zeitstempel von Gateway‑stderr, CLI‑stdout und docker events zusammenlegen — häufig passen „random“‑Ausfälle zu Restarts oder zu aggressiven Healthchecks.

Sechs Schritte – Erreichbarkeit vor Pairing‑Jubel

1. Eine gültige Tokenquelle definieren: Datei oder Env (xor), per docker compose config nachweisen.
2. URL‑Semantik einfrieren: entweder DNS‑TCP Ende‑zu‑Ende oder ein konsistenter Unix‑Socket mit einem Bind.
3. .openclaw gleich eingebunden: beschreibbare gleiche Baum — sonst wirkt pairing „wie Schritt 0“ eingefroren (Volumencheckliste).
4. openclaw gateway status, dann doctor: Zeitstempel Host vs. Inner‑Logs angleichen.
5. Loopback‑Parität wirklich gefordert: network_mode: service:<gateway> im Review dokumentieren — konsistent zu trustedProxies‑Playbooks.
6. Evidenzpaket beim Schließen: Probescreenshot im gleichen Namespace + kurzer URL/Token‑Hash — „curl auf Laptop“ reicht nicht.

Steht Nginx oder Caddy vor dem Gateway, verknüpfen Sie Upgrade‑ und Idle‑Timeouts mit der Compose‑URL (Reverse‑Proxy‑Leitfaden), sonst mischt sporadisches 1006 mit Auth‑Bugs.

# Namen/Volumes anpassen, dann docker compose config prüfen
services:
  openclaw-gateway:
    environment:
      - OPENCLAW_CONFIG_DIR=/data/.openclaw
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
    volumes:
      - oc-data:/data/.openclaw
    networks: [oc-net]

  openclaw-cli:
    environment:
      - OPENCLAW_CONFIG_DIR=/data/.openclaw
      - OPENCLAW_GATEWAY_URL=http://openclaw-gateway:18789
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
    volumes:
      - oc-data:/data/.openclaw
    networks: [oc-net]
    depends_on:
      - openclaw-gateway

networks:
  oc-net:
    driver: bridge

volumes:
  oc-data:

Ingenieur‑Fakten fürs Change‑Ticket

• Probes im fehlerhaften Namespace — sonst ein Schrödinger‑Gateway.
• Kurze Fingerprints für beide Tokenoberflächen vor Release‑Tag.
• Liveness‑Stürme erhöhen 1006, bevor Pairing‑Policy hilft.
• Zerstreute Commands außerhalb des kaputten Images zählen nicht als RCA.

Weshalb Laptop‑„Wegwerf“-Stacks selten Produktionsketten sind

OpenClaw braucht planbare Restarts, Festplattengrundlinien und auditierbare Pairing‑Historie. Auf einem eigenständigen Fern‑Mac mit sechs Regionen und Monats-/Quartalskalkulation passt das eher zur CI‑Geheimnisrotation als zu schlummernden PCs. Öffentliche Seiten: Mac‑mini‑Mietpreise · Hilfe & FAQ; Variablen anschließend aus diesem Runbook spiegeln.

Fazit: Vertrag vor Heldentum

Compose‑Fälle kleben meist an Namespace + Token + Zustandsverzeichnis. Ohne wiederholbare Handshake‑Aufzeichnung aus dem gleichen Container: keine Image‑Panic, kein Blind‑„TLS‑aus“. Sobald Kontrakte stabil: GHCR + Control UI und gehärtete Proxies.