Codex se reconnecte sans cesse ? Vérifiez le DNS et le routage de Clash
Des erreurs Codex comme Reconnecting..., stream disconnected before completion et error sending request peuvent impliquer une interférence DNS ou un routage Clash incorrect. Ce guide explique comment examiner cette possibilité, appliquer une amélioration ciblée de Clash Verge Rev et vérifier le résultat.
Ce que montrent réellement les signalements de la communauté
Des utilisateurs de Reddit ont signalé des tâches interrompues visant chatgpt.com/backend-api/codex/responses, des tentatives de reconnexion répétées et des erreurs liées au corps de la réponse. Ces signalements établissent des symptômes, pas un diagnostic DNS. Requête interrompue, boucle de reconnexion
Une autre discussion décrit des échecs lors du compactage du contexte distant. Un commentateur suggère d’examiner le proxy, mais la discussion n’établit pas une cause vérifiée. Discussion sur le compactage
Des signalements sur X montrent des questions similaires : une publication du 9 septembre décrit des échecs de flux persistants, tandis qu’une publication du 6 septembre signale un délai d’inactivité SSE pendant le compactage distant. Aucun ne fournit une comparaison DNS. Ce sont des exemples utiles de problèmes d’utilisateurs, mais ils n’établissent pas de cause commune. Rapport X sur le flux, Rapport X sur le compactage
| Symptôme | Ce qu’il faut examiner |
|---|---|
| Délai d’attente immédiat avec une erreur de résolution | DNS, accessibilité du nœud et vérification que le trafic entre dans Clash |
| ChatGPT fonctionne dans un navigateur mais Codex échoue | Différences de proxy, DNS, certificats et sortie |
| La sortie commence, puis le flux se déconnecte | Connexions de longue durée, changements réseau et erreurs de service |
| Seules les longues conversations ou le compactage échouent | Comparer avec une petite nouvelle tâche ; examiner les erreurs de session et de serveur |
| HTTP 401, 403, 429 ou 5xx | Examiner l’origine et le corps de la réponse pour l’authentification, la politique, les limites ou les échecs du service |
Vérifiez l’état du service OpenAI et notez l’heure ainsi que la version du client. Pour les conversations bloquées, OpenAI recommande aussi de vérifier les approbations en attente et d’essayer une nouvelle conversation plus petite et ciblée. Les versions bureau et CLI peuvent différer. Dépannage officiel
Un cas local : une réponse DNS inattendue a déclenché DIRECT
Dans une investigation macOS enregistrée utilisant Clash Verge Rev et Mihomo, les nœuds proxy étaient joignables, mais chatgpt.com correspondait à une règle GeoIP/CN et tentait une connexion directe qui expirait. Une comparaison avec un DNS chiffré atteint via le proxy a montré une réponse anormale sur le chemin de résolution local.
Request to chatgpt.com
→ anomalous DNS answer
→ no earlier matching OpenAI domain rule
→ GeoIP selects DIRECT
→ connection times out and Codex retries
Il y a deux problèmes de configuration à traiter : le chemin de résolution et la décision de routage. Ce cas enregistré n’est ni une référence ni une preuve que d’autres échecs de Codex ont la même cause. Une réponse anormale à elle seule ne peut pas non plus identifier l’intermédiaire responsable ni établir spécifiquement un empoisonnement du cache DNS.
Diagnostiquez avant de modifier la configuration
Vérifiez le journal de connexion
Recherchez le nom d’hôte réel dans l’erreur, y compris chatgpt.com ou openai.com. Notez la règle correspondante, la chaîne de connexion et l’erreur au moment de l’échec. Une connexion qui devrait utiliser un proxy mais qui sélectionne DIRECT justifie un examen de l’ordre des règles. Mihomo évalue les règles de routage de haut en bas. Documentation du routage
Si aucune connexion correspondante n’apparaît, vérifiez d’abord si ce client utilise Clash. Le succès dans le navigateur ne prouve pas le chemin utilisé par un processus distinct.
Comparez les chemins de résolution
Sur macOS, inspectez le résolveur système et sa réponse actuelle :
scutil --dns
dscacheutil -q host -a name chatgpt.com
Pour une comparaison chiffrée, remplacez 7890 par votre port HTTP/mixte Clash :
curl --noproxy '' --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
-H 'accept: application/dns-json' \
'https://1.1.1.1/dns-query?name=chatgpt.com&type=A'
La requête utilise l’interface DNS JSON de Cloudflare. Vérifiez le panneau de connexion : un proxy local explicite garantit l’entrée dans Clash, mais les règles Clash déterminent toujours la sortie finale.
Des adresses IP différentes ne sont pas à elles seules une preuve d’interférence. La sélection CDN, la mise en cache, les familles d’adresses et Fake-IP peuvent expliquer des différences. Une adresse synthétique provenant de la plage Fake-IP de Clash n’est pas intrinsèquement suspecte. Corrélez une réponse anormale avec l’itinéraire incorrect et l’échec, puis comparez avec un autre chemin réseau vérifié. Avec TUN activé, même dig @resolver peut être intercepté ; il ne s’agit pas automatiquement d’un test amont indépendant.
Appliquez une amélioration ciblée de Clash Verge Rev
Ce modèle nécessite Clash Verge Rev avec Mihomo, un abonnement existant et un nœud proxy fonctionnel. C’est un Script d’abonnement, pas un profil autonome complet. Sauvegardez d’abord la configuration actuelle. Si vous utilisez déjà un script, intégrez la modification dans sa fonction main(config) existante. Inspectez la configuration d’exécution finale après toutes les étapes d’amélioration. Documentation du Script Clash Verge Rev
Définissez CODEX_PROXY_GROUP sur un groupe existant et sélectionnez un nœud proxy fonctionnel dans ce groupe. Définissez NODE_DNS sur un résolveur DoH qui fonctionne avant la connexion du proxy et résout correctement les noms d’hôte des nœuds. L’exemple AliDNS est prévu pour la validation sur un réseau de Chine continentale ; remplacez-le lorsqu’il n’est pas approprié. Il n’est pas utilisé pour résoudre les domaines d’IA ci-dessous.
// Clash Verge Rev subscription Script. Use with an existing Mihomo profile.
// Replace this with the exact name of a working proxy group in that profile.
const CODEX_PROXY_GROUP = "REPLACE_WITH_EXISTING_PROXY_GROUP";
// Example bootstrap resolver for a mainland-China network. Verify reachability
// and node-hostname answers on your network, or replace with your trusted DoH.
// It must work BEFORE the proxy is established. It does not resolve AI domains.
const NODE_DNS = ["https://223.5.5.5/dns-query#DIRECT"];
function main(config) {
const groups = config["proxy-groups"] || [];
if (!groups.some((group) => group.name === CODEX_PROXY_GROUP)) {
throw new Error("Set CODEX_PROXY_GROUP to an existing working proxy group.");
}
if (/[#&,\r\n]/.test(CODEX_PROXY_GROUP)) {
throw new Error("Use a proxy group name without #, &, commas or newlines.");
}
const domains = ["chatgpt.com", "openai.com", "oaistatic.com", "oaiusercontent.com"];
const doh = [
"https://1.1.1.1/dns-query#" + CODEX_PROXY_GROUP,
"https://8.8.8.8/dns-query#" + CODEX_PROXY_GROUP,
];
const dns = config.dns || {};
const policy = Object.assign({}, dns["nameserver-policy"] || {});
domains.forEach((domain) => { policy["+." + domain] = doh.slice(); });
dns.enable = true;
dns["nameserver-policy"] = policy;
dns["proxy-server-nameserver"] = NODE_DNS.slice();
if (!Array.isArray(dns.nameserver) || dns.nameserver.length === 0) {
dns.nameserver = NODE_DNS.slice();
}
config.dns = dns;
const oldRules = Array.isArray(config.rules) ? config.rules : [];
const aiRules = domains.map((domain) =>
"DOMAIN-SUFFIX," + domain + "," + CODEX_PROXY_GROUP
);
config.rules = aiRules.concat(oldRules.filter((rule) => !aiRules.includes(rule)));
return config;
}
Le script ajoute une politique DNS spécifique au domaine et préfixe les règles de proxy tout en conservant les autres règles et politiques de domaine. Il modifie la résolution des noms d’hôte des nœuds. Les quatre suffixes de domaine constituent un périmètre de départ, pas une liste exhaustive de chaque fonctionnalité Codex, fournisseur personnalisé, service MCP ou téléchargement de tâche.
Mihomo prend en charge un nameserver-policy spécifique au domaine et un suffixe proxy explicite sur une adresse de serveur DNS. La résolution des nœuds nécessite un chemin indépendant pour éviter une dépendance circulaire. Référence de configuration DNS
Le script ciblé conserve les paramètres de repli existants. Passez en revue séparément les dépendances DNS plus larges avant de les remplacer. Vérifiez aussi l’existence d’éventuelles correspondances hosts obsolètes ou de politiques plus spécifiques conflictuelles.
Vérifiez TUN séparément
Pour les processus qui n’utilisent pas le proxy système, activez TUN dans Clash Verge Rev et vérifiez qu’il est en cours d’exécution. Fusionnez les champs suivants dans votre objet TUN existant, en conservant ses autres paramètres :
tun:
enable: true
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
Cela couvre le DNS UDP et TCP sur le port 53. Mihomo documente des limitations pour le DNS destiné au LAN sur macOS et Windows ; le DNS chiffré géré par l’application est également en dehors de ces règles du port 53. Vérifiez le comportement du résolveur et de l’interface au lieu de supposer que le commutateur couvre chaque requête. Référence TUN
Vérifiez séparément la configuration, le routage et Codex
Commencez par vérifier la configuration finale pour détecter les erreurs, les références de groupe et l’ordre des règles. Si l’interface CLI de Mihomo est disponible, mihomo -t -f <final-config-path> vérifie si la configuration se parse. Cela ne prouve pas la connectivité.
Examinez ensuite le routage réel de la connexion et exécutez un test HTTPS avec vérification du certificat via votre véritable port local :
curl --noproxy '' --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
-o /dev/null -sS \
-w 'HTTP=%{http_code} TLS=%{time_appconnect}s TOTAL=%{time_total}s\n' \
https://chatgpt.com/
Une réponse du service visé après une vérification réussie du certificat établit un échange HTTP pour ce test. Un 401 ou un 403 peut toujours bloquer l’accès. Cela ne prouve pas qu’une requête Codex authentifiée fonctionne, et désactiver la vérification du certificat invaliderait ce contrôle.
Enfin, effectuez une petite tâche dans le client qui échouait initialement. Une CLI installée et authentifiée peut exécuter le test optionnel suivant, qui envoie une véritable requête au modèle et utilise le quota du compte :
codex exec --skip-git-repo-check --sandbox read-only \
'Reply with exactly: PONG. Do not use tools.'
La réussite dans la CLI ne vérifie que cette requête CLI ; testez l’application de bureau séparément si c’est là que l’échec s’est produit. Vérifiez à nouveau après une mise à jour d’abonnement, un changement de réseau et une mise en veille/réactivation. Des couches de configuration ultérieures ou des groupes renommés peuvent encore casser une amélioration.
Questions fréquentes
Le fait de changer le DNS système en 8.8.8.8 suffit-il ?
Pas nécessairement. Une adresse de résolveur seule n’établit ni le chiffrement, ni le routage par proxy, ni l’accessibilité. Vérifiez ensemble le résolveur, le transport et l’acheminement sortant.
Pourquoi Codex échoue-t-il pendant que Clash est en cours d’exécution ?
Le processus peut contourner le proxy, correspondre à une règle directe ou dépendre d’un DNS de nœud indisponible. Le problème peut aussi ne pas être lié au DNS. Identifiez la connexion réelle avant de modifier plusieurs paramètres à la fois.
Et si ça se déconnecte toujours ?
Si le DNS, TLS et le routage fonctionnent, examinez l’état du service, la taille de la conversation, la version du client, la stabilité de la connexion au nœud et le corps exact de l’erreur. OpenAI documente les emplacements des retours et des journaux ; vérifiez les journaux pour y repérer des secrets avant de les partager. Dépannage et journaux
Comment annuler la modification ?
Désactivez le Script ajouté et restaurez le profil sauvegardé, les paramètres TUN et tous les paramètres DNS système que vous avez modifiés. Une architecture distincte proxy-providers peut ensuite isoler les abonnements de nœuds du DNS local et des règles, mais elle n’est pas requise pour cette correction ciblée.
Pour les étapes d’installation et d’importation, voir Configuration de Clash Verge. Pour les autres échecs, voir Dépannage de Clash. Vous pouvez utiliser ce processus de diagnostic avec un abonnement compatible existant ; acheter un autre service n’est pas un prérequis pour tester le DNS.