Codex ist langsam, obwohl ChatGPT im Web funktioniert? Proxy, Neuverbindungen und TLS untersuchen

ChatGPT funktioniert im Browser normal und Google ist schnell, doch Codex antwortet nur langsam oder zeigt wiederholt Reconnecting an. Prüfe in diesem Fall zuerst die Verbindungsfehler von Codex und entscheide danach, ob du den Knoten wechseln, den Proxy anpassen oder auf das Modell warten solltest.

Eine funktionierende Website belegt nur, dass der aktuelle Zugriffsweg des Browsers verfügbar ist. Sie belegt weder, dass Codex-Anfragen denselben Proxy verwenden, noch, dass seine dauerhafte Verbindung funktioniert. Wenn die Protokolle bereits tls handshake eof, einen Verbindungsabbruch oder wiederholte Neuverbindungen zeigen, lässt sich die gesamte Wartezeit nicht der Modellinferenz zuschreiben.

Dieser Artikel behandelt langsames Codex-Verhalten mit begleitenden Verbindungsfehlern. Gehe in dieser Reihenfolge vor: Neuverbindungen erkennen → den tatsächlichen Proxy-Pfad feststellen → TLS und gewöhnliches HTTPS prüfen → anschließend WebSocket oder Streaming-Verbindung testen.

Die folgenden Einschätzungen beruhen auf einem echten Test auf einem Mac: Drei echte Codex-Aufrufe wurden mit Tailscale abgeschlossen; der gespeicherte AnyTLS-Knoten erzeugte beim isolierten Neuaufbau TLS EOF und selbst Google HTTPS schlug fehl. Der Test reproduzierte den früheren Zustand „die Website ist schnell, nur Codex ist langsam“ nicht vollständig und beweist daher keine einzelne Ursache für den damaligen Fehler. Er hilft dabei, anhand der jeweiligen Belege zuerst die passende Ebene zu untersuchen.

Denkt Codex nach oder verbindet es sich ständig neu?

Suche zuerst nach dem Fehler des aktuellen Aufrufs, statt nur darauf zu achten, wie lange die Oberfläche unverändert bleibt.

Beobachtetes Symptom oder Fehler	Was du zuerst prüfen solltest
`Reconnecting...` zusammen mit `tls handshake eof`	Proxy-Pfad, TLS-Aufbau und Weiterleitung zum Ziel
`stream disconnected before completion`	Prüfe den konkreten nachfolgenden Fehler; diese Meldung allein bestimmt keine Ursache
WebSocket wurde aufgebaut und dann mit Schließcode 1006 unterbrochen	Zeitpunkt und Dauer des Verbindungsendes sowie Zwischenglieder der Verbindung
HTTP 400 mit ausdrücklichem Hinweis auf erforderliche Modellaktualisierung	Clientversion; ordne den Fehler nicht zuerst als Netzwerkproblem ein
Kein Verbindungsfehler, nur langes Warten auf ein Ergebnis	Bleibe vorsichtig: Langsamkeit allein beweist keine unterbrochene Verbindung

In dieser Testrunde wurden dasselbe Modell und dieselbe Reasoning-Stufe verwendet. Codex sollte lediglich den festen Text NETWORK_PROBE_OK zurückgeben:

Pfad	Ergebnis des echten Aufrufs
Tailscale, drei unabhängige kurze Sitzungen	Alle abgeschlossen; die gesamte CLI-Prozessdauer betrug 11.551, 13.945 beziehungsweise 14.877 Sekunden
Lokales HTTP CONNECT mit Tailscale als Ausgang	Abgeschlossen; gesamte Prozessdauer 11.634 Sekunden
Lokales HTTP CONNECT über den gespeicherten AnyTLS-Knoten	Wiederholte Neuverbindungen; innerhalb des Beobachtungsfensters von 45 Sekunden nicht abgeschlossen

Der fehlgeschlagene Aufruf erzeugte diese Protokolle:

Reconnecting... 2/5 (... tls handshake eof)
Reconnecting... 3/5 (... tls handshake eof)
Reconnecting... 4/5 (... tls handshake eof)
Reconnecting... 5/5 (... tls handshake eof)
Reconnecting... waiting for network

In diesem Fall bedeutet weiteres Warten nicht, dass das Modell fortlaufend eine Antwort erzeugt. Die Anfrage erlebt Verbindungsfehler und Wiederholungen; prüfe daher zuerst die Verbindung.

