Se visualizzi upstream connect error or disconnect/reset before headers su ChatGPT o tramite l'OpenAI API, il problema è lato OpenAI. Il messaggio proviene da Envoy, il proxy al bordo di OpenAI, e significa che Envoy non è riuscito a ottenere una risposta utilizzabile dal backend di OpenAI. Sul sito di ChatGPT questo è spesso indicato come *Error Code 111*. Il testo dopo reset reason: è la diagnosi effettiva e before headers significa che il proxy ha rinunciato prima che arrivasse anche solo un header di risposta — quindi dietro quel 503 non c'è una risposta reale, ma solo quella di Envoy. Non puoi correggere l'infrastruttura di OpenAI, ma ciò che fai dopo dipende dal reset reason e dal fatto che l'errore si verifichi nel browser o nel codice.
Quale percorso stai seguendo:
- ChatGPT web/app: controlla status.openai.com, poi ricarica o avvia una nuova sessione.
- OpenAI API in code: leggi il motivo del reset, acquisisci l'ID della richiesta, quindi applica una policy di retry.
Cosa significa davvero l'errore
Envoy si trova tra te e il backend di OpenAI. Quando arriva la tua richiesta, Envoy apre una connessione al backend, inoltra la richiesta e attende le intestazioni della risposta. Se quella connessione fallisce, viene reimpostata, va in timeout o supera un limite di capacità prima che arrivino le intestazioni, Envoy restituisce questo messaggio con un HTTP 503 (a volte 502). Compare nelle schermate di interruzione di ChatGPT, nelle stack trace di openai.InternalServerError e nei log degli agenti.
La formulazione varia: la dicitura retried and the latest reset reason significa che Envoy ha già effettuato un retry e che questo è stato l'errore del tentativo finale. In ogni caso, è il proxy di OpenAI che segnala che il proprio backend non ha risposto — non è un problema del tuo prompt o del corpo della tua richiesta.
Decodifica il motivo del reset
Il motivo del reset ti dice cosa ha incontrato il proxy di OpenAI e quindi se vale la pena riprovare.
| motivo del reset | Ciò che ha colpito il proxy di OpenAI | Ciò che puoi fare |
|---|---|---|
connection timeout | Il backend era troppo lento per accettare la connessione in tempo | Riprova con backoff; controlla lo stato |
overflow | È stato raggiunto un limite di capacità o di velocità (backend sovraccarico) | Riduci la concorrenza, fai backoff, poi riprova |
connection failure / remote connection failure | Backend non raggiungibile o connessione rifiutata | Riprova; se persiste, controlla lo stato e segnala |
connection termination / connection reset | Il backend ha chiuso la connessione a metà richiesta | Riprova; di solito coincide con un incidente |
protocol error | Un problema di protocollo dal lato di OpenAI | Riprova; segnala con il tuo ID richiesta se persiste |
overflow e connection timeout sono i due che ricorrono più spesso nei report della community OpenAI, il che è coerente con un backend che raggiunge la capacità sotto carichi a raffica. Nessuno di questi si risolve con qualcosa sul tuo computer — le risposte utili sono controlli dello stato, backoff e failover.
Sul sito web o sull'app di ChatGPT (Codice di errore 111)
Controlla prima status.openai.com. Se è pubblicato un incidente, aspettare è la soluzione principale, anche se un guasto persistente specifico dell’account merita di essere segnalato al supporto. Se lo stato è verde, ricarica la pagina, apri una nuova scheda oppure esci e accedi di nuovo — una sessione obsoleta può mantenere una connessione morta. Cambiare rete o disattivare una VPN o un proxy aziendale aiuta solo se è proprio quel livello a reimpostare la connessione, quindi prova prima di dare per scontato che sia OpenAI.
Dall'API di OpenAI nel codice
Qui l'errore è intermittente e dipendente dal carico. Uno sviluppatore sul tracker dei problemi di openai-python ha segnalato circa il 5% delle chiamate in errore con openai.InternalServerError: upstream connect error or disconnect/reset before headers أثناء l'esecuzione di centinaia di richieste all'ora — l'altro 95% ha avuto esito positivo. Un tasso di errore parziale di questo tipo indica una saturazione del backend, e i job con forte uso di batch (embedding in massa, ingestione di grandi documenti) lo colpiscono di più perché aumentano la concorrenza. La correzione è di solito una policy di retry piuttosto che una modifica del payload, anche se modellare la concorrenza e accodare i job bulk conta altrettanto quando il carico è elevato.
Prima di inoltrare l’escalation, raccogli abbastanza elementi per dimostrare che il problema è lato provider: il timestamp, l’endpoint e il modello, lo stato HTTP e il body, il x-request-id, la tua versione SDK, il numero di richieste in corso e se i guasti coincidono con un incidente pubblicato. Quindi applica una policy di retry che regga in produzione:
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)
# ritenta per interruzioni di connessione e 5xx (incluso questo 503); non ritentare mai ciecamente i 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)Gli SDK di OpenAI ritentano già autonomamente gli errori transitori (max_retries, predefinito 2), quindi impostalo deliberatamente — ad esempio OpenAI(max_retries=0) — prima di avvolgere le chiamate, altrimenti il tuo livello e quello dell'SDK si sommeranno. Limita il numero totale di tentativi (3–5) e la concorrenza complessiva, così i retry non amplificheranno il picco che ha causato l'overflow. Gestisci 429 in base al suo Retry-After; ritenta 408/409 solo quando l'operazione è sicura da ripetere. Fai attenzione alle chiamate non idempotenti o in streaming — un retry alla cieca può duplicare il lavoro o riprodurre uno stream consumato solo in parte.
Come appare dal lato del cliente
Spesso non vedi nemmeno il corpo del 503 di Envoy — prima si interrompe la connessione. Un curl -v verso un endpoint non attivo restituisce curl: (52) Empty reply from server dopo Request completely sent off: la richiesta è partita, non è tornato nulla. La versione dell'errore di Envoy è un 503 che riporta il testo upstream connect error... come corpo. Le segnalazioni pubbliche coincidono: nel subreddit di OpenAI un utente ha pubblicato la stringa esatta retried and the latest reset reason: connection timeout con "Network connection lost," e il tracker di openai-python riporta lo stesso messaggio come InternalServerError sotto alto volume di richieste.
Quando aggirarlo
Poiché il salto che va in errore è tra il gateway di OpenAI e il suo backend, ritentare e applicare un backoff è tutto ciò che puoi fare contro un singolo endpoint. L’altra leva è la ridondanza: instradare tramite un livello che effettua il failover verso un backend diverso quando un upstream va in timeout o va in overflow. Gateway multi-provider come OpenRouter e AIReiter si pongono davanti a diversi provider di modelli e aggirano quello lento, lo stesso modello di routing multi-provider su cui si basa OpenRouter, così un singolo upstream che rallenta può trasformarsi in un reindirizzamento invece che in un 503 esposto. Il compromesso è reale — un salto aggiuntivo, una dipendenza dalla disponibilità del router stesso e differenze in termini di prezzi, gestione dei dati e osservabilità da valutare — ma riduce l’esposizione all’instabilità di un singolo provider.
FAQ
Che cos'è il codice di errore 111 di ChatGPT?
Alcuni utenti di ChatGPT segnalano di vedere questo messaggio insieme all'etichetta "Error Code 111." Significa che il proxy di OpenAI non è riuscito a ottenere una risposta dal suo backend — un problema lato server. Controlla status.openai.com e ricarica.
Perché lo ottengo solo sotto carico o in modo casuale?
I guasti dipendenti dal carico di solito significano overflow (un limite di capacità o di velocità) oppure una saturazione del backend che porta i tempi di connessione oltre il timeout. Entrambi compaiono solo quando la concorrenza aumenta, motivo per cui lo stesso codice funziona per lo più la maggior parte delle volte.
Un VPN o un firewall lo causa?
Solo se quel livello è ciò che sta resettando la connessione tra te e OpenAI. Vale la pena escluderlo passando ad altre reti, ma non risolverà un vero disservizio di OpenAI o un 503 lato API.
È la stessa cosa di un errore di limitazione della frequenza 429?
No. Un 429 è una risposta esplicita di limite di frequenza che hai ricevuto. Questo 503 significa che non è arrivata alcuna risposta utilizzabile. Rispetta Retry-After su un 429; applica un backoff e riprova sul 503.
Cosa significa "ritentato e l'ultimo motivo di reset"?
Envoy ha già ritentato la richiesta, ed è per questo che l’ultimo tentativo è fallito. Ciò indica un problema persistente del backend lato OpenAI, non un intoppo isolato.