# bridge.ki1.it — Neuer Bridge-Server, 4 PWA-Bridges + einheitliche /ask-API

**Datum:** 2026-07-22 · **Host:** bridge.ki1.it (Hetzner cx33, 204.168.156.114, Tailscale 100.81.245.44)
**Ergebnis:** Docker-Container `bridges-ki1` healthy, reboot-fest. 2/4 Bridges live mit echter
Generierung verifiziert (Mammouth, Gemini), 1/4 Bridge technisch funktionsfaehig aber
Ziel-Dienst selbst lehnt Generierung ab (Suno), 1/4 braucht einmaligen Baer-Login (Qolaba).

---

## Architektur

- Eigener neuer Server (NICHT go2ki/keys-bridges auf 100.125.242.12 — der bleibt unangetastet,
  laeuft weiter parallel).
- Docker-Container `bridges-ki1`: FastAPI (Port 4003) + noVNC (Port 4004, nur ueber
  Tailscale-IP 100.81.245.44 erreichbar) via supervisord, Xvfb+fluxbox fuer headful Browser.
- 2 Chromium-Bridges (Gemini, Qolaba) mit eigenem persistentem Profil unter `/profiles/<name>`.
- 1 Firefox-Bridge (Mammouth) mit eigenem persistentem Profil + SOCKS5-Proxy zu gpu-pc
  (gleiche Egress-IP wie die migrierten Cookies, wichtig wegen Cloudflare `cf_clearance`).
- 1 CDP-Tunnel-Bridge (Suno): kein eigenes Profil, verbindet sich per CDP zu einem bereits
  laufenden, eingeloggten Chrome auf gpu-pc (Port 9223, per SSH-Tunnel zu bridge.ki1.it
  weitergereicht) — identisches Prinzip wie go2ki.
- Reboot-Persistenz: `docker restart=always` + Docker-Systemdienst enabled + 2 systemd-Units
  fuer die SSH-Tunnel zu gpu-pc (`gpupc-socks-tunnel.service`, `suno-pwa-cdp-tunnel.service`,
  beide `enabled` + `active`).

## Einheitliche /ask-API (fuer den MCP-Hub)

```
POST http://204.168.156.114:4003/ask/<dienst>      dienst = suno|qolaba|mammouth|gemini
Header: X-Bridge-Key: <BRIDGE_API_KEY aus /opt/bridges/.env>  (oder Authorization: Bearer <key>)
Body:   {"prompt": "...", "mode"?: "...", "negative"?: "...", "timeout"?: int}

Sync-Antwort  (mammouth chat, gemini chat, qolaba chat):
  {"ok": true, "result": "<text>"}
  {"ok": false, "error": "<msg>"}

Async-Antwort (suno, qolaba image/audio/music/video, gemini image/veo3):
  {"ok": null, "job_id": "...", "status_url": "/ask/status/<job_id>"}

GET /ask/status/<job_id>
  {"job_id":"...", "status": "queued|running|generating|ok|ok_partial|failed|timeout_240s",
   "ok": true|false|null, "result": "<text|url|pfad>"?, "error"?}
```

Auch alle bisherigen nativen Endpoints aus go2ki 1:1 uebernommen (`/mammouth/chat`,
`/gemini/chat`, `/gemini/image`, `/qolaba/chat|image|audio|music|video`, `/suno/generate`
+ `/suno/status/<id>`).

Neu (Debug/Ops, nicht im go2ki-Original):
```
GET  /debug/state/<bridge>       -- Page-URL/Titel/readyState + Fehlerdetails
GET  /debug/screenshot/<bridge>  -- PNG-Screenshot der aktuellen Page
POST /debug/reset/<bridge>       -- schliesst alle Pages, oeffnet frische (Notfall-Reparatur)
```

## Status je Dienst (verifiziert per echtem Testcall, nicht nur `logged_in`-Flag —
## siehe Merksatz im go2ki-Doc oben: das allein ist KEIN Beweis)

| Dienst | Login | Testcall | Ergebnis |
|---|---|---|---|
| Mammouth | ok | `/ask/mammouth` "7×8?" | echte korrekte Antwort, Abo aktiv bestaetigt |
| Gemini | ok | `/ask/gemini` "Hauptstadt Portugal?" | echte korrekte Antwort |
| Suno | ok (CDP, Konto `mkulm`, 10.410 Credits sichtbar) | 2× `/ask/suno` Songgenerierung | Feld gefuellt + Create-Button geklickt (per Screenshot bewiesen), **Suno selbst** meldet beide Male "Generation failed — Something went wrong. Please try again." — kein Bug auf unserer Seite, Suno-seitiges Problem (Ursache offen, evtl. Bot-Erkennung auf Automations-Traffic oder temporaeres Suno-Problem) |
| Qolaba | **logged_in: false** | Screenshot | echte anonyme Shell (Sign Up/Login-Buttons sichtbar, kein UI-Flacker-Fehlalarm). Migrierte Cookies waren vom 21. Juni — ueber 1 Monat abgelaufen. Passwort-Auto-Login im Code bewusst deaktiviert (Login-Selektoren der echten Seite nie verifiziert) |