Die Tabellenzeiten umfassen Prozessstart, Authentifizierung, Inferenz und Übertragung. Sie sind weder die Zeit bis zum ersten Token noch reine Netzwerkzeit. Die 45 Sekunden sind die Abbruchgrenze des Testprogramms und keine durchschnittliche Antwortzeit des Proxys.

Warum kann Codex keine Verbindung herstellen, obwohl ChatGPT im Web funktioniert?

Prüfe die tatsächliche Verbindung von Browser, Desktop-App und CLI getrennt. Eine Browser-Proxy-Erweiterung, Systemproxy, TUN, prozessbasiertes Routing und Proxy-Umgebungsvariablen im Terminal können unterschiedliche Bereiche abdecken. Dass ein Programm funktioniert, beweist nicht, dass ein anderes denselben Pfad verwendet.

Prüfe in Clash Verge zunächst diese drei Punkte:

Prüfe, ob das Clash-Verbindungsprotokoll den passenden Datenverkehr anzeigt, wenn Codex die Anfrage sendet. Eine gesetzte Variable im Terminal beweist noch nicht, dass die Anfrage den Proxy durchlaufen hat.
Prüfe, ob die angewendete Regel und der Ausgang den Erwartungen entsprechen. Untersuche die aktuelle Anfrage und nicht nur die Knotenauswahl.
Vergleiche denselben Nutzungskontext. Eine funktionierende CLI beweist nicht, dass alle Hintergrundverbindungen der Desktop-App funktionieren; eine Unterhaltung im Web ersetzt auch keinen Verbindungstest der Desktop-App.

Beim echten CLI-Proxytest dieser Runde zeigte das Protokoll des isolierten Proxys chatgpt.com. Damit ist bestätigt, dass die Anfrage diesen Proxy-Eingang erreichte. Auch der HTTP-CONNECT-Kontrolltest schloss eine echte Anfrage ab und zeigt, dass der Client in dieser Runde über diesen Eingang funktionieren konnte.

Der fehlerhafte Kanal durable/app-server in den Desktop-Protokollen muss jedoch separat untersucht werden. Auch die OpenAI-Dokumentation führt SSE- und WebSocket-Anfragen sowie Ereignisse als getrennte Beobachtungskategorien auf. Fasse den Erfolg und Fehler verschiedener Kanäle nicht zur Aussage „Codex-Netzwerk funktioniert“ zusammen.Kategorien der Codex-Verbindungstelemetrie

Wenn der Browser funktioniert, der passende Codex-Datenverkehr aber nicht im erwarteten Proxy auftaucht, korrigiere zuerst den Proxy-Pfad dieser Anfrage. Ein wiederholter Knotenwechsel kann wirkungslos bleiben, wenn sich dadurch die fehlerhafte Verbindung gar nicht ändert.

Was solltest du bei tls handshake eof zuerst prüfen?

tls handshake eof weist darauf hin, dass die Verbindung während des TLS-Handshakes vorzeitig beendet wurde. Das bedeutet nicht dasselbe wie „WebSocket wurde normal aufgebaut und lief später wegen Inaktivität ab“. Prüfe zunächst, ob gewöhnliches HTTPS über denselben Proxy funktioniert, und untersuche danach die dauerhafte Verbindung der Anwendung.

Gewöhnliches HTTPS über denselben Proxy prüfen

Teste eine einfache HTTPS-Adresse sowohl über das aktuelle Systemnetzwerk als auch über den ausdrücklich angegebenen lokalen Proxy. Verwende den Port des tatsächlich laufenden Clients; derselbe Aufruf im Browser bestätigt weiterhin nicht den von Codex verwendeten Pfad.

Die folgenden Befehle verwenden einen austauschbaren Port. 7897 ist nur ein Beispiel und muss durch den aktuellen HTTP- oder Mixed-Port von Clash ersetzt werden. In diesem Experiment kam ein vom Skript zugewiesener temporärer Port zum Einsatz.

# 不显式使用 HTTP 代理，沿当前系统路由访问。
# 如果开着 TUN 或 Tailscale，这不等于绕过它们。
curl --noproxy '*' --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

# 明确经过本地 HTTP/mixed 代理入口。
curl --proxy http://127.0.0.1:7897 --noproxy '' \
  --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

