Codex est lent alors que ChatGPT fonctionne sur le Web ? Diagnostiquer le proxy, les reconnexions et TLS

ChatGPT fonctionne normalement dans le navigateur et Google répond vite, mais Codex tarde à répondre ou affiche Reconnecting à répétition. Dans ce cas, commencez par examiner les erreurs de connexion de Codex, puis décidez s’il faut changer de nœud, ajuster le proxy ou attendre le modèle.

Le bon fonctionnement du site prouve seulement que le navigateur dispose d’une route d’accès opérationnelle ; il ne prouve ni que les requêtes de Codex passent par le même proxy ni que sa connexion persistante fonctionne. Si les journaux indiquent déjà tls handshake eof, une réinitialisation de connexion ou des reconnexions successives, le temps d’attente ne peut pas être entièrement attribué à l’inférence du modèle.

Cet article traite des ralentissements de Codex accompagnés d’anomalies de connexion. Procédez dans cet ordre : vérifier les reconnexions → confirmer le chemin réel du proxy → contrôler TLS et HTTPS classique → tester ensuite WebSocket ou la connexion en flux.

Les constats ci-dessous proviennent d’un essai réel sur un Mac : trois appels Codex réels ont abouti avec Tailscale ; le nœud AnyTLS enregistré a produit un TLS EOF lors de sa reconstruction isolée, et même Google en HTTPS a échoué. L’essai n’a pas reproduit intégralement la situation antérieure « le site est rapide, seul Codex est lent » ; il ne permet donc pas d’établir la cause racine unique de l’incident passé. Il aide à déterminer quelle couche examiner en premier selon les éléments disponibles.

Codex réfléchit-il ou se reconnecte-t-il sans arrêt ?

Cherchez d’abord l’erreur associée à la requête actuelle au lieu de vous fier uniquement à la durée d’immobilité de l’interface.

Symptôme ou erreur observé	Premier élément à vérifier
`Reconnecting...` avec `tls handshake eof`	Chemin du proxy, établissement TLS et transfert vers la destination
`stream disconnected before completion`	Consultez l’erreur détaillée qui suit ; cette phrase seule ne détermine pas la cause
WebSocket établi puis interrompu, code de fermeture 1006	Heure et durée de fermeture de cette connexion et maillons intermédiaires
HTTP 400 indiquant explicitement que le modèle exige une mise à jour	Version du client ; ne classez pas d’abord le problème comme réseau
Aucune erreur de connexion, seulement un long délai d’attente	Gardez votre conclusion ouverte : la lenteur seule ne prouve pas une rupture réseau

Cette série d’essais utilisait le même modèle et le même niveau de raisonnement ; la seule consigne donnée à Codex était de renvoyer le texte fixe NETWORK_PROBE_OK :

Chemin	Résultat de l’appel réel
Tailscale, trois sessions courtes indépendantes	Les trois ont abouti ; la durée totale du processus CLI était respectivement de 11.551, 13.945 et 14.877 secondes
HTTP CONNECT local avec sortie via Tailscale	Terminé ; durée totale du processus : 11.634 secondes
HTTP CONNECT local utilisant le nœud AnyTLS enregistré	Reconnexions répétées ; aucune réussite pendant la fenêtre d’observation de 45 secondes

L’appel en échec a produit ces journaux :

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

Dans ce cas, attendre davantage ne signifie pas que le modèle génère continuellement une réponse. La requête subit des échecs de connexion et des tentatives répétées ; il faut donc d’abord diagnostiquer la connexion.

Les durées du tableau incluent le démarrage du processus, l’authentification, l’inférence et le transfert ; elles ne correspondent ni à la latence avant le premier jeton ni au seul temps réseau. Les 45 secondes constituent la limite d’arrêt du programme de test, et non le temps de réponse moyen du proxy.

Pourquoi Codex peut-il être inaccessible alors que ChatGPT fonctionne sur le Web ?

Vérifiez séparément la connexion réelle du navigateur, de l’application de bureau et de la CLI. Une extension proxy du navigateur, le proxy système, TUN, le routage par processus et les variables proxy du terminal peuvent agir sur des périmètres différents. Le bon fonctionnement d’un programme ne permet pas de conclure qu’un autre emprunte le même chemin.

Dans Clash Verge, vérifiez d’abord ces trois points :