**Offene Punkte / Blocker:**
- Qolaba braucht einmaligen Baer-Login (E-Mail/PW s. `reference-bridge-logins.md`,
  `matthias@consoro.eu` / `KeinPlan0815!`) auf `https://www.qolaba.ai/chat` — am einfachsten
  per VNC (`100.81.245.44:4004`, kein Passwort) oder Passwort-Selektoren fuer Auto-Relogin
  nachruesten sobald einmal ein echter Login live beobachtet werden konnte.
- Suno-Generierungsfehler noch nicht final geklaert — moeglich, dass ein manueller Test
  direkt auf gpu-pc (ausserhalb des Bridge-Containers, gleiche eingeloggte Session) zeigt,
  ob es ein Konto-/Sperrenproblem oder ein automatisierungsspezifisches Problem ist.

## 3 echte Bugs gefunden + gefixt

**1. Suno-CDP-Verbindung tot: Chrome lehnt benannten Host-Header ab**
Symptom: `BrowserType.connect_over_cdp: Unexpected status 500 ... "Host header is specified
and is not an IP address or localhost."` Chromes Remote-Debugging-Server hat einen
DNS-Rebinding-Schutz, der HTTP-Requests mit einem **Hostnamen** (statt IP-Literal) im
Host-Header ablehnt — `host.docker.internal` ist ein Name, keine IP.
Fix (`suno.py`): Hostname vor dem `connect_over_cdp()` per `socket.gethostbyname()` zur IP
aufloesen.

**2. Mammouth (Firefox) komplett kaputt — echter patchright-Bug**
Symptom: JEDE Interaktion (`page.evaluate()`, `query_selector()`, ...) schlug fehl mit
`Cannot read properties of undefined (reading '_client')`. Reproduziert sogar mit einem
minimalen Isolations-Script OHNE App-Code, Proxy oder Cookies — nur `example.com` mit
`patchright.firefox`. Root Cause: **reproduzierbarer Bug in patchright 1.61.2 im
Firefox-Pfad** (isoliert verifiziert: identisches Script mit vanilla `playwright==1.49`
funktioniert einwandfrei — `TITLE_OK: Example Domain`, `EVAL_OK: complete`).
Fix (`base.py`): zwei Treiber parallel — **patchright** bleibt fuer Chromium-Bridges
(Gemini, Qolaba — dort ist der CDP-`Runtime.enable`-Leak-Patch der eigentliche Sinn von
patchright), **vanilla `playwright`** fuer die Firefox-Bridge (Mammouth — braucht den Patch
ohnehin nicht, Firefox hat den CDP-Leak nicht). Dockerfile installiert beide Pakete in
EINEM `pip install`-Aufruf (sonst Versionskonflikt bei `pyee`: patchright>=1.61 will
`pyee>=13`, playwright==1.49 zieht sonst `pyee<13` nach und der zweite Install ueberschreibt
den ersten).

**3. `host.docker.internal` als Proxy-Hostname (generischer Fix, waehrend Bug-2-Debugging
entdeckt, aber NICHT dessen Root Cause)**
Generischer Helper `_resolve_hostname_in_url()` in `base.py`, loest `host.docker.internal`
in JEDER Proxy-Config zur IP auf — Absicherung fuer alle aktuellen und kuenftigen Bridges,
die einen Proxy nutzen.

## Debugging-Lektion: Firefox-Fensterzustand pruefen ohne VNC

`docker exec bridges-ki1 sh -c "DISPLAY=:99 xwininfo -root -tree"` zeigt alle X11-Fenster
im Container — nuetzlich um zu sehen, ob Firefox/Chrome ueberhaupt ein echtes Fenster
(statt eines 10×10-Stub-Fensters) aufgemacht hat, ohne den Umweg ueber noVNC/Tailscale.
Isolationstest fuer "ist es die App oder der Treiber kaputt": minimales Standalone-Python-
Script direkt per `docker exec ... python3 -c "..."` mit `patchright`/`playwright` gegen
`example.com` — kein Profil, kein Proxy, keine Cookies. Wenn das schon fehlschlaegt, liegt
es garantiert nicht an App-Konfiguration.

## Naechste Schritte (nicht mehr in dieser Session erledigt)

- Qolaba-Login (Baer) + danach Passwort-Selektoren fuer Auto-Relogin ableiten.
- Suno-Generierungsfehler klaeren (Vergleichstest direkt auf gpu-pc).
- Portal-Umstellung (cp.go-ki.eu) auf die neue `/ask`-API von bridge.ki1.it.
- MCP-Hub-Verdrahtung (`hub_mcp.py`) fuer die 4 `/ask`-Endpoints.