Wenn zuerst der lokale Port nicht erreichbar ist, prüfe, ob Clash läuft und der Port stimmt; der entfernte Knoten wurde dann noch nicht getestet. Scheitert es erst bei TLS, untersuche den Knoten und die Weiterleitung zum Ziel. Erfolgreiche Befehle belegen lediglich, dass kurzes HTTPS funktioniert; Codex muss noch getestet werden.

In dieser Runde wurde jedes Ziel über jeden Pfad dreimal getestet:

Testziel	Tailscale-Pfad	Isolierter Proxy-Pfad mit gespeichertem Knoten
Google `generate_204`	Dreimal HTTP 204	Dreimal curl 35, keine HTTP-Antwort
ChatGPT-Startseite	Dreimal HTTP 403	Dreimal curl 35, keine HTTP-Antwort
Nicht authentifizierter GET an die Codex-Responses-Adresse	Dreimal HTTP 405	Dreimal curl 35, keine HTTP-Antwort

curl 35 ist ein Fehler beim Aufbau von SSL/TLS; die Meldung in diesem Test lautete SSL_ERROR_SYSCALL.Beschreibung der curl-Fehlercodes

Die Antworten 403 und 405 belegen nicht, dass ChatGPT oder Codex funktionsfähig sind; sie zeigen lediglich, dass die Sonde eine HTTP-Antwort erhielt. Ein nicht authentifizierter GET ersetzt ebenfalls keinen legitimen Modellaufruf. Die echte Anwendungsprüfung ist der Aufruf aus dem vorigen Abschnitt, der die feste Markierung zurückgab.

Dass der Proxy-Pfad sogar beim HTTPS-Aufruf an Google scheiterte, reicht jedoch aus, um die Diagnose-Reihenfolge zu ändern: Stelle zuerst die allgemeine HTTPS-Weiterleitung wieder her, statt das Problem direkt dem Codex-WebSocket zuzuschreiben.

Ein erreichbarer Knoten kann OpenAI trotzdem unerreichbar machen

Wenn der Proxy-Eingang erreichbar ist, prüfe als Nächstes Authentifizierung, Protokollkompatibilität und Weiterleitung zum Ziel.

In dieser Runde wurde der Proxy-Client umgangen und ein natives Socket an die physische Netzwerkkarte gebunden, um die vier aufgelösten IPv4-Eingänge des Knotens anzusprechen. Alle vier TCP-Verbindungen wurden in etwa 4–7 ms aufgebaut; auch der TLS-Handshake mit Zertifikatsprüfung war erfolgreich und dauerte insgesamt etwa 248–553 ms.

Das belegt lediglich, dass der Eingang erreichbar ist. Der Proxy-Pfad umfasst weitere Schritte:

本机 → 代理入口 TCP/TLS → 认证、协议处理与转发 → 目标服务

Ein erfolgreicher TLS-Handshake am Eingang und ein erfolgreicher TLS-Zugriff auf die Zielseite über den Proxy sind zwei unterschiedliche Prüfungen. Der erste beweist weder eine erfolgreiche AnyTLS-Authentifizierung noch, dass der Knoten Google oder OpenAI erreichen kann.

In dieser Runde schlug Google HTTPS weiterhin fehl, nachdem die Knotendomäne auf eine der aufgelösten IP-Adressen festgelegt worden war. Derselbe lokale HTTP-CONNECT-Eingang derselben Implementierung lieferte Google 204, nachdem er auf DIRECT umgestellt wurde und über Tailscale ausging. Dieser Vergleich lenkt die Untersuchung auf die Kompatibilität zwischen Knotenprotokoll und Client, den Authentifizierungs- und Weiterleitungsstatus sowie die Server-Ausgangsprotokolle, reicht jedoch nicht aus, um eine einzelne Ursache festzulegen.

Wenn du dasselbe Ergebnis erhältst, sammle als Nächstes Fehlermeldungen dieser Schritte, statt die Untersuchung mit „Ping ist niedrig“ oder „Serverport ist erreichbar“ abzuschließen.

Solltest du WebSocket abschalten, wenn Codex ständig Reconnecting zeigt?

Unterscheide zwei Dinge: das von der Codex-Anwendung verwendete WebSocket und das Transportprotokoll des Proxy-Knotens.

Der in diesem Versuch ausgewählte und gespeicherte Knoten war AnyTLS und kein VLESS/WS-Knoten aus der Konfiguration. Die Vermutung „dieser Knoten verwendet WS, deshalb ist Codex langsam“ passt daher nicht zum gespeicherten Knotentyp. Codex’ eigenes WebSocket kann bei der Weiterleitung durch diesen Knoten trotzdem scheitern.

