Errores de tiempo de espera en transferencia: causas y soluciones

Los errores de timeout durante transferencias de archivos provienen de uno de estos cuatro lugares: la solicitud HTTP del cliente esperó demasiado tiempo para que el servidor respondiera (normalmente de 30 a 120 segundos), el servidor esperó demasiado tiempo para que el cliente enviara datos (habitual en cargas lentas), un proxy intermedio o balanceador de carga cortó la conexión (el valor predeterminado de AWS ALB es 60 segundos), o el sistema operativo mató una conexión TCP inactiva. 504 Gateway Timeout significa que el balanceador de carga no pudo llegar al origen. 408 Request Timeout significa que el servidor se rindió esperando tus datos. ERR_CONNECTION_TIMED_OUT significa que el handshake TCP nunca se completó. Cada uno tiene una corrección distinta.

Lee el tipo de timeout en el error

Los distintos timeouts necesitan correcciones diferentes:

• 504 Gateway Timeout: El proxy intermedio o balanceador de carga agotó el tiempo. Problema del lado del servicio, normalmente transitorio. Reintenta o cambia de región.
• 408 Request Timeout: El servidor se rindió esperando los datos del cliente. Tu carga se detuvo a mitad de solicitud.
• 524 (Cloudflare): El origen no respondió en 100 segundos. Lado del servicio.
• 502 Bad Gateway: El proxy recibió una respuesta inválida del origen. Interrupción del servicio o despliegue en progreso.
• ERR_CONNECTION_TIMED_OUT: Tu conexión TCP al servidor nunca se completó. Red o cortafuegos.
• ERR_NETWORK_CHANGED: Tu red cambió a mitad de conexión. Roaming de Wi-Fi o desconexión de VPN.

La pestaña Red de DevTools muestra la respuesta exacta, el tiempo y el código de estado. Haz una captura antes de cerrar nada.

El roaming de Wi-Fi mata las cargas largas

Los chips Wi-Fi de los portátiles cambian entre bandas y puntos de acceso automáticamente. Cada cambio corta la conexión TCP actual. Las cargas de flujo único mueren de inmediato; las cargas fragmentadas sobreviven si el servicio reintenta por fragmento.

Solución: conecta por cable Ethernet para cargas de más de 2 GB. Si no puedes, desactiva la dirección de banda en tu router (ponlo en "solo 5 GHz" para el SSID del portátil) y quédate en una habitación. En macOS, desactiva "Unirse automáticamente" para todos los SSID menos el principal para evitar buscar señales más fuertes a mitad de carga.

Timeouts del balanceador de carga en el lado del servicio

El tiempo de inactividad predeterminado del AWS Application Load Balancer es de 60 segundos. Nginx tiene por defecto proxy_read_timeout de 60 segundos. Los servicios que no han ajustado estos valores cortan las cargas que se detienen brevemente (por cifrado, por una lectura lenta del disco en el origen) al llegar a la marca de los 60 segundos.

Si ves timeouts 504 en un servicio concreto, normalmente es su balanceador de carga mal configurado. No hay nada que puedas hacer en el lado del cliente más allá de reintentar. Los cargadores fragmentados gestionan esto de forma transparente reintentando el fragmento fallido; los cargadores de flujo único fallan completamente y debes empezar de nuevo.

Timeouts del proxy corporativo

Zscaler, Blue Coat, Palo Alto y otros proxies corporativos aplican sus propios timeouts, normalmente de 30 segundos a 5 minutos de inactividad. Si tu carga está haciendo algo que el proxy percibe como inactividad (pausa de cifrado, retraso de reintento de fragmento), el proxy mata la conexión.

Diagnostica cargando fuera de la red corporativa (punto de acceso del móvil). Si los timeouts desaparecen, el proxy es la causa. Pide a IT que añada el dominio del servicio de transferencia a la lista blanca y omita la inspección para esos dominios. La alternativa es red personal o túnel VPN a casa.

Keepalive TCP a nivel del sistema operativo

Linux por defecto envía paquetes keepalive TCP solo después de 2 horas de inactividad, lo que es inútil para la transferencia de archivos. macOS y Windows tienen valores predeterminados similares. Para cargas muy largas en redes inestables, algunos servicios implementan keepalive a nivel de aplicación mediante tramas de ping WebSocket o fragmentos periódicos vacíos. Si el servicio no lo hace, las cargas largas a través de un cortafuegos NAT (tiempo de espera predeterminado de la sesión UDP de 5 minutos en la mayoría de routers domésticos) pueden romperse cuando la entrada NAT caduca.

