Upload continua a falhar? Corrija os erros comuns de transferência
Resolva uploads com falha com este guia passo a passo. Corrija erros de timeout, quedas de ligação e travamentos do browser.
Um upload com falha enquadra-se quase sempre numa de cinco categorias: instabilidade de rede (quedas de Wi-Fi, rerouting do ISP), esgotamento de memória do browser (Chrome a matar um separador com 2 GB de RAM), limitação de débito ou quota do lado do serviço, ficheiro de origem corrompido, ou antivírus/firewall a bloquear pedidos de saída. Comece por verificar o separador Rede do DevTools para obter o código de estado HTTP real do pedido falhado. Um 413 é "payload demasiado grande". Um 502 ou 503 é o serviço. Um "ERR_CONNECTION_RESET" é a sua rede. Cada um tem uma correção diferente.
Ler o erro real, não a mensagem genérica
A maioria das interfaces de upload mostra "Upload falhado" e fica por aí. Isso é inútil. Abra o DevTools do browser (F12 ou Cmd+Option+I), mude para o separador Rede e observe o pedido falhado. O código de estado diz-lhe onde está o problema: os códigos 400 significam o seu lado (413 demasiado grande, 401 autenticação, 403 proibido), os códigos 500 significam o lado do serviço (502 bad gateway, 503 slow down, 504 timeout). Erros de ligação como ERR_CONNECTION_RESET ou net::ERR_NETWORK_CHANGED significam que a ligação TCP morreu a meio da transferência.
Tire uma captura de ecrã do pedido falhado e dos seus cabeçalhos de resposta antes de fechar qualquer coisa. Se escalar para o suporte, esses cabeçalhos geralmente identificam o problema.
Quedas de Wi-Fi: o assassino silencioso
Os chips Wi-Fi de portátil fazem roaming entre pontos de acesso e entre bandas (2,4 GHz e 5 GHz) por vezes. Cada roaming quebra a ligação TCP durante uma fração de segundo, o que mata um upload de único fluxo. Os serviços de upload que implementam uploads em chunks e retomáveis (baseados em tus.io, multipart S3) sobrevivem a isto; os uploads de POST único não.
Se puder ligar por cabo, faça-o. O Ethernet não faz roaming. Se não puder, pelo menos fique numa divisão e desative "Mudança automática de SSID" ou o band-steering da mesh durante o upload. Corra um ping contínuo para 1.1.1.1 noutro terminal e observe as lacunas — essas lacunas são onde os uploads morrem.
Crashes do browser e remoção de separadores
O Chrome mata separadores quando excedem um limiar de memória, tipicamente cerca de 2 a 4 GB por separador consoante a RAM disponível. Fazer upload de um ficheiro de 10 GB através de um browser que coloca tudo em memória (má implementação) vai crashar. Fazer upload através de um que transmite chunks (boa implementação, usando o método slice() da File API) usa algumas centenas de MB de RAM independentemente do tamanho do ficheiro.
Se o browser continuar a crashar em uploads grandes, experimente o Firefox, que historicamente lida com uploads grandes da File API com menos pressão de memória do que o Chromium. Certifique-se de que o serviço usa uploads em chunks; se um ficheiro de 5 GB estiver a ser carregado para um único Blob antes do POST, esse é o problema de design.
Feche todos os outros separadores. Reinicie o browser antes de começar. Desative extensões (bloqueadores de anúncios, extensões de privacidade e gestores de palavras-passe às vezes injetam-se nos fluxos de upload e quebram-nos).
Firewalls e proxies corporativos
As redes corporativas frequentemente correm inspeção profunda de pacotes, modelação de tráfego ou servidores proxy que injetam certificados. Sintomas: os uploads têm sucesso em ficheiros pequenos mas falham a um tamanho específico (muitas vezes 100 MB ou 1 GB), ou o erro indica "SSL handshake failed" ou "certificate verification failed".
Verifique fazendo upload a partir do hotspot do telemóvel (fora da rede corporativa). Se funcionar aí, o problema está do seu lado. Opções: peça à TI para colocar o endpoint de upload do serviço na lista de permissões, use uma VPN (se permitido) para contornar o modelador, ou mude para uma rede pessoal.
O Zscaler, Cisco Umbrella e aparelhos Palo Alto são culpados comuns. Frequentemente inspeccionam ficheiros acima de um limiar de tamanho e atingem timeout em fluxos grandes.
Antivírus a analisar o fluxo de saída
O Windows Defender, Bitdefender, Norton e Kaspersky podem analisar o tráfego HTTPS de saída ao interceptar TLS. Em uploads grandes, a própria análise pode abrandar o débito em 40 a 60 por cento, e nalgumas versões introduz timeouts que matam a ligação.
Desative temporariamente a proteção web em tempo real (não o antivírus completo, apenas o componente de inspeção HTTPS) e tente novamente. Se o upload for bem-sucedido, adicione o domínio do serviço de transferência à lista de exclusões do AV. Não deixe a proteção web desativada permanentemente.
Limites de débito do lado do serviço
Se estiver a obter respostas 429 ou 503, o serviço está a limitar o seu débito. Razões possíveis: está a correr demasiados chunks paralelos (reduza de 8 para 4 workers), atingiu uma quota diária do nível gratuito (o WeTransfer gratuito tem limites implícitos de volume diário), ou está num IP partilhado que foi sinalizado (comum em Wi-Fi de hotel e café que foi abusado).
Aguarde 15 minutos e tente novamente. Ou mude de rede. Ou mude de serviço.
Ficheiro de origem corrompido
Raramente, o próprio ficheiro é o problema. A corrupção do sistema de ficheiros (setor defeituoso numa unidade externa, cópia interrompida) produz um ficheiro que lê bem nos primeiros MB e retorna erros de E/S a partir daí. O upload para a uma percentagem consistente em cada tentativa.
Teste copiando o ficheiro para um disco local diferente primeiro. Se a cópia falhar na mesma percentagem, é a origem. Corra chkdsk no Windows ou diskutil verifyDisk no macOS na unidade de origem. Para ficheiros críticos, recupere de uma cópia conhecidamente boa antes de tentar fazer upload novamente.
Erros de data, hora e certificado TLS
Se o relógio do sistema estiver errado em mais de alguns minutos, a validação do certificado TLS falha e os uploads dão erro com "certificate not yet valid" ou semelhante. Os Macs e o Windows sincronizam geralmente via NTP automaticamente, mas após uma suspensão longa ou uma bateria da motherboard descarregada, os relógios derivam.
Force uma sincronização NTP: sntp -sS time.apple.com no macOS, ou Definições > Hora e Idioma > Data e hora > Sincronizar agora no Windows.
VPNs que falham silenciosamente
Alguns clientes VPN (especialmente os gratuitos) quebram ligações TCP de longa duração após 5 a 10 minutos porque os tokens de sessão são renovados. Um upload de 2 GB que demora 20 minutos morre na renovação do token, silenciosamente. Mude para uma VPN paga com melhor gestão de sessão (Mullvad, ProtonVPN, IVPN), ou desconecte a VPN durante uploads se o serviço já usa encriptação TLS ponta a ponta.
Os serviços com encriptação ponta a ponta significam que não precisa da VPN para confidencialidade durante a própria transferência. O HexaTransfer, por exemplo, encripta com AES-256-GCM no cliente antes de o ficheiro sair do browser, por isso adicionar encriptação VPN por cima é redundante, não essencial.
Se corrigiu os problemas locais óbvios e os uploads continuam a falhar, o próprio serviço pode não lidar bem com interrupções. Um serviço com retry automático por chunk e estado de sessão retomável continua a correr através do tipo de falhas breves (um roaming Wi-Fi, um breve rerouting do ISP) que matam os carregadores de único fluxo. O HexaTransfer corre uploads em chunks paralelos com retry por chunk e sobrevive à maioria dos eventos de rede breves sem qualquer intervenção manual.
Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo