Inicio → Ayuda

Las peticiones mueren exactamente a los 100 segundos detrás de Cloudflare

Los planes Free y Pro de Cloudflare limitan una respuesta HTTP proxificada a 100 segundos. Si el modelo no ha terminado para entonces, la conexión se corta, digan lo que digan tus propios timeouts. El streaming lo evita porque siguen llegando bytes; una única respuesta larga sin streaming, no.

Lo que ves

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

Por qué ocurre

La pista es la precisión. Los problemas de red y los timeouts del origen se dispersan: fallan a los 40 segundos una vez y a los 180 la siguiente. Un límite de proxy salta siempre en el mismo número. Si tus fallos se agrupan en 100-101 segundos, deja de mirar tu propia pila.

Se mide hasta el primer byte del cuerpo de la respuesta, y por eso el streaming se comporta tan distinto. Con stream: true el primer token suele llegar en uno o dos segundos y el reloj nunca se acerca al límite. Sin él, el proxy espera la respuesta completa, y una cadena de razonamiento larga o una imagen 4K pueden superar fácilmente los 100 segundos.

Esto también explica un síntoma confuso: en el servidor la petición parece haber tenido éxito. El upstream terminó, el origen registró un 200, los tokens se facturaron. Solo se cortó el tramo entre el proxy y el cliente. El registro de uso de tu proveedor mostrará una petición completada y cobrada que tu cliente nunca recibió.

Comprueba si es esta la causa

Cronometra el fallo. El número exacto es el diagnóstico:

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

Alrededor de 100s con un 524 lo confirma. Ejecuta la misma petición con "stream": true: si esa termina, el límite era lo único que fallaba.

Cómo solucionarlo

Activa el streamingLa solución más eficaz, y normalmente un cambio de una línea. stream: true en el cuerpo de la petición; todos los SDK importantes lo admiten. El primer token llega en segundos, así que la ventana de 100 segundos nunca llega a abrirse.
Usa un endpoint que no esté proxificadoAlgunos proveedores publican un nombre de host de API aparte que evita la CDN precisamente por esto. Si el tuyo lo tiene, apunta allí las llamadas largas y deja la web en el nombre proxificado.
Limita el trabajo por peticiónFijar max_tokens en algo que el modelo pueda terminar dentro de la ventana convierte un corte invisible en una parada predecible. Dividir una generación larga en varias llamadas hace lo mismo y es más fácil de reintentar.
No subas el timeout de tu cliente y lo des por arregladoLa conexión se corta antes de llegar a ti. Un timeout de cliente de 300 segundos produce el mismo fallo 200 segundos más tarde — solo hace que el síntoma tarde más en reproducirse.

APICLAN publica https://api.apiclan.us/v1 precisamente para este caso — no está detrás del límite de 100 segundos del proxy, así que las respuestas largas sin streaming terminan. El endpoint principal https://apiclan.us/v1 sirve para streaming y para todo lo que responde rápido.

Relacionado

Unexpected token '<' al llamar a una API compatible con OpenAI 401 invalid API key: cuando la clave parece correcta pero sigue fallando

Revisado por última vez el 2026-10-01. Escrito a partir de problemas diagnosticados en una pasarela compatible con OpenAI en producción, no recopilado de otras webs.