¿La carga falla? Soluciona errores comunes de transferencia

Una carga fallida casi siempre cae en una de estas cinco categorías: inestabilidad de red (corte de Wi-Fi, redirección del ISP), agotamiento de memoria del navegador (Chrome matando una pestaña al llegar a 2 GB de RAM), limitación de velocidad o cuota del servicio, archivo de origen corrupto, o antivirus/firewall bloqueando las solicitudes salientes. Empieza revisando la pestaña Red de DevTools para ver el código HTTP real de la solicitud fallida. Un 413 es "payload demasiado grande". Un 502 o 503 es el servicio. Un "ERR_CONNECTION_RESET" es tu red. Cada uno tiene una solución diferente.

Lee el error real, no el mensaje genérico

La mayoría de las interfaces de carga muestran "Carga fallida" y ahí queda. Eso no sirve de nada. Abre DevTools en el navegador (F12 o Cmd+Opción+I), ve a la pestaña Red y observa la solicitud fallida. El código de estado te dice dónde está el problema: la serie 400 es tu lado (413 demasiado grande, 401 autenticación, 403 prohibido), la serie 500 es su lado (502 bad gateway, 503 ralentizar, 504 timeout). Los errores de conexión como ERR_CONNECTION_RESET o net::ERR_NETWORK_CHANGED indican que la conexión TCP murió durante la transferencia.

Haz una captura de pantalla de la solicitud fallida y sus cabeceras de respuesta antes de cerrar nada. Si escalas al soporte técnico, esas cabeceras suelen identificar el problema con precisión.

Wi-Fi que corta en silencio

Los chips Wi-Fi del portátil hacen roaming entre puntos de acceso y entre bandas (2,4 GHz y 5 GHz) de forma automática. Cada roaming corta la conexión TCP durante una fracción de segundo, lo que mata una carga de flujo único. Los servicios que implementan cargas fragmentadas reanudables (basados en tus.io, S3 multipart) sobreviven a esto; las cargas de un único POST no.

Si puedes conectar por cable Ethernet, hazlo. Ethernet no hace roaming. Si no puedes, al menos quédate en la misma habitación y desactiva el cambio automático de SSID o la dirección de banda del sistema de malla durante la carga. Ejecuta un ping continuo a 1.1.1.1 en otra terminal y observa las interrupciones; ahí es donde mueren tus cargas.

Cierres del navegador y expulsión de pestañas

Chrome mata las pestañas cuando superan un umbral de memoria, normalmente entre 2 y 4 GB por pestaña según la RAM disponible. Cargar un archivo de 10 GB a través de un navegador que almacena todo en memoria antes de enviarlo (mala implementación) superará ese límite con creces. Cargar a través de uno que transmite en fragmentos (buena implementación, usando el método slice() de la File API) usa unos pocos cientos de MB de RAM independientemente del tamaño del archivo.

Si el navegador se cierra continuamente en cargas grandes, prueba Firefox, que históricamente gestiona cargas de File API grandes con menos presión de memoria que Chromium. Asegúrate de que el servicio usa cargas fragmentadas; si un archivo de 5 GB se carga en un único Blob antes del POST, ese es el problema de diseño.

Cierra todas las demás pestañas. Reinicia el navegador antes de empezar. Desactiva las extensiones —los bloqueadores de anuncios, las extensiones de privacidad y los gestores de contraseñas a veces se inyectan en los flujos de carga y los rompen.

Cortafuegos corporativos y proxies

Las redes corporativas suelen ejecutar inspección profunda de paquetes, moldeado de tráfico o servidores proxy que inyectan certificados. Síntomas: las cargas funcionan con archivos pequeños pero fallan a partir de un tamaño específico (a menudo 100 MB o 1 GB), o el error indica "SSL handshake failed" o "certificate verification failed".

Compruébalo cargando desde el punto de acceso móvil (fuera de la red corporativa). Si funciona ahí, el problema está en tu lado. Opciones: pide al departamento de IT que añada a la lista blanca el endpoint de carga del servicio, usa una VPN (si está permitido) para evitar el limitador, o pasa a una red personal.

