Live-Transkription, wenn die Firewall WebSockets blockiert

Es gibt eine bestimmte, zum Verrücktwerden ärgerliche Art, wie Echtzeit-Transkription in einem Firmennetz scheitert. Dein WLAN ist in Ordnung. HTTPS funktioniert — du kannst jede Website laden. Aber die Live-Transkription startet einfach... nicht, und nichts sagt dir, warum.

Der Übeltäter ist eine Klasse von Firmen-Proxys, die gewöhnlichen HTTPS-Verkehr erlaubt, aber das WebSocket-Upgrade blockiert — den Handshake, der eine HTTPS-Verbindung in den dauerhaften, bidirektionalen Kanal verwandelt, den Echtzeit-Transkription braucht. Für den Proxy sieht ein WebSocket wie ein unüberwachter Tunnel aus dem Netz aus, also killt er ihn. Für dich ist die Transkription lautlos kaputt.

GeekBye v2.0.8 hat genau dafür einen automatischen Fallback ergänzt — und ihn zu bauen förderte einen Bug zutage, der das ganze Feature nichts hätte tun lassen.

Warum ein Fallback und nicht nur ein Retry

Wackelige Netze fangen wir bereits ab. Wenn deine Verbindung mitten in der Session abbricht, verbindet sich GeekBye mit Backoff neu und puffert dein Audio, damit nichts verloren geht — das ist ein eigenes Feature, behandelt in warum dein KI-Notetaker bei schlechtem WLAN stoppt.

Aber ein blockierter WebSocket ist keine wackelige Verbindung. Denselben WebSocket gegen einen Proxy zu wiederholen, der WebSockets ablehnt, scheitert jedes Mal auf dieselbe Weise, für immer. Die einzige Lösung ist ein anderer Transport — einer, der wie das schlichte HTTPS aussieht, das der Proxy ohnehin erlaubt.

Also fällt v2.0.8 auf einen reinen HTTPS-Transport über denselben authentifizierten Endpoint zurück:

• Runter (Transkripte, die zu dir zurückkommen): server-sent events — eine langlebige HTTPS-Antwort, die der Proxy als gewöhnlichen gestreamten Download sieht.
• Rauf (dein Audio, das rausgeht): gebündelte POST-Requests, jeder mit einem Audio-Chunk und einer Sequenznummer, damit der Server sie in der richtigen Reihenfolge wieder zusammensetzen kann, selbst wenn das Netz sie umsortiert.

Kein dauerhafter Socket, nichts, das wie ein Tunnel aussieht — nur HTTPS-Requests und -Antworten. Wenn ein Proxy dich eine Website nutzen lässt, lässt er auch das durch.

Der Bug, der ein totes Feature ausgeliefert hätte

Hier ist der Teil, der die Lektüre wert ist. Der Fallback soll auslösen, wenn die WebSocket-Verbindung ihre Versuche mit einer Signatur für blockierten Transport erschöpft — jeder Versuch scheitert am Upgrade, kein Auth- oder Quota-Problem, mindestens eine proxy-förmige Ablehnung. Ein Proxy, der einen WebSocket blockiert, beantwortet das Upgrade typischerweise mit einem HTTP 403 Forbidden oder 407.

Das Problem: Unser Verbindungscode hatte bereits eine Regel, dass ein 403 einen fatalen Authentifizierungsfehler — stopp, zeig ihn dem Nutzer, kein Retry bedeutet. Was fast überall korrekt ist. Aber es bedeutete, dass das 403 eines blockierenden Proxys — genau das Signal, das den Fallback hätte auslösen sollen — stattdessen als fataler Fehler geworfen wurde, bevor die Fallback-Logik überhaupt laufen konnte. Nur ein roher Verbindungsabbruch (ein 1006-Close) fiel bis zum Fallback durch. Also hätte das Feature für den seltenen Fall funktioniert und für sein eigentliches Hauptziel lautlos versagt: den Firmen-Proxy.

Wir haben das beim Härten des Releases gefangen, nicht in Produktion. Der Fix: Ein 403/407 auf der Upgrade-Stufe des WebSockets wird jetzt als behebbar behandelt, damit die Verbindungsschleife sich in den Fallback erschöpfen kann — während ein echter Authentifizierungsfehler (der anders eintrifft, nachdem das Upgrade erfolgreich war) weiterhin schnell scheitert, genau wie vorher. Ein Regressionstest fixiert nun die Unterscheidung: Ein 403 von einem blockierenden Proxy muss auf den Fallback wechseln; ein echtes Auth-403 darf nicht.

Der Rest der Härtung folgte derselben paranoiden Linie: ein Timeout auf jedem Upstream-POST, damit ein Proxy, der einen Request annimmt, aber nie antwortet, den Audiostrom nicht ins Stocken bringen kann, und eine Garantie, dass ein echtes Anmeldeproblem niemals lautlos von der Fallback-Maschinerie verdeckt werden kann.

Wir haben es gegen einen echten feindlichen Proxy getestet

Ein Feature, dessen ganzer Zweck das Überleben in feindlichen Netzen ist, lässt sich nicht allein mit Unit-Tests validieren — Unit-Tests haben keine Proxys. Bevor wir es aktivierten, schickten wir die echte App durch einen lokalen Reverse-Proxy, konfiguriert, genau das zu tun, was Firmen-Proxys tun: HTTPS weiterleiten, WebSocket-Upgrades mit einem 403 ablehnen.

Die Spur in den Logs ist der Beleg: vier blockierte WebSocket-Versuche, die Erschöpfungssignatur erkannt, der automatische Wechsel zum HTTPS-Transport und dann eine gesunde 96-sekündige Transkriptionssession über reines HTTPS — 66 Transkriptsegmente, null Ausfälle. Das Failover funktioniert, weil wir zugesehen haben, wie es umschaltete.

Drei übertragbare Lektionen

1. „Es funktioniert bei wackeligem WLAN" und „es funktioniert hinter einem feindlichen Proxy" sind verschiedene Garantien. Das eine braucht Reconnection; das andere braucht einen anderen Transport. Sie zu verwechseln lässt eine ganze Population von Firmennutzern lautlos kaputt zurück.
2. Deine Fehlerklassifizierung kann dein eigenes Feature vor sich selbst verstecken. Eine Regel, die zu 99 % korrekt ist (403 = fatale Auth), war für das 1 %, dem dieses Feature zu dienen existierte, genau falsch. Wenn du einen Fallback hinzufügst, prüfe, ob die Auslösebedingung den Fallback überhaupt erreichen kann.
3. Teste den Gegner, nicht nur den Happy Path. Der einzige ehrliche Test von „übersteht einen WebSocket-blockierenden Proxy" ist ein WebSocket-blockierender Proxy. Wir haben einen gebaut.

GeekBye v2.0.8 hat den HTTPS-Fallback flag-gesteuert und validiert ausgeliefert. Für die Zuverlässigkeitsarbeit, an die er anschließt, siehe warum dein KI-Notetaker bei schlechtem WLAN stoppt, und für die benachbarten Releases dieser Serie warum dein KI-Notetaker mitten im Meeting die Aufnahme stoppt (v2.0.9) und warum KI-Transkription Fachbegriffe falsch versteht (v2.0.11).