Erros de timeout na transferência de ficheiros: causas e soluções

Os erros de timeout durante transferências de ficheiros provêm de um de quatro lugares: o pedido HTTP do cliente esperou demasiado pela resposta do servidor (tipicamente 30 a 120 segundos), o servidor esperou demasiado que o cliente enviasse dados (comum em carregamentos lentos), um proxy ou balanceador de carga intermediário cortou a ligação (o padrão do AWS ALB é 60 segundos), ou o sistema operativo eliminou uma ligação TCP inativa. 504 Gateway Timeout significa que o balanceador de carga não conseguiu alcançar a origem. 408 Request Timeout significa que o servidor desistiu de aguardar os seus dados. ERR_CONNECTION_TIMED_OUT significa que o handshake TCP nunca foi concluído. Cada um tem uma solução distinta.

Identifique o tipo de timeout pelo erro

Timeouts diferentes requerem soluções diferentes:

• 504 Gateway Timeout: proxy ou balanceador de carga intermediário esgotou o tempo. Problema do lado do serviço, geralmente transitório. Tente novamente ou mude de região.
• 408 Request Timeout: o servidor desistiu de aguardar dados do cliente. O seu carregamento ficou parado no meio do pedido.
• 524 (Cloudflare): a origem não respondeu em 100 segundos. Problema do serviço.
• 502 Bad Gateway: o proxy recebeu uma resposta inválida da origem. Interrupção do serviço ou deploy em curso.
• ERR_CONNECTION_TIMED_OUT: a sua ligação TCP ao servidor nunca foi concluída. Rede ou firewall.
• ERR_NETWORK_CHANGED: a sua rede mudou a meio da ligação. Roaming de Wi-Fi ou desconexão de VPN.

O separador Rede do DevTools mostra a resposta exata, o timing e o código de estado. Tire uma captura de ecrã antes de fechar qualquer coisa.

O roaming de Wi-Fi mata os carregamentos longos

Os chips Wi-Fi dos portáteis trocam automaticamente entre bandas e pontos de acesso. Cada troca interrompe a ligação TCP atual. Os carregamentos de fluxo único morrem imediatamente; os carregamentos em chunks sobrevivem se o serviço repetir por chunk.

Solução: use Ethernet por cabo para carregamentos acima de 2 GB. Se não for possível, desative o band-steering no router (mude para "5 GHz apenas" para o SSID do portátil) e fique numa única divisão. No macOS, desative "Aderir automaticamente" para todos os SSIDs exceto o principal para evitar que o sistema procure sinais mais fortes a meio do carregamento.

Timeouts do balanceador de carga do lado do serviço

O AWS Application Load Balancer tem um timeout de inatividade padrão de 60 segundos. O Nginx usa por defeito proxy_read_timeout de 60 segundos. Os serviços que não ajustaram estas configurações corretamente cortam os carregamentos que fazem uma pausa breve (para encriptação, para uma leitura lenta do disco na origem) ao fim dos 60 segundos.

Se vir timeouts 504 num serviço específico, é geralmente o balanceador de carga mal configurado. Não há nada a fazer do lado do cliente além de tentar novamente. Os carregamentos em chunks lidam com isto de forma transparente ao repetir o chunk falhado; os carregamentos de fluxo único falham completamente e precisa de recomeçar.

Timeouts de proxy empresarial

Zscaler, Blue Coat, Palo Alto e outros proxies empresariais impõem os seus próprios timeouts, geralmente de 30 segundos a 5 minutos de inatividade. Se o seu carregamento fizer algo que o proxy interpreta como inativo (pausa de encriptação, atraso de tentativa de chunk), o proxy corta a ligação.

Diagnostique carregando fora da rede empresarial (hotspot do telemóvel). Se os timeouts desaparecerem, o proxy é a causa. Peça ao departamento de TI que adicione o domínio do serviço de transferência à lista de permissões e ignore a inspeção para esses domínios. A alternativa é usar a rede pessoal ou um túnel VPN para casa.

TCP keepalive ao nível do sistema operativo

O Linux envia por defeito pacotes TCP keepalive apenas após 2 horas de inatividade, o que é inútil para transferência de ficheiros. O macOS e o Windows têm valores predefinidos semelhantes. Para carregamentos muito longos em redes instáveis, alguns serviços implementam keepalive ao nível da aplicação via frames de ping WebSocket ou chunks vazios periódicos. Se o serviço não o fizer, os carregamentos longos através de uma firewall NAT (timeout de sessão padrão de 5 minutos na maioria dos routers domésticos) podem interromper quando a entrada NAT expirar.