Vérifiez si le journal de connexions de Clash affiche le trafic correspondant lorsque Codex envoie une requête. La présence d’une variable dans le terminal ne prouve pas que la requête est passée par le proxy.
Confirmez que la règle appliquée et la sortie correspondent aux attentes. Examinez la requête actuelle, et pas seulement l’écran de sélection du nœud.
Comparez le même contexte d’utilisation. Le succès de la CLI ne prouve pas que toutes les connexions en arrière-plan de l’application de bureau fonctionnent ; une conversation sur le Web ne remplace pas non plus le test de connexion de l’application de bureau.

Lors du test réel du proxy CLI, le journal du proxy isolé a affiché chatgpt.com, ce qui confirme que la requête est arrivée à cette entrée. Le test de contrôle HTTP CONNECT a également exécuté une vraie requête avec succès, ce qui montre que le client pouvait fonctionner par cette entrée dans cet essai.

Cependant, le canal durable/app-server en erreur dans les journaux du bureau doit être analysé séparément. La documentation d’OpenAI distingue aussi les requêtes et événements SSE de ceux de WebSocket ; ne fusionnez pas les résultats de canaux différents pour conclure que « le réseau Codex fonctionne ».Catégories d’événements de télémétrie de connexion Codex

Si le navigateur fonctionne mais que le trafic Codex concerné n’apparaît pas dans le proxy attendu, corrigez d’abord le chemin de cette requête. Changer de nœud à répétition peut ne rien changer à la connexion en échec.

Que vérifier en premier si Codex signale tls handshake eof ?

tls handshake eof indique que la connexion s’est terminée prématurément pendant la négociation TLS. Cela ne signifie pas « WebSocket établi normalement puis expiré après une période d’inactivité ». Vérifiez d’abord si HTTPS classique fonctionne par le même proxy, puis examinez la connexion persistante de l’application.

Vérifier HTTPS classique par le même proxy

Testez une URL HTTPS simple à la fois via le réseau système actuel et via le proxy local explicitement spécifié. Utilisez le port du client réellement actif ; tester la même URL dans le navigateur ne confirme toujours pas le chemin utilisé par Codex.

Les commandes ci-dessous utilisent un port remplaçable. 7897 est un exemple : remplacez-le par le port HTTP ou mixed actuel de Clash. Cet essai a utilisé un port temporaire attribué par le script.

# 不显式使用 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

Si la première erreur indique que le port local est inaccessible, vérifiez que Clash fonctionne et que le port est exact ; le nœud distant n’a pas encore été testé. Si l’échec survient au stade TLS, examinez le nœud et le transfert vers la destination. La réussite des deux commandes prouve seulement qu’un HTTPS de courte durée est disponible ; il faut encore tester Codex.

Cette série comprenait trois essais par destination et par chemin :

Cible testée	Chemin Tailscale	Chemin du proxy isolé avec le nœud enregistré
Google `generate_204`	HTTP 204 les trois fois	curl 35 les trois fois, sans réponse HTTP
Page d’accueil de ChatGPT	HTTP 403 les trois fois	curl 35 les trois fois, sans réponse HTTP
GET non authentifié vers l’URL responses de Codex	HTTP 405 les trois fois	curl 35 les trois fois, sans réponse HTTP

curl 35 est une erreur de connexion SSL/TLS ; le message de cet essai était SSL_ERROR_SYSCALL.Description des codes d’erreur curl

Ces réponses 403 et 405 ne prouvent pas que les fonctions ChatGPT ou Codex fonctionnent ; elles indiquent seulement que la sonde a reçu une réponse HTTP. Un GET non authentifié ne remplace pas non plus un appel légitime au modèle. La véritable validation de l’application est la requête de la section précédente, qui a renvoyé la marque fixe.

Néanmoins, le fait que le chemin proxy échoue aussi sur HTTPS Google suffit à modifier l’ordre du diagnostic : rétablissez d’abord le transfert HTTPS général au lieu d’attribuer immédiatement le problème au WebSocket de Codex.

Un nœud joignable ne signifie pas qu’il peut vous connecter à OpenAI

Si l’entrée du proxy est joignable, vérifiez ensuite l’authentification, la compatibilité du protocole et le transfert vers la destination.

