Corrigir velocidade lenta: diagnosticar problemas de upload
Diagnostique e corrija velocidades de transferência lentas. Solução passo a passo para problemas de rede, browser e gargalos do serviço.
Para corrigir um upload lento, diagnostique por ordem: meça a ligação bruta com speedtest-cli, compare com o débito real da ferramenta de transferência no DevTools, verifique sincronizações em segundo plano a consumir largura de banda, confirme se o serviço não está a limitar o débito por transferência e verifique se está no endpoint regional mais próximo. Uma linha de 500 Mbps a entregar 40 Mbps para um serviço de transferência resulta de contenção de largura de banda, incompatibilidade de região CDN, throttling do servidor ou um gargalo de único fluxo. Cada um tem uma correção diferente, e todos aparecem no separador Rede do DevTools antes de fazer qualquer outra coisa.
Medir a ligação primeiro
Antes de culpar o serviço de transferência, confirme que a ligação está realmente a entregar o que pensa. Corra speedtest-cli --json num terminal, ou speedtest.net no browser. Anote Mbps de upload, latência e jitter. Este é o seu teto. Se a sua ligação "de 500 Mbps" apenas entrega 80 Mbps de upload no speedtest, nenhum serviço de transferência irá fazer melhor.
Corra o teste duas vezes, uma no Wi-Fi e uma no Ethernet se possível. A diferença diz-lhe quanto o Wi-Fi está a custar. No Wi-Fi 5 numa casa típica, espere perder 30 a 50 por cento do teto com fios.
Comparar speedtest com o débito real de transferência
Abra o serviço de transferência, inicie o upload e abra DevTools > separador Rede. Observe o débito dos pedidos individuais. Se o speedtest diz 500 Mbps e a transferência entrega 150 Mbps, a diferença tem quatro causas prováveis: o serviço usa um único fluxo (não consegue saturar uma ligação de alta latência), o endpoint CDN do serviço está distante de si, consumidores de largura de banda em segundo plano estão a roubar, ou o serviço está a limitar o débito por transferência.
Os carregadores em chunks paralelos (serviços baseados em tus.io, multipart S3, HexaTransfer) devem correr 4 a 8 pedidos simultâneos. Conte-os na cascata. Menos do que isso numa linha rápida significa que o serviço está a desperdiçar largura de banda.
Eliminar sincronizações em segundo plano
O Monitor de Atividade do macOS (separador Rede, ordenar por "Bytes Enviados por seg") e o Monitor de Recursos do Windows (separador Rede) mostram a largura de banda de cada processo. Culpados prováveis: Dropbox, Google Drive, OneDrive, iCloud Photos, Backblaze, Time Machine em rede, sincronização do Adobe Creative Cloud. Saia deles — não apenas pause, porque a pausa por vezes mantém as ligações TCP abertas.
Uma chamada Zoom em HD usa 2,5 Mbps upstream. Um upload de YouTube em 4K noutro separador pode consumir 20 Mbps. Mesmo as pré-visualizações de ficheiros do Slack empurram algumas centenas de KB/s. Em ligações assimétricas (100 Mbps de download, 10 Mbps de upload é um plano de cabo comum), estes somam-se rapidamente.
Verificar o endpoint regional
Muitos serviços de transferência encaminham através de edges CDN. Se o DNS ou GeoIP estiver desatualizado, pode estar a fazer upload para um edge em Frankfurt a partir de Sydney, o que adiciona 300 ms de ida e volta e prejudica seriamente o débito de único fluxo. Verifique o IP do endpoint no painel Rede do DevTools (clique com o botão direito no pedido > Copiar > Copiar URL, depois nslookup), depois faça ping para ver a latência.
Latência ideal para o ponto de ingestão do serviço de transferência: abaixo de 20 ms na mesma cidade, abaixo de 50 ms no mesmo continente, abaixo de 100 ms para ligações intercontinentais. Se estiver a 250 ms no mesmo continente do serviço, algo está a encaminhar por um edge distante. Uma mudança de DNS (do resolver predefinido do ISP para Cloudflare 1.1.1.1 ou Google 8.8.8.8) pode corrigir isto — resolvers diferentes retornam edges CDN diferentes via ECS (EDNS Client Subnet) e podem reduzir a latência em 50 ms sem tocar em mais nada.
Bufferbloat do router
O bufferbloat é invisível nos speedtests normais mas prejudica seriamente as ligações de uso misto. Corra o teste de bufferbloat da Waveform em waveform.com/tools/bufferbloat. Uma nota A+ significa que o router lida com filas de forma limpa. Uma nota F significa que o router está a introduzir 200 a 2000 ms de latência sob carga, o que não só prejudica o tráfego interativo como faz com que o controlo de congestão TCP recue repetidamente, cortando o débito de upload.
Correção: ative SQM (Smart Queue Management) no OpenWrt ou pfSense, ative QoS em routers Asus/Netgear/Ubiquiti, ou compre um router que o faça por predefinição (eero recente, Google Nest Wifi Pro).
Desativar VPN a menos que seja necessário
Uma VPN adiciona 20 a 80 ms de latência e tipicamente limita o débito ao upstream do servidor VPN. Uma linha de 1 Gbps através de um endpoint PIA ou NordVPN congestionado pode cair para 50 Mbps. Bons fornecedores (Mullvad, ProtonVPN Plus) aguentam melhor; as VPNs gratuitas quase sempre estrangulam os uploads.
Se o serviço de transferência já usa TLS 1.3 e encriptação ponta a ponta, a VPN é redundante para confidencialidade em trânsito. Desligue-a durante os uploads, ligue-a de novo depois.
Escolha do browser e protocolo
O Chrome, Edge, Brave e Firefox suportam todos HTTP/3 (QUIC) nativamente. O Safari também, mas usa HTTP/2 por predefinição para alguns hosts. O HTTP/3 sobre UDP tolera muito melhor a perda de pacotes do que o HTTP/2 sobre TCP em dados móveis, Wi-Fi de hotel ou ligações de última milha com perdas.
Verifique no DevTools > Rede > coluna Protocolo. Se disser h2, está em HTTP/2. Se disser h3, está em HTTP/3. Os serviços que servem uploads sobre HTTP/3 registam 15 a 30 por cento de ganhos de débito em ligações com perdas.
Tentar uma rede diferente para isolar o problema
O diagnóstico mais rápido: faça tethering do telemóvel por um minuto e faça upload de um chunk de teste. Se o tethering do telemóvel for mais rápido do que o Wi-Fi doméstico, o problema está na rede local (router, ISP ou dispositivo). Se o tethering do telemóvel tiver a mesma velocidade, o gargalo está mais acima (congestionamento de trânsito, limite do lado do serviço).
Este único teste elimina metade das causas possíveis em menos de dois minutos.
Quando o serviço é o gargalo
Alguns serviços de transferência simplesmente limitam o débito por transferência. Os níveis gratuitos de algumas ferramentas limitam acima de 10 MB/s independentemente da ligação. Os níveis pagos frequentemente removem o throttle.
Se eliminou tudo o resto e a sua linha de 500 Mbps ainda entrega apenas 30 Mbps para um serviço específico, o serviço é o limite. Mude. O HexaTransfer não faz throttle por transferência e corre uploads em chunks paralelos que saturam o que a ligação consegue realmente enviar até ao teto de 10 GB por transferência.
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