Zscaler, Cisco Umbrella y los dispositivos Palo Alto son culpables habituales. A menudo inspeccionan archivos por encima de un umbral de tamaño y agotan el tiempo de espera con flujos grandes.

El antivirus escanea el flujo saliente

Windows Defender, Bitdefender, Norton y Kaspersky pueden escanear el tráfico HTTPS saliente interceptando TLS. En cargas grandes, el propio escaneo puede reducir el rendimiento entre un 40 y un 60 por ciento, y en algunas versiones introduce timeouts que matan la conexión.

Desactiva temporalmente la protección web en tiempo real (no el antivirus completo, solo el componente de inspección HTTPS) y vuelve a intentarlo. Si la carga se completa, añade el dominio del servicio de transferencia a la lista de exclusiones del AV. No dejes la protección web desactivada de forma permanente.

Límites de velocidad del servicio

Si estás recibiendo respuestas 429 o 503, el servicio te está limitando. Posibles razones: estás ejecutando demasiados fragmentos en paralelo (reduce a 4 trabajadores en lugar de 8), has alcanzado una cuota diaria del nivel gratuito (WeTransfer gratuito limita a 2 GB por transferencia y tiene límites de volumen diario implícitos), o estás en una IP compartida que ha sido marcada (habitual en Wi-Fi de hoteles y cafeterías abusadas).

Espera 15 minutos y vuelve a intentarlo. O cambia de red. O cambia de servicio.

Archivo de origen corrupto

En raras ocasiones, el archivo en sí es el problema. La corrupción del sistema de archivos (sector defectuoso en un disco externo, copia interrumpida) produce un archivo que se lee bien durante los primeros megabytes y devuelve errores de E/S a partir de ese punto. La carga se detiene en un porcentaje consistente en cada reintento.

Prueba copiando primero el archivo a un disco local diferente. Si la copia falla en el mismo porcentaje, el problema es el origen. Ejecuta chkdsk en Windows o diskutil verifyDisk en macOS en la unidad de origen. Para archivos críticos, recupéralos de una copia conocida en buen estado antes de intentar cargarlos de nuevo.

Errores de fecha, hora y certificado TLS

Si el reloj del sistema está desajustado en más de unos minutos, la validación del certificado TLS falla y las cargas dan error con "certificate not yet valid" o similar. Los Mac y Windows suelen sincronizarse automáticamente por NTP, pero tras un sueño prolongado o una placa base sin batería, los relojes se desvían.

Fuerza una sincronización NTP: sntp -sS time.apple.com en macOS, o Configuración > Hora e idioma > Fecha y hora > Sincronizar ahora en Windows.

VPNs que fallan en silencio

Algunos clientes VPN (especialmente los gratuitos) cortan las conexiones TCP de larga duración tras 5 a 10 minutos porque sus tokens de sesión se renuevan. Una carga de 2 GB que tarda 20 minutos muere en la renovación del token, silenciosamente. O cambia a una VPN de pago con mejor gestión de sesión (Mullvad, ProtonVPN, IVPN), o desconecta la VPN durante las cargas si el servicio ya está cifrado de extremo a extremo con TLS.

Los servicios cifrados de extremo a extremo significan que no necesitas la VPN para la confidencialidad durante la propia transferencia. HexaTransfer, por ejemplo, cifra con AES-256-GCM en el lado del cliente antes de que el archivo salga de tu navegador, por lo que añadir el cifrado VPN encima es una capa adicional, no imprescindible.

Prueba un servicio que reintente fragmentos automáticamente

Si has corregido los problemas locales obvios y las cargas siguen fallando, es posible que el servicio en sí no gestione bien las interrupciones. Un servicio con reintento automático por fragmento y estado de sesión reanudable sigue funcionando a través de los tipos de cortes —un roaming de Wi-Fi, una breve redirección del ISP— que matan a los cargadores de flujo único. HexaTransfer ejecuta cargas fragmentadas en paralelo con reintento por fragmento y sobrevive a la mayoría de eventos de red breves sin ninguna intervención manual.

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