Lors de cet essai, le client proxy a été contourné et un socket natif lié à la carte réseau physique a été utilisé pour joindre les quatre entrées IPv4 résolues du nœud. Les quatre connexions TCP ont abouti en environ 4–7 ms ; les négociations TLS avec validation du certificat ont également abouti, en 248–553 ms environ au total.

Cela prouve seulement que l’entrée est joignable. Le chemin du proxy comporte encore les étapes suivantes :

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

La réussite TLS à l’entrée et la réussite TLS vers le site cible via le proxy sont deux vérifications distinctes. La première ne prouve ni que l’authentification AnyTLS fonctionne ni que le nœud peut accéder à Google ou OpenAI.

Lors de cet essai, fixer le domaine du nœud sur l’une des adresses IP résolues n’a pas rétabli HTTPS Google. En revanche, le passage de l’entrée HTTP CONNECT locale de la même implémentation en mode DIRECT, avec sortie via Tailscale, a permis d’obtenir Google 204. Ces comparaisons orientent l’examen vers la compatibilité entre le protocole du nœud et le client, l’authentification et l’état du transfert, ainsi que les journaux de sortie du serveur ; elles ne suffisent pas à désigner une cause racine unique.

Si vos résultats sont identiques, recueillez ensuite les erreurs de ces étapes au lieu de clore l’analyse parce que « le ping est faible » ou que « le port du serveur est joignable ».

Faut-il désactiver WebSocket si Codex se reconnecte sans cesse ?

Distinguez deux éléments : le WebSocket utilisé par l’application Codex et le protocole de transport utilisé par le nœud proxy.

Le nœud sélectionné et enregistré dans cet essai était AnyTLS, et non un nœud VLESS/WS de la configuration. L’hypothèse « ce nœud utilise WS, donc Codex est lent » ne correspond donc pas au type de nœud enregistré. Le WebSocket propre à Codex peut toutefois échouer en le traversant.

La décision d’examiner WebSocket dépend de l’étape atteinte par la connexion :

Élément observé	Priorité du diagnostic
HTTPS classique ne parvient pas non plus à négocier TLS	Réparer d’abord l’établissement et le transfert du proxy
HTTPS classique fonctionne, mais la négociation WS échoue	Vérifier la négociation de cette connexion, son chemin proxy et la politique d’accès
WS est établi puis se coupe en cours d’utilisation ou après inactivité	Noter le moment de la coupure et vérifier le maintien de connexion et les maillons intermédiaires

La connexion persistante a été testée avec le service public WSS Echo de Postman : via Tailscale, cinq messages ont d’abord été échangés ; le ping périodique initié par le client de test a été désactivé, la connexion est restée inactive 90 secondes, puis cinq autres messages ont été échangés. Les dix échos correspondaient. Désactiver le ping client ne signifie pas supprimer le keepalive TCP ni les éventuelles trames envoyées par le serveur.Présentation de Postman Echo

Un autre test de contrôle HTTP CONNECT/DIRECT a également réussi la négociation WSS et l’écho. Il montre que cette entrée proxy locale pouvait transporter WSS, sans permettre de généraliser à tous les nœuds ; le service public Echo ne remplace pas non plus le point de terminaison précis de Codex.

Les journaux historiques du bureau contenaient exactement 10 événements websocket_error et 15 événements reconnect_started, associés au canal durable. Il s’agit d’enregistrements d’événements, pas de 25 pannes indépendantes ; une même erreur peut se propager dans plusieurs lignes d’état.

Le code de fermeture 1006 indique lui aussi uniquement une fermeture anormale ; il ne permet pas à lui seul d’identifier qui a interrompu la connexion.Définition RFC du code de fermeture anormale WebSocket

Ainsi, après l’apparition de Reconnecting, n’appliquez pas directement un réglage « désactiver WS ». Dans cet essai, l’échec apparaissait déjà au stade TLS ; rien ne permet d’affirmer que modifier le délai d’inactivité de WebSocket serait la correction correspondante.

Tailscale peut-il résoudre les ralentissements de Codex ?

Pour les requêtes courtes testées sur ce Mac, Tailscale est un chemin dont le fonctionnement a été vérifié ; cela ne garantit pas qu’il sera plus rapide en général. Trois appels Codex réels et un test d’écho après 90 secondes d’inactivité étayent mieux la décision actuelle de continuer à l’utiliser qu’un simple test de débit.