Ob du WebSocket untersuchen solltest, hängt davon ab, wie weit die Verbindung gekommen ist:

Vorliegender Hinweis	Schwerpunkt der Untersuchung
Auch gewöhnliches HTTPS kann den TLS-Handshake nicht abschließen	Zuerst Proxy-Aufbau und Weiterleitung reparieren
Gewöhnliches HTTPS funktioniert, aber der WS-Handshake schlägt fehl	Handshake der betreffenden Verbindung, Proxy-Pfad und Zugriffsrichtlinie prüfen
WS wurde aufgebaut und bricht während der Nutzung oder nach Inaktivität ab	Zeitpunkt des Abbruchs festhalten sowie Verbindungserhaltung und Zwischenpfad prüfen

In dieser Runde wurde eine dauerhafte Verbindung mit dem öffentlichen WSS-Echo-Dienst von Postman geprüft: Über Tailscale wurden zunächst fünf Nachrichten ausgetauscht, dann wurde der vom Testclient initiierte periodische Ping abgeschaltet, die Verbindung 90 Sekunden inaktiv gelassen und anschließend wurden weitere fünf Nachrichten ausgetauscht. Alle zehn Echos stimmten überein. Das Abschalten des Client-Pings bedeutet nicht, dass TCP-Keepalive oder mögliche Frames des Servers entfallen.Informationen zu Postman Echo

Ein weiterer HTTP-CONNECT/DIRECT-Kontrolltest konnte den WSS-Handshake und Echo ebenfalls abschließen. Das belegt, dass dieser lokale Proxy-Eingang WSS transportieren konnte. Es lässt sich nicht auf alle Proxy-Knoten übertragen; der öffentliche Echo-Dienst ersetzt auch nicht den konkreten Codex-Endpunkt.

In älteren Desktop-Protokollen wurden ausdrücklich 10 websocket_error-Ereignisse und 15 reconnect_started-Ereignisse für den Durable-Kanal gefunden. Das sind Ereignisprotokolle und keine 25 unabhängigen Ausfälle; derselbe Fehler kann sich in mehreren Statuszeilen niederschlagen.

Auch Schließcode 1006 bedeutet lediglich einen abnormalen Verbindungsabbruch. Allein daraus lässt sich nicht erkennen, wer die Verbindung unterbrochen hat.RFC-Definition des abnormalen WebSocket-Schließcodes

Wenn Reconnecting erscheint, solltest du deshalb nicht sofort eine Einstellung zum „Abschalten von WS“ anwenden. In dieser Runde trat der Fehler bereits während TLS auf; es gibt keinen Beleg dafür, dass eine Änderung des WebSocket-Leerlaufzeitlimits die passende Lösung wäre.

Kann Tailscale Codex-Verzögerungen beheben?

Bei den auf diesem Mac getesteten kurzen Anfragen war Tailscale ein nachweislich funktionierender Pfad; eine allgemeine Geschwindigkeitsgarantie ist das nicht. Drei echte Codex-Aufrufe und ein Echo-Test nach 90 Sekunden Inaktivität stützen die aktuelle Entscheidung, Tailscale weiterzuverwenden, besser als ein einfacher Geschwindigkeitstest.

Tailscale verwendet WireGuard: Bei direkter Verbindung wird über UDP übertragen; wenn eine direkte Verbindung nicht möglich ist, kann ein Relay zum Einsatz kommen. Codex-WebSocket kann innerhalb des Tunnels laufen; der Wechsel zu Tailscale schaltet WebSocket nicht ab.Tailscale-Verbindungstypen

Bei 20 Tailscale-Erkennungssonden in dieser Runde waren 17 erfolgreich und 3 liefen ab; der Median-RTT der erfolgreichen Stichproben lag bei 188 ms. Das ist nicht direkt die langfristige Paketverlustrate des Geschäftsdatenverkehrs, zeigt aber, dass „funktioniert“ nicht „ohne Verzögerung und Fehler“ bedeutet.

Ebenso beweist dig keine Überlastung des 163-Backbone-Netzes. Die drei A-Abfragen für die ChatGPT-Domäne waren in 185–233 ms erfolgreich. Sie messen DNS-Abfragen und ersetzen weder TCP noch TLS oder echte Anwendungsaufrufe. In dieser Runde gab es keine ausreichenden Pfadbelege, um eine Überlastung des 163-Backbone-Netzes zu bestätigen.