Renovação do token de sessão da VPN

Alguns clientes VPN renovam os tokens de sessão a cada 5 a 15 minutos. Em clientes com erros, a renovação interrompe o túnel TCP subjacente durante meio segundo. Os carregamentos longos morrem nesse momento.

As VPNs pagas (Mullvad, ProtonVPN Plus, IVPN) lidam com isto de forma limpa. As VPNs gratuitas frequentemente não. Se estiver a ver timeouts consistentes ao fim dos 10 minutos, suspeite da renovação da VPN. Desative a VPN durante o carregamento se o serviço de transferência já usa encriptação de ponta a ponta com TLS 1.3.

Handoffs de rede móvel

Os dados móveis trocam de célula conforme se move. Cada handoff ou (a) mantém o IP via gestão de mobilidade (transparente) ou (b) atribui um novo IP (a ligação cai). Em LTE, a maioria dos handoffs é transparente. Em 5G, especialmente mmWave, os handoffs para sub-6 ou fallback de LTE podem alterar o IP e terminar as ligações.

Se estiver a carregar a partir de um veículo em movimento em rede móvel, espere interrupções. Os carregamentos retomáveis em chunks lidam bem com isto; os carregamentos de fluxo único não.

Timeouts de mod_security e WAF

Se um serviço estiver por detrás de uma Web Application Firewall (Cloudflare WAF, AWS WAF, ModSecurity), o WAF pode sinalizar um carregamento longo como suspeito e cortá-lo. Sintomas: carregamentos bem-sucedidos em tamanhos pequenos, falham num limiar específico (frequentemente 1 GB ou 10 GB dependendo da configuração do WAF), com respostas 403 ou 502.

Não há nada a corrigir do lado do cliente. Reporte ao serviço. Um WAF bem configurado permite carregamentos em chunks sem sinalizar.

Timeouts padrão do navegador

Os navegadores também têm timeouts de pedido, embora geralmente sejam generosos para carregamentos. O Chrome e o Firefox não impõem tempo limite por defeito para pedidos XHR e fetch, mas terminam ligações inativas após 5 minutos nalgumas configurações. Os Service Workers podem intercetar e prolongar os timeouts.

Se o JavaScript do próprio serviço definir xhr.timeout = 30000 (30 segundos) por chunk, os chunks lentos falham. Isso é um erro do lado do serviço; reporte-o.

Antivírus a inspecionar tráfego HTTPS

O Windows Defender com "inspeção de HTTPS" ativada, o Norton, o Bitdefender e similares fazem MITM nas ligações HTTPS para analisar o conteúdo. Em carregamentos grandes, a própria análise acrescenta latência que pode fazer os chunks excederem os timeouts do servidor.

Desative temporariamente a inspeção de HTTPS (não o antivírus completo, apenas a análise de HTTPS) durante os carregamentos grandes. Se os carregamentos forem bem-sucedidos, adicione o serviço de transferência à lista de exclusões do antivírus de forma permanente.

Lógica de repetição e recuo exponencial

Os clientes de transferência bem construídos repetem os chunks falhados com recuo exponencial: 1 segundo, depois 2, depois 4, depois 8. Uma breve oscilação de rede resolve-se de forma transparente. Os clientes sem lógica de repetição falham no primeiro erro.

Se estiver a usar um serviço que não repete automaticamente, verá mais falhas induzidas por timeout. Escolha um cliente ou serviço que trate das repetições por si.

Tente novamente passados 15 minutos

Alguns timeouts são transitórios: uma oscilação de um edge node da Cloudflare, um deploy de serviço, um link de trânsito congestionado. Tente novamente passados 15 minutos antes de escalar. Se falhar de novo, mude para outra rede para isolar se o problema é seu ou do serviço.

Escolha um serviço com repetição robusta

Para ficheiros grandes em redes instáveis, um serviço com repetição por chunk, estado de sessão retomável e sem timeout agressivo do lado do servidor é o que precisa. O HexaTransfer executa carregamentos paralelos em chunks com repetição por chunk e encriptação AES-256-GCM no lado do cliente, pelo que um carregamento de 10 GB numa ligação instável repete os chunks afetados de forma transparente em vez de falhar toda a transferência numa única oscilação de rede.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.