Home → Assistenza

Le richieste muoiono esattamente a 100 secondi dietro Cloudflare

Cosa vedi

• error code: 524
• Requests consistently fail at 100-101 seconds, never at 90 or 120
• The same request succeeds when sent directly to the origin IP
• A streaming response stops mid-sentence with no error in the server log
• read ECONNRESET / IncompleteRead after a long pause

Perché succede

L'indizio è la precisione. I problemi di rete e i timeout dell'origine si disperdono: falliscono a 40 secondi una volta e a 180 la successiva. Un limite di proxy scatta sempre allo stesso numero. Se i tuoi errori si concentrano a 100-101 secondi, smetti di cercare nel tuo stack.

Viene misurato fino al primo byte del corpo della risposta, ed è per questo che lo streaming si comporta in modo così diverso. Con stream: true il primo token arriva di solito in un secondo o due e il cronometro non si avvicina mai al limite. Senza, il proxy aspetta l'intera generazione, e una lunga catena di ragionamento o un'immagine 4K possono facilmente superare i 100 secondi.

Questo spiega anche un sintomo che confonde: sul server la richiesta sembra riuscita. L'upstream ha finito, l'origine ha registrato un 200, i token sono stati addebitati. È stato tagliato solo il tratto tra proxy e client. Il log di utilizzo del provider mostrerà una richiesta completata e addebitata che il tuo client non ha mai ricevuto.

Verifica se la causa è questa

Cronometra l'errore. Il numero esatto è la diagnosi:

time curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' \
  'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Write a 3000 word essay."}]}'

Circa 100s con un 524 lo conferma. Riesegui la stessa richiesta con "stream": true: se quella va a termine, il limite era l'unico problema.

Come risolvere

1. Attiva lo streamingLa soluzione più efficace, e di solito una modifica di una riga. stream: true nel corpo della richiesta; tutti i principali SDK lo supportano. Il primo token arriva in pochi secondi, quindi la finestra dei 100 secondi non si apre mai.
2. Usa un endpoint non passato dal proxyAlcuni provider pubblicano un nome host API separato che aggira la CDN proprio per questo motivo. Se il tuo ce l'ha, indirizza lì le chiamate lunghe e lascia il sito sul nome con proxy.
3. Limita il lavoro per richiestaImpostare max_tokens su un valore che il modello riesce a completare entro la finestra trasforma un taglio invisibile in uno stop prevedibile. Dividere una generazione lunga in più chiamate ottiene lo stesso risultato ed è più facile da ritentare.
4. Non alzare il timeout del client pensando di aver risoltoLa connessione viene tagliata prima di arrivare a te. Un timeout client di 300 secondi produce lo stesso errore 200 secondi dopo — rende solo il sintomo più lento da riprodurre.

Articoli correlati

Ultima verifica: 2026-10-01. Scritto a partire da problemi diagnosticati su un gateway compatibile con OpenAI in produzione, non raccolto da altri siti.