Accueil → Aide

Les requêtes meurent à exactement 100 secondes derrière Cloudflare

Les offres Free et Pro de Cloudflare plafonnent une réponse HTTP proxifiée à 100 secondes. Si le modèle n'a pas terminé d'ici là, la connexion est coupée, quels que soient vos propres délais. Le streaming l'évite parce que des octets continuent d'arriver ; une longue génération unique sans streaming, non.

Ce que vous voyez

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

Pourquoi cela arrive

L'indice, c'est la précision. Les problèmes réseau et les délais d'origine se dispersent : ils échouent à 40 secondes une fois et à 180 la suivante. Une limite de proxy se déclenche toujours au même chiffre. Si vos échecs se regroupent autour de 100-101 secondes, arrêtez de chercher dans votre propre pile.

Elle est mesurée jusqu'au premier octet du corps de la réponse, ce qui explique pourquoi le streaming se comporte si différemment. Avec stream: true, le premier token arrive généralement en une ou deux secondes et le chronomètre n'approche jamais de la limite. Sans lui, le proxy attend la génération complète, et une longue chaîne de raisonnement ou une image 4K peuvent facilement dépasser 100 secondes.

Cela explique aussi un symptôme déroutant : côté serveur, la requête semble avoir réussi. L'amont a terminé, l'origine a journalisé un 200, les tokens ont été facturés. Seul le tronçon entre le proxy et le client a été coupé. Le journal d'utilisation de votre fournisseur montrera une requête terminée et facturée que votre client n'a jamais reçue.

Vérifiez si c'est bien la cause

Chronométrez l'échec. Le chiffre exact est le diagnostic :

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."}]}'

Environ 100s avec un 524 le confirme. Relancez la même requête avec "stream": true : si celle-ci aboutit, la limite était le seul problème.

Comment le corriger

Activez le streamingLa correction la plus efficace, et généralement un changement d'une ligne. stream: true dans le corps de la requête ; tous les grands SDK le prennent en charge. Le premier token arrive en quelques secondes, donc la fenêtre de 100 secondes ne s'ouvre jamais.
Utilisez un endpoint non proxifiéCertains fournisseurs publient un nom d'hôte d'API distinct qui contourne le CDN exactement pour cette raison. Si le vôtre en a un, dirigez-y les appels longs et laissez le site sur le nom proxifié.
Plafonnez le travail par requêteRégler max_tokens sur une valeur que le modèle peut terminer dans la fenêtre transforme une coupure invisible en arrêt prévisible. Diviser une longue génération en plusieurs appels produit le même effet et se relance plus facilement.
N'augmentez pas votre délai client en considérant le problème régléLa connexion est coupée en amont de vous. Un délai client de 300 secondes produit le même échec 200 secondes plus tard — il ne fait que rendre le symptôme plus lent à reproduire.

APICLAN publie https://api.apiclan.us/v1 exactement pour ce cas — il n'est pas derrière la limite de 100 secondes du proxy, donc les longues générations sans streaming aboutissent. L'endpoint principal https://apiclan.us/v1 convient au streaming et à tout ce qui répond rapidement.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI 401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.