Tailscale utilise WireGuard : lorsqu’une connexion directe est possible, le transport passe par UDP ; sinon, un relais peut être utilisé. Le WebSocket de Codex peut fonctionner dans son tunnel ; passer à Tailscale ne revient pas à désactiver WebSocket.Types de connexion Tailscale

Sur les 20 sondes de découverte Tailscale de cet essai, 17 ont réussi et 3 ont expiré ; la médiane RTT des échantillons réussis était de 188 ms. Cela ne représente pas directement le taux de perte à long terme du trafic métier, mais montre que « cela fonctionne » ne signifie ni « aucune latence » ni « aucune anomalie ».

De même, dig ne prouve pas une congestion du réseau dorsal China Telecom 163. Les trois requêtes A du domaine ChatGPT ont réussi en 185–233 ms ; elles mesurent les requêtes DNS et ne remplacent pas TCP, TLS ni les appels réels à l’application. Cet essai n’a pas fourni de preuves suffisantes pour confirmer une congestion du réseau dorsal 163.

Si Codex refonctionne après le changement de sortie, vous pouvez confirmer que « le changement de chemin a modifié le résultat ». Pour attribuer ensuite le résultat à un opérateur précis, à la charge d’un nœud partagé ou au protocole proxy, il faut des éléments adaptés à cette conclusion.

Comment vérifier que Codex est rétabli, et pas seulement que la page Web s’ouvre ?

Validez le client où le problème est survenu au lieu de retourner simplement dans le navigateur pour actualiser la page d’accueil.

Envoyez une courte requête sans outil. Conservez le même modèle et le même niveau de raisonnement, puis vérifiez que la réponse est complète afin de ne pas mélanger le temps d’exécution des outils au test de connexion.
Vérifiez la règle proxy, la sortie et les journaux d’erreur de cette requête. Assurez-vous que les reconnexions ont cessé ; la configuration d’un proxy ne prouve pas que la requête l’a emprunté.
Testez ensuite le flux de travail qui échouait. La réussite d’une requête courte ne remplace pas la vérification des tâches longues, de la reprise après inactivité ou du canal d’arrière-plan du bureau. Cet essai n’a abouti qu’à une requête courte au modèle ; il n’a pas prouvé le rétablissement des flux longs.

Dans l’application de bureau, envoyez simplement : « Ne lisez aucun fichier et n’utilisez aucun outil ; répondez uniquement NETWORK_PROBE_OK. » Les utilisateurs de la CLI peuvent essayer la commande ci-dessous ; elle appelle réellement le modèle et ne constitue pas une vérification hors ligne :

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

Testez avec la version et les paramètres réellement concernés, en consignant les erreurs et le résultat. Ne déclarez pas l’application de bureau rétablie au seul motif qu’une autre CLI répond.

Si le client indique explicitement qu’une mise à jour de version est nécessaire pour le modèle, résolvez d’abord la compatibilité. Cela s’est produit au premier test de cette série : la CLI autonome 0.151.0 a renvoyé HTTP 400 ; le nouveau test a ensuite utilisé 0.164.0-alpha.11.1, inclus dans l’application. Le premier résultat n’a pas été compté comme un échec réseau.

Au vu des résultats actuels, le choix pratique est de continuer avec Tailscale, qui a mené des appels réels à terme ; pour examiner ce proxy, rétablissez d’abord HTTPS classique puis testez la connexion Codex précise. Pour expliquer l’incident antérieur « le Web fonctionnait, seul Codex était lent », il faudrait encore enregistrer simultanément la connexion et la sortie lorsque ces conditions se reproduisent.

Périmètre des tests : Les données de l’article proviennent de tests locaux sur un Mac, dans la nuit du 27 octobre 2026. L’expérience proxy a repris les paramètres du nœud AnyTLS enregistré et l’a reconstruit dans un processus mihomo indépendant ; elle n’a pas démarré l’interface/TUN Clash d’origine et n’a modifié ni le proxy système ni la sortie Tailscale. Bien que la liaison à la carte réseau physique ait été configurée, nettop n’a pas capturé d’interface amont vérifiable pour ce processus AnyTLS ; on ne peut donc pas affirmer que les deux chemins physiques complets ont été vérifiés de façon totalement indépendante. Les résultats de la CLI, du canal durable de bureau et du service Echo public ont été consignés séparément ; les données brutes, scripts et conditions détaillées sont conservés dans les documents d’expérience associés.