Renovación del token de sesión de VPN

Algunos clientes VPN renuevan los tokens de sesión cada 5 a 15 minutos. En clientes con bugs, la renovación corta el túnel TCP subyacente durante medio segundo. Las cargas largas mueren entonces.

Las VPN de pago (Mullvad, ProtonVPN Plus, IVPN) gestionan esto limpiamente. Las VPN gratuitas a menudo no. Si ves timeouts consistentes a la marca de los 10 minutos, sospecha de la renovación de VPN. Desconecta la VPN para la carga si el servicio de transferencia ya usa cifrado de extremo a extremo con TLS 1.3.

Traspasos de red móvil

Los datos móviles cambian de celda al moverte. Cada traspaso o (a) mantiene la IP mediante gestión de movilidad (transparente) o (b) asigna una nueva IP (la conexión se corta). En LTE, la mayoría de traspasos son transparentes. En 5G, especialmente mmWave, los traspasos a sub-6 o LTE de respaldo pueden cambiar la IP y matar las conexiones.

Si estás cargando desde un vehículo en movimiento con datos móviles, espera cortes. Los cargadores fragmentados con reanudación los gestionan bien; los cargadores de flujo único no.

Timeouts de mod_security y WAF

Si un servicio está detrás de un Web Application Firewall (WAF de Cloudflare, WAF de AWS, ModSecurity), el WAF puede marcar una carga de larga duración como sospechosa y cortarla. Síntomas: las cargas funcionan con tamaños pequeños, fallan a partir de un umbral específico (a menudo 1 GB o 10 GB según la configuración del WAF), con respuestas 403 o 502.

No hay nada que puedas corregir en el lado del cliente. Informa al servicio. Un WAF bien configurado permite cargas fragmentadas sin marcarlas.

Timeouts predeterminados del navegador

Los navegadores también tienen timeouts de solicitud, aunque suelen ser generosos para las cargas. Chrome y Firefox dan a las solicitudes XHR y fetch tiempo ilimitado por defecto, pero sí terminan las conexiones inactivas después de 5 minutos en algunas configuraciones. Los Service Workers pueden interceptar y ampliar los timeouts.

Si el JavaScript del propio servicio establece xhr.timeout = 30000 (30 segundos) por fragmento, los fragmentos lentos fallan. Esto es un bug del lado del servicio; repórtalo.

Antivirus inspeccionando el tráfico HTTPS

Windows Defender con "inspección HTTPS" activada, Norton, Bitdefender y similares hacen MITM de las conexiones HTTPS para escanear el contenido. En cargas grandes, el propio escaneo añade latencia que puede empujar los fragmentos más allá de los timeouts del lado del servidor.

Desactiva la inspección HTTPS temporalmente (no el AV completo, solo el escaneo HTTPS) durante las cargas grandes. Si las cargas tienen éxito, añade el servicio de transferencia a la lista de exclusiones del AV de forma permanente.

Lógica de reintento y backoff exponencial

Los clientes de transferencia bien construidos reintentan los fragmentos fallidos con backoff exponencial: 1 segundo, luego 2, luego 4, luego 8. Un breve corte de red se recupera de forma transparente. Los clientes sin lógica de reintento fallan en el primer error.

Si usas un servicio que no reintenta automáticamente, verás más fallos inducidos por timeouts. Elige un cliente o servicio que gestione los reintentos por ti.

Simplemente inténtalo de nuevo después de 15 minutos

Algunos timeouts son transitorios: un fallo de un nodo de Cloudflare, un despliegue del servicio, un enlace de tránsito congestionado. Reintenta a los 15 minutos antes de escalar. Si falla de nuevo, cambia a una red diferente para aislar si el problema es tuyo o del servicio.

Elige un servicio con reintento robusto

Para archivos grandes sobre redes poco fiables, lo que necesitas es un servicio con reintento por fragmento, estado de sesión reanudable y sin timeout agresivo en el lado del servidor. HexaTransfer ejecuta cargas fragmentadas en paralelo con reintento por fragmento y cifrado AES-256-GCM en el lado del cliente, por lo que una carga de 10 GB sobre una conexión inestable reintenta los fragmentos afectados de forma transparente en lugar de fallar toda la transferencia en un único fallo de red.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.