AIREITERLe message upstream connect error or disconnect/reset before headers apparaît dans ChatGPT ou via l’API OpenAI ? Le problème se trouve du côté d’OpenAI. Cette erreur est générée par Envoy, le proxy placé à la périphérie de l’infrastructure d’OpenAI : il n’a pas réussi à obtenir de réponse exploitable du backend. Sur le site ChatGPT, elle est souvent accompagnée de la mention Error Code 111. Le texte qui suit reset reason: donne le diagnostic réel. Quant à before headers, il indique qu’Envoy a abandonné avant de recevoir le moindre en-tête HTTP : le 503 ne contient donc pas une réponse de l’application, mais uniquement celle d’Envoy. Vous ne pouvez pas réparer l’infrastructure d’OpenAI ; la marche à suivre dépend toutefois du motif de réinitialisation et du contexte, navigateur ou code.
Selon votre situation :
- ChatGPT sur le web ou l’app : consultez status.openai.com, puis rechargez la page ou démarrez une nouvelle session.
- API OpenAI dans votre code : relevez le motif de réinitialisation, conservez l’identifiant de requête, puis mettez en place une stratégie de retry.
Ce que cette erreur signale concrètement
Envoy s’intercale entre votre client et le backend d’OpenAI. À l’arrivée d’une requête, il établit une connexion avec ce backend, lui transmet la demande et attend les en-têtes de réponse. Si la connexion échoue, est interrompue, expire ou rencontre une limite de capacité avant le retour du moindre en-tête, Envoy renvoie ce message avec un HTTP 503, parfois un 502. On le retrouve sur les écrans d’incident de ChatGPT, dans les traces openai.InternalServerError et dans les journaux d’agents.
La formulation peut légèrement changer. La mention retried and the latest reset reason signifie qu’Envoy a déjà relancé la requête et que l’échec affiché correspond à la dernière tentative. Dans tous les cas, c’est le proxy d’OpenAI qui indique que son propre backend n’a pas répondu : votre prompt et le corps de votre requête ne sont pas en cause.
Lire le motif de réinitialisation
Le motif de réinitialisation précise ce qu’a rencontré le proxy d’OpenAI et permet de savoir si une nouvelle tentative a des chances d’aboutir.
| reset reason | Ce que le proxy d’OpenAI a rencontré | Ce que vous pouvez faire |
|---|---|---|
connection timeout | Le backend a mis trop de temps à accepter la connexion | Réessayez avec un délai progressif ; vérifiez le statut |
overflow | Une limite de capacité ou de débit a été atteinte ; le backend est surchargé | Réduisez la concurrence, espacez les tentatives, puis réessayez |
connection failure / remote connection failure | Le backend est inaccessible ou a refusé la connexion | Réessayez ; si le problème persiste, consultez le statut et signalez-le |
connection termination / connection reset | Le backend a fermé la connexion pendant la requête | Réessayez ; cela coïncide généralement avec un incident |
protocol error | Un problème de protocole côté OpenAI | Réessayez ; s’il persiste, signalez-le avec votre identifiant de requête |
overflow et connection timeout sont les deux motifs les plus fréquemment rapportés par la communauté OpenAI. C’est cohérent avec un backend qui atteint ses limites lors de pics de charge. Aucun réglage sur votre machine ne corrigera ces erreurs : les réponses utiles sont la vérification du statut, le backoff et le basculement.
Dans ChatGPT, sur le web ou l’application (Error Code 111)
Commencez par consulter status.openai.com. Si un incident est en cours, la solution consiste avant tout à attendre sa résolution ; une défaillance persistante liée à un compte donné mérite néanmoins d’être remontée au support. Si tous les voyants sont au vert, rechargez la page, ouvrez un nouvel onglet ou déconnectez-vous avant de vous reconnecter : une session obsolète peut conserver une connexion morte. Changer de réseau, désactiver un VPN ou un proxy d’entreprise ne sera utile que si cette couche interrompt elle-même la connexion. Faites le test avant de conclure à un incident OpenAI.
Depuis l’API OpenAI dans votre code
Avec l’API, l’erreur est intermittente et dépend souvent de la charge. Sur le suivi d’incidents de openai-python, un développeur a signalé qu’environ 5 % de ses appels échouaient avec openai.InternalServerError: upstream connect error or disconnect/reset before headers alors qu’il envoyait plusieurs centaines de requêtes par heure ; les 95 % restants aboutissaient. Un taux d’échec partiel de ce type évoque une saturation du backend. Les traitements par lots, comme les embeddings en masse ou l’ingestion de gros volumes de documents, y sont davantage exposés parce qu’ils augmentent la concurrence. Une politique de retry est généralement plus pertinente qu’une modification du payload, mais le contrôle de la concurrence et la mise en file des tâches volumineuses sont tout aussi importants à forte charge.
Avant de faire remonter le problème, collectez de quoi établir qu’il vient du fournisseur : l’horodatage, l’endpoint et le modèle, le statut HTTP et le corps de réponse, le x-request-id, la version du SDK, le nombre de requêtes en cours et la correspondance éventuelle avec un incident publié. Appliquez ensuite une stratégie de retry adaptée à la production :
import random, time
from openai import OpenAI, APIStatusError, APIConnectionError
client = OpenAI()
def with_retry(fn, max_attempts=5, cap=30.0):
for attempt in range(max_attempts):
try:
return fn()
except (APIConnectionError, APIStatusError) as e:
status = getattr(e, "status_code", None)
# retry connection drops and 5xx (incl. this 503); never blindly retry 4xx
if isinstance(e, APIStatusError) and status and status < 500 and status != 429:
raise
if attempt == max_attempts - 1:
raise
retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
backoff = retry_after or min(cap, 0.5 * 2 ** attempt) * (0.5 + random.random())
time.sleep(backoff)Les SDK OpenAI relancent déjà eux-mêmes les erreurs transitoires, via max_retries, dont la valeur par défaut est 2. Configurez donc ce paramètre explicitement — par exemple avec OpenAI(max_retries=0) — avant d’ajouter votre propre couche, faute de quoi les deux mécanismes se cumuleront. Limitez le nombre total de tentatives, entre 3 et 5, ainsi que la concurrence globale afin que les retries n’amplifient pas le pic à l’origine du overflow. Pour un 429, respectez le champ Retry-After ; ne relancez un 408/409 que si l’opération peut être répétée sans risque. Prudence également avec les appels non idempotents ou en streaming : un retry aveugle peut dupliquer un traitement ou rejouer un flux déjà partiellement consommé.
Ce que le client voit réellement
Vous ne verrez pas toujours le corps du 503 d’Envoy : la connexion peut mourir avant. Un curl -v vers un endpoint indisponible renvoie alors curl: (52) Empty reply from server après Request completely sent off : la requête est bien partie, mais rien n’est revenu. Lorsque Envoy parvient à répondre, il retourne son propre 503 avec le texte upstream connect error... dans le corps. Les signalements publics vont dans le même sens : sur le subreddit OpenAI, un utilisateur a publié la chaîne exacte retried and the latest reset reason: connection timeout avec « Network connection lost », tandis que le suivi openai-python mentionne le même message sous forme d’InternalServerError lors d’un volume élevé de requêtes.
Quand contourner l’incident
Puisque le maillon défaillant se situe entre la passerelle d’OpenAI et son backend, vos seuls leviers face à un endpoint unique sont les retries et le backoff. L’autre option est la redondance : passer par une couche capable de basculer vers un backend différent lorsqu’un upstream expire ou déborde. Des passerelles multi-fournisseurs comme OpenRouter et AIReiter placent plusieurs fournisseurs de modèles derrière une même interface et contournent un fournisseur lent. C’est le même modèle de routage multi-fournisseurs sur lequel repose OpenRouter : un upstream qui ralentit peut déclencher un reroutage plutôt qu’un 503 visible. Le compromis est réel : un saut supplémentaire, une dépendance à la disponibilité du routeur lui-même, ainsi que des différences de prix, de traitement des données et d’observabilité à évaluer. Cette approche réduit néanmoins votre exposition à l’instabilité d’un seul fournisseur.
FAQ
Qu’est-ce que ChatGPT Error Code 111 ?
Certains utilisateurs de ChatGPT voient ce message accompagné de la mention « Error Code 111 ». Cela signifie que le proxy d’OpenAI n’a pas réussi à obtenir de réponse de son backend : c’est un problème côté serveur. Consultez status.openai.com, puis rechargez la page.
Pourquoi cette erreur n’apparaît-elle que sous charge ou de façon aléatoire ?
Les échecs liés à la charge indiquent généralement un overflow, c’est-à-dire une limite de capacité ou de débit, ou une saturation du backend qui fait dépasser le délai de connexion. Ces situations ne surviennent que lorsque la concurrence augmente, d’où un code qui fonctionne la plupart du temps.
Un VPN ou un pare-feu peut-il provoquer cette erreur ?
Uniquement si cette couche interrompt la connexion entre vous et OpenAI. Il est utile de l’écarter en changeant de réseau, mais cela ne résoudra ni une véritable panne d’OpenAI ni un 503 côté API.
Est-ce la même chose qu’une erreur de limite de débit 429 ?
Non. Un 429 est une réponse explicite de limitation que vous avez reçue. Ce 503 signifie qu’aucune réponse exploitable n’est revenue. Respectez Retry-After pour un 429 ; utilisez un backoff et réessayez pour le 503.
Que signifie « retried and the latest reset reason » ?
Envoy a déjà retenté la requête, et ce message explique pourquoi la dernière tentative a échoué. Il pointe vers un problème persistant du backend côté OpenAI, plutôt que vers un incident isolé.