Wenn Codex nach einem Wechsel des Ausgangs wieder funktioniert, lässt sich bestätigen: „Der geänderte Pfad hat das Ergebnis geändert.“ Für eine zusätzliche Zuordnung zu einem bestimmten Anbieter, der Auslastung eines gemeinsam genutzten Knotens oder einem Proxy-Protokoll sind passende Belege erforderlich.

Wie kannst du prüfen, ob Codex wieder funktioniert und nicht nur die Website gerade lädt?

Teste den Client, in dem das Problem aufgetreten ist, statt nur zum Browser zurückzukehren und die Startseite zu aktualisieren.

Sende eine kurze Anfrage ohne Werkzeuge. Verwende dasselbe Modell und dieselbe Reasoning-Stufe und prüfe, ob eine vollständige Antwort eintrifft, damit die Laufzeit von Werkzeugen nicht in den Verbindungstest einfließt.
Prüfe Proxy-Regel, Ausgang und Fehlerprotokolle der betreffenden Anfrage. Achte darauf, ob noch Neuverbindungen auftreten; eine Proxy-Konfiguration beweist nicht, dass die Anfrage den Proxy tatsächlich genutzt hat.
Teste anschließend den ursprünglich fehlerhaften Arbeitsablauf. Eine erfolgreiche kurze Anfrage ersetzt keine Prüfung langer Aufgaben, der Wiederaufnahme nach Inaktivität oder des Desktop-Hintergrundkanals. In dieser Runde wurde nur eine kurze Modellanfrage abgeschlossen; eine Wiederherstellung langer Abläufe wurde nicht nachgewiesen.

In der Desktop-App kannst du direkt senden: „Lies keine Dateien und verwende keine Werkzeuge; antworte nur mit NETWORK_PROBE_OK.“ CLI-Nutzer können das folgende Beispiel verwenden. Es ruft das Modell tatsächlich auf und ist keine Offline-Prüfung:

codex exec --ephemeral --skip-git-repo-check --sandbox read-only \
  '不要读取文件或调用工具，只回复 NETWORK_PROBE_OK'

Teste mit der Version und den Einstellungen, bei denen das Problem tatsächlich auftrat, und protokolliere Fehler und Abschluss. Erkläre die Desktop-App nicht für wiederhergestellt, nur weil eine andere CLI antwortet.

Wenn der Client ausdrücklich meldet, dass das Modell eine neuere Version benötigt, löse zuerst die Versionskompatibilität. Das passierte beim ersten Test dieser Runde: Die eigenständige CLI 0.151.0 antwortete mit HTTP 400; danach wurde mit 0.164.0-alpha.11.1 erneut getestet, das der App beiliegt. Der erste Versuch wurde nicht als Netzwerkfehler gewertet.

Für das aktuelle Ergebnis ist die umsetzbare Wahl, Tailscale weiterzuverwenden, da damit echte Aufrufe abgeschlossen wurden. Bei der Untersuchung dieses Proxys solltest du zuerst gewöhnliches HTTPS wiederherstellen und anschließend die konkrete Codex-Verbindung testen. Um den früheren Fehler „Webseite normal, nur Codex langsam“ zu erklären, müssen Verbindung und Ausgang erneut gleichzeitig protokolliert werden, wenn genau diese Bedingungen auftreten.

Umfang der Tests: Die Daten dieses Artikels stammen aus lokalen Tests auf einem Mac in den frühen Morgenstunden des 27. Oktober 2026. Beim Proxy-Experiment wurden die Parameter des gespeicherten AnyTLS-Knotens in einem separaten mihomo-Prozess neu aufgebaut. Die ursprüngliche Clash-Oberfläche/TUN wurde nicht gestartet und weder Systemproxy noch Tailscale-Ausgang wurden umgestellt. Obwohl die Bindung an die physische Netzwerkkarte konfiguriert war, erfasste nettop für diesen AnyTLS-Prozess keine verifizierbare Upstream-Schnittstelle. Daher lässt sich nicht behaupten, dass beide vollständigen physischen Pfade vollständig unabhängig geprüft wurden. CLI-, Desktop-Durable-Kanal- und öffentliche-Echo-Ergebnisse wurden jeweils separat aufgezeichnet; Rohdaten, Skripte und ausführliche Bedingungen liegen in den zugehörigen Versuchsmaterialien.