Comparação entre Speedtest de 500 Mbps e download de 20 MB/s mostrando possíveis gargalos de rede. — Um Speedtest rápido não garante a mesma taxa em todos os downloads; servidor, Wi-Fi, Ethernet, VPN e computador podem limitar a transferência.

54 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Você contrata uma conexão de 500 Mbps, abre um teste de velocidade e encontra um resultado próximo do esperado:

Download: 487 Mbps
Upload: 246 Mbps
Ping: 8 ms

Até aqui, tudo parece normal.

Minutos depois, você baixa um arquivo grande e o navegador informa:

20 MB/s

A primeira impressão costuma ser:

“Meu plano é de 500 mega, mas estou recebendo apenas 20.”

Essa comparação, porém, possui um problema fundamental: 500 Mbps e 20 MB/s não utilizam a mesma unidade de medida.

E mesmo depois de converter corretamente megabits para megabytes, outra pergunta permanece.

Se uma conexão de 500 Mbps pode, teoricamente, transportar aproximadamente 62,5 MB/s, por que determinado download fica limitado a 20 MB/s, 10 MB/s ou até menos enquanto o Speedtest continua mostrando quase toda a velocidade contratada?

É justamente aí que começa o diagnóstico.

Um teste de velocidade mede a capacidade da conexão em determinadas condições e contra determinados servidores. Ele não garante que todo servidor da Internet, toda CDN, todo navegador ou toda aplicação conseguirá entregar dados na mesma taxa.

Além disso, o gargalo pode nem estar na operadora.

Ele pode estar:

no servidor que fornece o arquivo;
na rota até esse servidor;
no Wi-Fi;
no cabo de rede;
na negociação Ethernet;
em uma VPN;
no navegador;
no antivírus;
no computador;
no armazenamento;
ou em uma combinação desses fatores.

Neste artigo da VMIA, vamos separar cada uma dessas possibilidades e responder a uma pergunta mais útil do que simplesmente “minha Internet está lenta?”:

Onde exatamente a velocidade está sendo limitada?

Primeiro: Mbps e MB/s não são a mesma coisa

Esse é o ponto mais importante para começar.

As operadoras normalmente anunciam velocidade de Internet em:

Mbps — megabits por segundo

Programas de download, navegadores e algumas aplicações podem apresentar a transferência em:

MB/s — megabytes por segundo

Observe a diferença entre as letras:

Mb = megabit
MB = megabyte

O B maiúsculo representa byte.

Como:

1 byte = 8 bits

uma aproximação simples para converter Mbps em MB/s é:

Mbps ÷ 8 = MB/s

Assim:

500 Mbps ÷ 8 = 62,5 MB/s

Portanto, uma conexão de 500 Mbps não significa que o navegador deveria mostrar:

500 MB/s

Isso exigiria uma capacidade muito maior.

Quanto cada velocidade representa em MB/s?

Podemos fazer algumas conversões simples:

Velocidade da conexão	Máximo teórico aproximado
100 Mbps	12,5 MB/s
200 Mbps	25 MB/s
300 Mbps	37,5 MB/s
500 Mbps	62,5 MB/s
600 Mbps	75 MB/s
1 Gbps	125 MB/s

Esses valores representam uma conversão matemática, não uma promessa de velocidade real de download.

Na prática, existem protocolos, cabeçalhos, retransmissões, limitações dos equipamentos e outros fatores.

Portanto, não espere necessariamente observar exatamente 62,5 MB/s em todos os downloads de uma conexão de 500 Mbps.

O primeiro erro: comparar 500 Mbps com 20 MB/s diretamente

Imagine:

Plano: 500 Mbps
Download: 20 MB/s

Se quisermos comparar os dois na mesma unidade, podemos converter 20 MB/s para megabits:

20 × 8 = 160 Mbps

Então o cenário real é aproximadamente:

Conexão testada: 500 Mbps
Download daquele arquivo: 160 Mbps

Agora temos uma comparação válida.

E podemos fazer a pergunta correta:

por que aquele download utilizou aproximadamente 160 Mbps de uma conexão capaz de atingir perto de 500 Mbps em outro teste?

Isso significa que a operadora está limitando a conexão?

Não necessariamente.

Esse é outro erro comum.

Um resultado pode mostrar:

Speedtest → 490 Mbps

enquanto determinado servidor entrega:

Download → 160 Mbps

Isso não comprova, sozinho, que:

o Speedtest está mentindo;
a operadora está reduzindo o download;
o computador está com defeito.

Os dois testes podem estar medindo caminhos e condições completamente diferentes.

O Speedtest não mede “a velocidade da Internet inteira”

Quando realizamos um teste de velocidade, o computador se comunica com um servidor utilizado para aquela medição.

Simplificando:

Seu computador
      ↓
Roteador
      ↓
Operadora
      ↓
Servidor do teste

Quando baixamos um arquivo de outro serviço:

Seu computador
      ↓
Roteador
      ↓
Operadora
      ↓
Redes intermediárias
      ↓
CDN ou hospedagem
      ↓
Servidor do arquivo

Os destinos podem ser diferentes.

As rotas podem ser diferentes.

A capacidade dos servidores pode ser diferente.

O congestionamento também pode ser diferente.

Por isso, obter 500 Mbps em um teste não significa que qualquer servidor da Internet esteja obrigado ou seja capaz de enviar dados para você a 500 Mbps.

Pense na Internet como vários caminhos

Imagine que sua conexão com a operadora suporta:

500 Mbps

Isso significa que existe capacidade para transportar aquela taxa nas condições adequadas.

Mas o servidor de onde você está baixando pode limitar cada usuário a:

200 Mbps

Nesse caso:

Sua conexão → suporta 500 Mbps
Servidor → entrega até 200 Mbps

O resultado não poderá ultrapassar aproximadamente o gargalo daquele fluxo.

Em uma representação simples:

PC
│
│ 500 Mbps
↓
Roteador
│
│ 500 Mbps
↓
Operadora
│
│ 500 Mbps
↓
Servidor
│
│ 200 Mbps
↓
DOWNLOAD
≈ 200 Mbps

A velocidade de uma transferência é limitada pelo ponto mais restritivo do caminho relevante.

Um download não é um teste de velocidade

Essa distinção precisa ficar clara.

Um Speedtest tenta medir a capacidade da conexão utilizando infraestrutura e metodologia voltadas para essa finalidade.

Um download comum possui outro objetivo:

entregar determinado arquivo.

O servidor pode estar atendendo:

centenas;
milhares;
milhões de usuários.

Pode existir limitação por conexão, por usuário ou pela própria infraestrutura.

Assim, não devemos usar um único arquivo aleatório como prova definitiva da velocidade contratada.

O servidor pode ser o gargalo

Considere três downloads realizados no mesmo computador, um após o outro.

Servidor A → 58 MB/s
Servidor B → 20 MB/s
Servidor C → 8 MB/s

A conexão não mudou.

O roteador não mudou.

O computador não mudou.

Mas o destino mudou.

Isso é uma pista muito importante.

Se conseguimos baixar de uma fonte confiável a 58 MB/s, mas outro servidor entrega apenas 8 MB/s, dificilmente podemos afirmar que a conexão inteira está limitada a 8 MB/s.

Por que servidores limitam downloads?

Existem vários motivos.

Um serviço pode:

limitar a velocidade por usuário;
limitar cada conexão;
possuir capacidade insuficiente;
estar congestionado;
priorizar planos pagos;
utilizar uma CDN específica;
sofrer alta demanda;
possuir armazenamento lento;
controlar tráfego para reduzir custos.

Do ponto de vista do usuário, tudo aparece simplesmente como:

“download lento”.

Mas a Internet local pode estar funcionando perfeitamente.

CDN também influencia

Grandes serviços raramente dependem de um único servidor físico.

Eles podem utilizar uma CDN — Content Delivery Network.

A ideia geral é distribuir conteúdo por vários pontos.

Em vez de todos os usuários acessarem:

Servidor único

podemos ter:

Usuário em São Paulo
        ↓
     CDN A

enquanto outro usuário pode acessar:

Usuário em outra região
        ↓
     CDN B

Isso melhora desempenho e disponibilidade, mas também significa que duas pessoas acessando aparentemente o mesmo arquivo podem receber o conteúdo por infraestruturas diferentes.

DNS pode até mudar a CDN utilizada

Como vimos no artigo anterior sobre nslookup, serviços modernos podem entregar diferentes endereços conforme:

resolvedor DNS;
localização;
disponibilidade;
balanceamento;
infraestrutura.

Isso significa que mudar o DNS pode, em determinados serviços, acabar levando o usuário a outro destino ou caminho.

Se o download melhora, não devemos concluir automaticamente:

“o DNS antigo era lento.”

Pode ter mudado o servidor da CDN ou a rota utilizada.

O caminho até o Speedtest pode ser muito melhor

Imagine:

PC
↓
Operadora
↓
Servidor Speedtest próximo

Esse caminho pode ter:

baixa latência;
alta capacidade;
bom peering;
pouca distância de rede.

Agora compare com:

PC
↓
Operadora
↓
trânsito
↓
outra rede
↓
outro país
↓
servidor do arquivo

O segundo caminho possui muito mais variáveis.

Por isso, não existe contradição em:

Speedtest: 500 Mbps
Download A: 450 Mbps
Download B: 200 Mbps
Download C: 80 Mbps

Precisamos descobrir se o comportamento ocorre com um destino específico ou com todos.

Essa é a primeira grande divisão do diagnóstico

Pergunte:

Todos os downloads estão lentos?

Se a resposta for:

Não. Apenas um site ou serviço está lento.

Nossa suspeita aumenta para:

servidor;
CDN;
rota;
limitação do serviço;
aplicação específica.

Se a resposta for:

Sim. Tudo está lento naquele computador.

Agora investigamos:

rede local;
Wi-Fi;
Ethernet;
VPN;
antivírus;
navegador;
Windows;
armazenamento.

Essa divisão economiza muito tempo.

Teste o mesmo arquivo em outro computador

Imagine dois computadores conectados à mesma rede.

Computador A

Download → 55 MB/s

Computador B

Download → 12 MB/s

Mesmo servidor.

Mesmo arquivo.

Horário semelhante.

Mesma conexão de Internet.

Agora temos uma evidência importante:

o gargalo provavelmente está mais próximo do computador B.

Pode ser:

Wi-Fi;
cabo;
placa de rede;
driver;
negociação;
antivírus;
VPN;
armazenamento;
processamento.

Agora inverta o teste

Imagine:

PC A

Servidor X → 10 MB/s

PC B

Servidor X → 11 MB/s

Mas ambos conseguem:

Servidor Y → 55 MB/s

Nesse caso, o servidor X ou o caminho até ele passa a ser um suspeito muito mais forte.

Essa é a essência do diagnóstico:

comparação controlada.

Wi-Fi pode ser o gargalo mesmo com Internet de 500 Mbps

Outro cenário extremamente comum:

Plano → 500 Mbps
Ethernet → 480 Mbps
Wi-Fi → 170 Mbps

Nesse caso, a operadora pode estar entregando a capacidade contratada até o roteador, enquanto o enlace sem fio não consegue aproveitar toda essa capacidade naquele ambiente.

O Wi-Fi depende de:

padrão utilizado;
frequência;
largura de canal;
distância;
obstáculos;
interferência;
capacidade do roteador;
capacidade do adaptador;
número de dispositivos;
qualidade do sinal.

Portanto:

ter plano de 500 Mbps não transforma automaticamente qualquer conexão Wi-Fi em uma conexão de 500 Mbps.

“Meu Wi-Fi mostra 866 Mbps, então deveria baixar a 866 Mbps?”

Não.

A velocidade mostrada pelo adaptador Wi-Fi pode representar a taxa de link negociada, não o throughput real disponível para aplicações.

Existe overhead.

O meio é compartilhado.

Existem retransmissões.

As condições de rádio mudam.

Por isso:

Link Wi-Fi: 866 Mbps

não significa:

Download real: 866 Mbps

Essa diferença é fundamental.

Ethernet também pode limitar

Suponha que seu plano seja:

500 Mbps

mas a placa Ethernet negociou:

100 Mbps

Nesse cenário, mesmo que a operadora entregue 500 Mbps ao roteador, o computador possui um enlace local de aproximadamente 100 Mbps.

Em MB/s:

100 ÷ 8 = 12,5 MB/s

Na prática, a transferência útil ficará abaixo do máximo matemático.

Agora imagine o usuário reclamando:

“Todo download fica perto de 11 MB/s.”

Esse número é uma pista excelente.

Pode existir um enlace Fast Ethernet de 100 Mbps em algum ponto.

O padrão de 10 a 12 MB/s merece atenção

Quando downloads parecem ficar constantemente perto de:

10 MB/s
11 MB/s
12 MB/s

em uma conexão muito mais rápida, vale verificar se algum enlace negociou a 100 Mbps.

Isso pode acontecer por:

cabo com problema;
conector;
porta limitada;
equipamento Fast Ethernet;
negociação incorreta.

Não significa que todo download de 11 MB/s seja causado por Ethernet de 100 Mbps.

Mas o padrão merece investigação.

Como verificar a velocidade do link no Windows

No PowerShell, podemos utilizar:

Get-NetAdapter

Observe informações do adaptador ativo.

Também é possível verificar o status da conexão pelas propriedades de rede do Windows.

Queremos descobrir se a Ethernet está negociando, por exemplo:

100 Mbps

ou:

1 Gbps

ou valores superiores, dependendo do hardware.

1 Gbps significa download de 1 GB/s?

Não.

Novamente precisamos separar bits e bytes.

1 Gbps = 1000 Mbps

Convertendo aproximadamente:

1000 ÷ 8 = 125 MB/s

Então um link Gigabit Ethernet possui máximo teórico na ordem de 125 MB/s antes de considerarmos overhead e demais limitações.

Para atingir:

1 GB/s

seria necessária uma capacidade de rede muito maior que 1 Gbps.

O cabo pode fazer a conexão cair para 100 Mbps

Em Gigabit Ethernet sobre cobre, a qualidade e integridade dos pares necessários à negociação importam.

Um cabo ou terminação com problema pode impedir a negociação esperada.

O usuário pode continuar tendo Internet normalmente.

Só que:

antes → 1 Gbps
agora → 100 Mbps

Resultado:

sites continuam abrindo;
WhatsApp continua funcionando;
vídeos podem continuar funcionando;
downloads grandes ficam muito mais lentos.

É um problema fácil de ignorar porque a conexão não desapareceu completamente.

Teste por cabo antes de culpar o Wi-Fi

Se o computador está conectado por Wi-Fi e apresenta resultado baixo, quando possível faça um teste comparativo via Ethernet.

Temos:

Wi-Fi → 180 Mbps
Ethernet → 490 Mbps

Agora sabemos que a conexão externa é capaz de entregar uma taxa muito maior.

A prioridade passa a ser:

Wi-Fi e ambiente local.

Se ambos apresentam:

Wi-Fi → 180 Mbps
Ethernet → 185 Mbps

precisamos continuar investigando.

O Speedtest também precisa ser interpretado corretamente

Não basta olhar apenas para um número.

Compare:

diferentes horários;
conexão por cabo;
Wi-Fi;
diferentes servidores quando necessário;
outros dispositivos;
comportamento real de downloads.

Um único resultado pode ser influenciado pelas condições daquele momento.

Nosso objetivo não é escolher o teste que confirma o que queremos acreditar.

É procurar um padrão reproduzível.

O antivírus pode reduzir a velocidade de download?

Pode, dependendo da solução, da configuração e do tipo de arquivo.

Softwares de segurança podem inspecionar:

conexões;
conteúdo;
arquivos baixados;
tráfego HTTPS em determinados produtos;
gravações no armazenamento.

Isso não significa que devemos desativar a proteção como primeira tentativa.

O correto é observar:

CPU;
disco;
processos;
comportamento com diferentes arquivos;
logs da solução de segurança, quando disponíveis.

Segurança não deve ser removida aleatoriamente apenas para ganhar velocidade.

O disco pode limitar um download?

Sim, especialmente quando a transferência depende de gravação contínua e o armazenamento está ocupado ou possui desempenho insuficiente.

Imagine:

Rede consegue receber → 60 MB/s

mas o sistema enfrenta:

disco muito ocupado

ou outros processos competindo por I/O.

Dependendo da aplicação, isso pode afetar o comportamento da transferência.

Em computadores modernos com SSD saudável, isso tende a ser menos provável em velocidades domésticas moderadas, mas não deve ser ignorado.

HDD, SSD e armazenamento externo

O arquivo pode estar sendo salvo em:

SSD NVMe;
SSD SATA;
HDD;
HD externo;
pendrive;
pasta de rede.

Cada destino possui características diferentes.

Imagine baixar diretamente para um dispositivo USB lento.

O usuário vê:

download oscilando.

A suspeita inicial é Internet.

Mas a aplicação também precisa gravar os dados recebidos.

Por isso, o destino do arquivo faz parte do diagnóstico.

Gerenciador de Tarefas ajuda muito

Durante um download, abra:

Gerenciador de Tarefas → Desempenho

Observe:

Ethernet ou Wi-Fi;
disco;
CPU;
memória.

Também observe os processos.

Imagine:

Rede → 160 Mbps
Disco → 100%
CPU → normal

Esse cenário é diferente de:

Rede → 100%
Disco → normal
CPU → normal

Os números ajudam a identificar qual recurso está próximo do limite.

Cuidado com porcentagens do Gerenciador de Tarefas

“100% de disco” não significa necessariamente a mesma coisa que atingir a taxa máxima sequencial anunciada pelo fabricante.

O comportamento do armazenamento depende de:

latência;
fila;
leitura/gravação;
tamanho dos blocos;
processos simultâneos.

Da mesma forma, uma interface de rede em determinada porcentagem precisa ser interpretada em relação à velocidade negociada.

O diagnóstico precisa olhar o contexto.

VPN pode transformar 500 Mbps em muito menos

Ao ativar uma VPN, o caminho muda:

PC
↓
VPN
↓
Servidor da VPN
↓
Internet
↓
Servidor do download

Agora entram novas variáveis:

capacidade do servidor VPN;
criptografia;
protocolo;
distância;
rota;
MTU;
processamento.

Assim:

Sem VPN → 480 Mbps
Com VPN → 190 Mbps

não significa necessariamente defeito na Internet.

O gargalo pode estar no túnel ou no servidor da VPN.

Faça o teste com e sem VPN

Se a VPN não for obrigatória para aquele acesso, compare:

Speedtest sem VPN
Download sem VPN

com:

Speedtest com VPN
Download com VPN

Se a diferença aparece somente com a VPN, temos uma pista muito forte.

Não altere o Windows inteiro antes de investigar o componente que mudou.

Um primeiro diagnóstico em cinco minutos

Quando alguém disser:

“Tenho 500 mega, mas meus downloads ficam lentos.”

comece com cinco perguntas:

1. A velocidade está em Mbps ou MB/s?

2. Todos os downloads ficam lentos ou apenas um serviço?

3. Outro computador na mesma rede apresenta o mesmo resultado?

4. O problema acontece por Ethernet e Wi-Fi?

5. Existe VPN ativa?

Essas cinco respostas já conseguem eliminar várias hipóteses.

Exemplo prático

Temos:

Plano: 500 Mbps
Speedtest: 490 Mbps
Download: 11 MB/s

Primeiro:

11 × 8 = 88 Mbps

Curiosamente, estamos muito próximos do comportamento esperado de um enlace limitado em torno de 100 Mbps após considerar overhead.

Verificamos a Ethernet:

Velocidade do link: 100 Mbps

Trocamos o cabo defeituoso ou corrigimos a causa da negociação.

Depois:

Velocidade do link: 1 Gbps

Novo download:

55 MB/s

Nesse caso, o problema nunca esteve na velocidade contratada da operadora.

O gargalo estava entre:

computador e roteador.

Outro exemplo

Temos:

Plano: 500 Mbps
Speedtest: 495 Mbps
Download servidor A: 15 MB/s
Download servidor B: 57 MB/s

Ethernet:

1 Gbps

Outro PC:

Servidor A: 16 MB/s
Servidor B: 56 MB/s

Agora não faz sentido começar trocando a placa de rede do primeiro computador.

O comportamento acompanha o servidor.

A suspeita muda para:

servidor A;
CDN;
rota;
limitação daquele serviço.

Não existe um único “teste definitivo”

Um bom diagnóstico combina:

Speedtest
+
conversão Mbps/MB/s
+
outros servidores
+
outro computador
+
Ethernet/Wi-Fi
+
estado do link
+
recursos do Windows

Cada teste responde a uma pergunta diferente.

É a combinação dos resultados que revela o gargalo.

Throughput, TCP, latência, CDN e limitações reais

Na Parte 1, estabelecemos uma diferença fundamental: Mbps e MB/s não são a mesma unidade.

Uma conexão de:

500 Mbps

corresponde matematicamente a:

62,5 MB/s

antes de considerarmos overhead e outras limitações.

Também vimos que um download de 20 MB/s representa aproximadamente:

160 Mbps

Portanto, quando o Speedtest mostra perto de 500 Mbps e determinado arquivo baixa a 20 MB/s, a pergunta correta não é simplesmente:

“Por que a operadora está entregando apenas 20 mega?”

Precisamos descobrir qual componente da cadeia está limitando aquela transferência.

Agora vamos aprofundar essa investigação.

Velocidade de link, capacidade e throughput não são a mesma coisa

Imagine uma placa Ethernet mostrando:

1,0 Gbps

Esse número representa a velocidade negociada daquele enlace.

Não significa que qualquer aplicação conseguirá transferir exatamente:

1 Gbps

de dados úteis.

Da mesma forma, um adaptador Wi-Fi pode indicar:

866 Mbps

sem que o computador consiga baixar arquivos a 866 Mbps.

Precisamos separar três conceitos.

Velocidade de link

É a taxa negociada entre dispositivos naquele enlace.

Capacidade disponível

É quanto tráfego aquela infraestrutura consegue transportar nas condições atuais.

Throughput

É a quantidade efetiva de dados transferidos durante determinado período.

Em um cenário simples:

Link Ethernet
1 Gbps
   ↓
Internet
500 Mbps
   ↓
Servidor
250 Mbps
   ↓
Download
≈ até 250 Mbps

O link Gigabit não transforma um servidor de 250 Mbps em um servidor de 1 Gbps.

O menor gargalo limita a transferência

Podemos imaginar a comunicação como uma sequência de tubos:

PC
│ 1 Gbps
↓
Roteador
│ 1 Gbps
↓
Internet contratada
│ 500 Mbps
↓
Caminho externo
│ 350 Mbps
↓
Servidor
│ 200 Mbps
↓
DOWNLOAD

Nesse exemplo, o servidor ou algum trecho relacionado àquele fluxo limita a taxa para aproximadamente 200 Mbps.

Não importa que outros segmentos suportem mais.

Para aquela transferência, o gargalo está em 200 Mbps.

Por que o valor real não chega exatamente ao máximo matemático?

Considere novamente:

500 Mbps ÷ 8 = 62,5 MB/s

Esse cálculo é correto como conversão de unidades.

Mas uma comunicação real possui informações adicionais além dos dados do arquivo.

Dependendo do protocolo e do caminho, existem cabeçalhos e outros mecanismos relacionados a:

Ethernet;
IP;
TCP;
TLS;
HTTP;
retransmissões;
confirmações;
controle de congestionamento.

Portanto, nem todo bit transmitido corresponde diretamente a um byte útil do arquivo.

É por isso que devemos tratar:

62,5 MB/s

como uma referência matemática, não como uma obrigação para cada download.

Overhead não explica qualquer diferença

Também precisamos evitar o erro oposto.

Se uma conexão de 500 Mbps baixa constantemente a:

5 MB/s

não faz sentido simplesmente dizer:

“É o overhead.”

Cinco megabytes por segundo equivalem aproximadamente a:

40 Mbps

Existe uma diferença muito grande.

Nesse caso, devemos procurar um gargalo real.

Overhead existe, mas não serve como explicação universal para qualquer perda de desempenho.

TCP influencia bastante o download

Grande parte das transferências tradicionais da Web utiliza TCP, embora protocolos modernos também possam utilizar QUIC sobre UDP.

No TCP, a transmissão não funciona simplesmente assim:

Servidor joga dados
↓
PC recebe

Existe controle sobre:

entrega;
sequência;
confirmações;
congestionamento;
retransmissões;
quantidade de dados em trânsito.

Isso ajuda a garantir confiabilidade, mas também significa que latência e perda podem afetar o throughput.

Latência não é a mesma coisa que velocidade

Uma conexão pode apresentar:

Download: 500 Mbps
Ping: 5 ms

e outra:

Download: 500 Mbps
Ping: 120 ms

As duas possuem capacidade nominal semelhante, mas não necessariamente terão comportamento idêntico em todas as aplicações.

Latência representa o tempo envolvido na comunicação entre pontos.

Em determinadas transferências, especialmente quando combinada com perda e características do protocolo, uma latência maior pode influenciar a rapidez com que a transmissão cresce e mantém uma alta taxa.

Servidor distante pode baixar mais devagar

Imagine dois servidores.

Servidor A

São Paulo
Latência: 5 ms

Servidor B

Outro continente
Latência: 180 ms

Mesmo que ambos possuam infraestrutura rápida, o comportamento de determinadas conexões pode ser diferente.

Não significa que:

servidor distante = sempre lento.

Grandes redes conseguem entregar velocidades excelentes a longas distâncias.

Mas a distância de rede adiciona uma variável importante.

TCP precisa manter dados em trânsito

Para aproveitar uma conexão rápida em um caminho de alta latência, o TCP precisa conseguir manter uma quantidade adequada de dados “em voo”.

Imagine de forma simplificada:

Servidor
↓
dados
↓
Internet
↓
Cliente
↓
confirmações

Se o protocolo precisasse esperar cada pequeno pedaço ser confirmado antes de enviar o próximo, conexões de alta latência seriam extremamente ineficientes.

Por isso, TCP utiliza mecanismos de janela e controle que permitem múltiplos dados em trânsito.

O que é TCP Receive Window?

A janela de recepção participa do controle de quanto dado pode permanecer em trânsito sem confirmação individual de cada pequeno segmento.

Em sistemas modernos, esses mecanismos são ajustados dinamicamente.

No Windows, podemos verificar determinadas configurações TCP com:

netsh interface tcp show global

Podemos encontrar informações relacionadas a recursos como:

Receive Window Auto-Tuning Level

Em instalações normais do Windows, não existe motivo para alterar esses parâmetros apenas porque um download está lento.

Não desative TCP Auto-Tuning como “otimização”

Existem tutoriais antigos que recomendam alterar configurações TCP para “acelerar a Internet”.

Esse tipo de intervenção pode produzir o efeito contrário.

Se o Windows está funcionando normalmente, alterar parâmetros TCP sem diagnóstico pode:

reduzir throughput;
causar incompatibilidades;
dificultar o diagnóstico;
mascarar a causa original.

Primeiro descubra se existe realmente um problema.

Bandwidth-Delay Product ajuda a entender o cenário

Existe um conceito importante em redes chamado Bandwidth-Delay Product.

Sem transformar este artigo em uma aula matemática extensa, ele ajuda a responder:

quanto dado precisa estar em trânsito para aproveitar determinada capacidade em um caminho com determinada latência?

Quanto maior a velocidade e a latência, maior pode ser a quantidade de dados que precisa permanecer em trânsito para utilizar bem o enlace.

Isso ajuda a entender por que:

500 Mbps + 5 ms

500 Mbps + 180 ms

não são cenários idênticos para todos os protocolos e aplicações.

Perda de pacotes pode derrubar throughput

Agora adicione perda.

Imagine:

500 Mbps disponíveis

mas o caminho apresenta perda de pacotes.

O TCP detecta problemas e reage.

Dependendo do cenário, pode ocorrer:

retransmissão;
redução da taxa;
recuperação;
nova tentativa de crescimento.

Assim, uma conexão pode apresentar boa capacidade bruta, mas uma transferência TCP específica sofrer bastante.

Um Speedtest pode esconder perda?

“Esconder” não é a melhor palavra.

O teste utiliza sua própria metodologia, conexões e servidores.

Ele pode apresentar um resultado excelente enquanto outra aplicação, usando outro caminho e outro padrão de conexão, apresenta desempenho inferior.

Por isso, novamente:

um teste de velocidade não representa todos os destinos da Internet.

Uma conexão ou várias conexões fazem diferença

Esse é um ponto muito importante.

Um serviço de teste de velocidade pode utilizar múltiplas conexões para aproveitar melhor a capacidade disponível.

Um download específico pode depender de uma única conexão ou de uma estratégia diferente.

Imagine:

Conexão TCP 1 → 100 Mbps
Conexão TCP 2 → 100 Mbps
Conexão TCP 3 → 100 Mbps
Conexão TCP 4 → 100 Mbps
Conexão TCP 5 → 100 Mbps

Em uma simplificação extrema, várias conexões podem preencher melhor uma capacidade total de:

500 Mbps

enquanto uma transferência única pode não atingir a mesma taxa.

Isso não significa que todo Speedtest funcione exatamente dessa forma em todas as situações. O princípio importante é que metodologias diferentes produzem resultados diferentes.

Por que gerenciadores de download podem parecer mais rápidos?

Alguns gerenciadores conseguem dividir determinados arquivos em partes e realizar múltiplas solicitações quando o servidor permite.

Conceitualmente:

Arquivo
├── Parte 1
├── Parte 2
├── Parte 3
└── Parte 4

As partes podem ser transferidas paralelamente.

Em alguns servidores, isso pode aumentar o aproveitamento da conexão.

Mas não existe garantia.

O servidor pode:

impedir múltiplas conexões;
limitar velocidade por usuário;
não aceitar solicitações parciais;
impor limites.

Não use gerenciador de download como prova de defeito no navegador

Se:

Navegador → 20 MB/s
Gerenciador → 50 MB/s

isso mostra que o comportamento das duas transferências é diferente.

Não prova automaticamente que o navegador esteja defeituoso.

Pode existir diferença em:

número de conexões;
método de download;
servidor;
cache;
protocolo.

Precisamos comparar corretamente.

CDN pode limitar ou melhorar dramaticamente o resultado

Imagine um arquivo popular.

Sem CDN:

Usuário
↓
servidor distante

Com CDN:

Usuário
↓
ponto próximo
↓
conteúdo

A segunda situação pode oferecer:

menor latência;
melhor rota;
maior capacidade;
menos congestionamento.

Por isso, serviços grandes frequentemente entregam downloads muito rápidos mesmo quando sua infraestrutura principal está distante.

O que é peering?

Na Internet, sua operadora precisa se conectar a outras redes para alcançar diferentes destinos.

Peering é uma das formas pelas quais redes trocam tráfego entre si.

Para o usuário, isso significa que a qualidade até um serviço não depende apenas do cabo entre sua casa e a operadora.

O caminho pode envolver:

Sua casa
↓
ISP
↓
interconexão
↓
outra rede
↓
CDN

Um problema ou congestionamento nessa relação pode afetar determinados destinos enquanto outros continuam rápidos.

Speedtest rápido e um serviço específico lento pode indicar rota ou interconexão

Imagine:

Speedtest → 500 Mbps
Serviço A → 480 Mbps
Serviço B → 450 Mbps
Serviço C → 70 Mbps

O comportamento está concentrado no serviço C.

Agora faz sentido investigar:

servidor;
CDN;
rota;
interconexão;
limitação do próprio serviço.

Não faz sentido começar formatando o Windows.

Tracert pode ajudar?

Pode fornecer pistas sobre o caminho:

tracert exemplo.com

Mas é importante não interpretar o tracert como um medidor direto de velocidade.

Além disso, roteadores intermediários podem:

não responder;
limitar respostas ICMP;
mostrar latência diferente para pacotes de diagnóstico.

Portanto:

* * *

em determinado salto não prova que aquele roteador esteja derrubando o download.

PathPing pode fornecer informações adicionais

No Windows:

pathping exemplo.com

O pathping combina características de rastreamento e medições ao longo do caminho.

Pode ser útil em determinados diagnósticos de perda.

Mas também exige interpretação cuidadosa.

Um equipamento intermediário pode limitar respostas direcionadas a ele sem necessariamente descartar o tráfego que está encaminhando.

Ping alto em um salto não prova gargalo

Imagine:

Hop 1 → 1 ms
Hop 2 → 5 ms
Hop 3 → 120 ms
Hop 4 → 20 ms
Destino → 22 ms

Se o salto 3 realmente adicionasse 120 ms ao encaminhamento de todos os pacotes, seria estranho o destino final voltar a 22 ms.

Provavelmente aquele roteador apenas respondeu aos pacotes de diagnóstico com baixa prioridade.

Esse é um erro clássico de interpretação.

Teste vários destinos

Para separar Internet local de servidor específico, escolha fontes confiáveis e diferentes.

O objetivo não é encontrar “o servidor mais rápido do mundo”.

Queremos descobrir um padrão:

Destino A → rápido
Destino B → rápido
Destino C → lento

ou:

Destino A → lento
Destino B → lento
Destino C → lento

Esses dois resultados apontam para direções diferentes.

Outro dispositivo é um dos melhores controles

Se possível, utilize outro computador conectado ao mesmo roteador.

Cenário 1

PC A → 500 Mbps
PC B → 150 Mbps

Suspeita maior no PC B ou no enlace dele.

Cenário 2

PC A → 150 Mbps
PC B → 155 Mbps

Agora o problema pode estar em um ponto compartilhado:

roteador;
Wi-Fi;
operadora;
destino;
horário.

Essa comparação é extremamente poderosa.

Mas os dois PCs precisam estar em condições comparáveis

Não compare:

Notebook antigo em Wi-Fi 2,4 GHz

com:

Desktop em Ethernet Gigabit

e conclua que o notebook está com defeito.

Para um teste controlado, tente aproximar:

mesmo tipo de conexão;
mesmo servidor;
mesmo horário;
mesmo arquivo;
condições semelhantes.

Wi-Fi de 2,4 GHz pode ser o limite

Em ambientes congestionados, uma rede de 2,4 GHz pode entregar throughput muito inferior ao de uma conexão de Internet moderna.

Isso não significa que 2,4 GHz seja inútil.

Ele pode ser excelente para:

alcance;
IoT;
dispositivos simples;
ambientes onde velocidade máxima não é necessária.

Mas esperar 500 Mbps reais de qualquer dispositivo conectado a qualquer rede de 2,4 GHz não é uma expectativa adequada.

5 GHz também não garante 500 Mbps

A faixa de 5 GHz oferece condições favoráveis para taxas maiores em muitos cenários, mas ainda depende de:

distância;
obstáculos;
canal;
interferência;
largura de canal;
capacidade do cliente;
capacidade do ponto de acesso.

Assim:

Wi-Fi 5 GHz

não significa automaticamente:

500 Mbps garantidos

Wi-Fi 6 e Wi-Fi 7 não eliminam gargalos

Tecnologias mais novas aumentam capacidades e introduzem melhorias importantes.

Mas o desempenho final continua dependendo da cadeia.

Um notebook Wi-Fi 7 conectado a um roteador moderno ainda pode baixar lentamente se:

servidor → 50 Mbps

ou:

Internet contratada → 100 Mbps

A tecnologia do Wi-Fi não remove o menor gargalo.

Como separar Wi-Fi da Internet?

Uma das melhores estratégias é medir a rede local.

Em vez de:

PC
↓
Wi-Fi
↓
Internet
↓
servidor externo

queremos testar:

PC A
↓
rede local
↓
PC B

Assim, eliminamos boa parte da Internet externa da equação.

iPerf é muito útil para isso

Em ambientes técnicos, o iPerf/iperf3 pode medir throughput entre dois dispositivos da rede.

A ideia é:

Servidor iPerf
↓
LAN
↓
Cliente iPerf

Se a rede local consegue entregar uma taxa alta, mas o download externo permanece baixo, nossa investigação pode avançar para fora da LAN.

Se a própria LAN está lenta, temos um gargalo mais próximo.

Não confunda iPerf com teste da Internet

Se dois computadores da rede atingem:

900 Mbps

no iPerf, isso demonstra bom desempenho entre aqueles pontos nas condições testadas.

Não significa que sua Internet seja de 900 Mbps.

Da mesma forma:

Internet → 500 Mbps

não garante que um Wi-Fi local mal posicionado consiga entregar 500 Mbps ao notebook.

São medições diferentes.

SMB também pode ser usado como pista, mas com cuidado

Transferir um arquivo grande entre dois computadores pode ajudar a avaliar a rede local.

Mas agora introduzimos:

disco do PC A;
disco do PC B;
SMB;
antivírus;
cache;
CPU.

Portanto, uma cópia SMB lenta não prova automaticamente que a rede esteja lenta.

O iPerf é mais adequado quando queremos isolar melhor a rede.

Disco pode se tornar o gargalo em cópias locais

Imagine:

Rede → 1 Gbps

mas o computador grava em um dispositivo lento.

A cópia pode apresentar:

30 MB/s

Mesmo que a rede seja capaz de transportar mais.

Novamente:

velocidade final = capacidade da cadeia completa.

CPU também pode interferir

Em conexões rápidas, determinadas operações podem consumir processamento significativo:

VPN;
criptografia;
antivírus;
descompactação;
verificação;
navegador;
armazenamento.

Se durante o download a CPU fica constantemente próxima do limite, investigue quais processos estão consumindo recursos.

Antivírus: não desligue a proteção para “testar” sem necessidade

É comum encontrar recomendações do tipo:

“Desative o antivírus e veja se fica rápido.”

Essa não deve ser a primeira abordagem.

Primeiro observe:

Gerenciador de Tarefas;
processos;
uso de CPU;
uso de disco;
comportamento com diferentes fontes.

Se uma solução de segurança parece ser o gargalo, investigue sua configuração e documentação.

Não transforme diagnóstico de velocidade em redução desnecessária de segurança.

VPN deve ser sempre considerada

Compare:

Sem VPN → 55 MB/s
Com VPN → 18 MB/s

Se o padrão é reproduzível, investigue:

servidor VPN;
protocolo;
distância;
CPU;
MTU;
rota.

Agora temos uma evidência concreta de que a mudança ocorre junto com o túnel.

Proxy também pode limitar

Em ambientes empresariais:

PC
↓
Proxy
↓
Internet

O proxy pode:

inspecionar tráfego;
aplicar políticas;
armazenar cache;
limitar largura de banda;
realizar filtragem.

Portanto, o Speedtest e um download corporativo podem não percorrer exatamente o mesmo caminho lógico.

Navegador pode ser o gargalo?

Em situações específicas, sim, mas é importante testar.

Se:

Chrome → 20 MB/s
Edge → 20 MB/s
Outro PC → 20 MB/s

a chance de o problema ser exclusivamente o Chrome diminui.

Se:

Chrome → 8 MB/s
Edge → 55 MB/s

no mesmo computador e mesma fonte, então vale investigar o navegador.

Compare:

extensões;
perfil;
segurança;
proxy;
comportamento do site.

Um download lento não significa necessariamente uma Internet ruim

Esse talvez seja o conceito mais importante do artigo.

Considere:

Speedtest → 490 Mbps
YouTube 4K → normal
Videoconferência → normal
Cloud → rápido
Servidor específico → 40 Mbps

Nesse cenário, dizer:

“Minha Internet é de 40 Mbps”

não representa corretamente o comportamento da conexão.

O problema está concentrado em determinado fluxo.

E o contrário também é verdadeiro

Imagine:

Speedtest → 90 Mbps
Downloads → 10 MB/s
Plano → 500 Mbps
Ethernet → 100 Mbps

Aqui temos uma limitação clara próxima de 100 Mbps.

O fato de “os sites abrirem rápido” não significa que a conexão esteja aproveitando o plano.

Para páginas pequenas, 100 Mbps pode parecer perfeitamente rápido.

O problema fica evidente em transferências maiores.

Por que navegação não é bom teste de largura de banda?

Uma página pode:

utilizar cache;
carregar conteúdo pequeno;
distribuir arquivos por CDN;
abrir várias conexões;
carregar elementos progressivamente.

A sensação de rapidez também depende muito de:

latência;
DNS;
processamento;
navegador.

Por isso:

“Google abre instantaneamente”

não comprova que uma conexão de 500 Mbps esteja entregando 500 Mbps.

Downloads grandes são melhores para observar estabilidade

Um arquivo suficientemente grande permite observar a transferência durante mais tempo.

Downloads muito pequenos podem terminar antes de a taxa se estabilizar.

Por isso, ao comparar desempenho, utilize arquivos grandes de fontes confiáveis e legítimas.

Observe:

taxa média;
oscilações;
comportamento ao longo do tempo.

Velocidade começa alta e depois cai

Esse padrão merece investigação.

Exemplo:

Início → 60 MB/s
Depois → 20 MB/s

Possíveis causas incluem:

cache;
limitação do servidor;
congestionamento;
armazenamento;
controle de tráfego;
comportamento da aplicação.

O padrão sozinho não identifica a causa, mas é uma pista.

Velocidade oscila constantemente

Exemplo:

50 MB/s
↓
12 MB/s
↓
45 MB/s
↓
8 MB/s
↓
55 MB/s

Agora investigue:

Wi-Fi;
perda;
servidor;
disco;
CPU;
outros usuários;
VPN.

Uma taxa média isolada esconde essa informação.

Outro dispositivo está usando a conexão?

Imagine uma conexão de 500 Mbps.

Enquanto você baixa um arquivo:

TV → streaming
PC 2 → backup em nuvem
Console → atualização
Celular → upload de vídeos

A capacidade disponível é compartilhada.

Não podemos exigir que uma única transferência receba toda a banda enquanto outros dispositivos também a utilizam.

Upload pode prejudicar a experiência

Uma conexão pode possuir:

500 Mbps download
250 Mbps upload

Se o upload estiver saturado, determinadas aplicações podem sofrer aumento de latência e piora na responsividade.

Isso se relaciona a gerenciamento de filas e, em certos cenários, bufferbloat.

Mas esse é um problema diferente de simplesmente converter Mbps para MB/s.

Por isso, não devemos misturar todos os sintomas em uma única explicação.

Faça testes com a rede ociosa

Para uma medição mais limpa:

pause grandes backups;
evite atualizações simultâneas;
verifique outros dispositivos;
teste preferencialmente via cabo quando possível.

O objetivo não é criar uma condição artificial perfeita para sempre.

É descobrir a capacidade disponível sem outras cargas confundindo o diagnóstico.

Fluxo de diagnóstico intermediário

Até aqui podemos montar:

DOWNLOAD LENTO
      ↓
Converter MB/s ↔ Mbps
      ↓
Speedtest também está lento?
   ↙                 ↘
 SIM                 NÃO
 ↓                    ↓
Testar LAN         Testar outros
e outros PCs       servidores
 ↓                    ↓
Link 100 Mbps?     Só um lento?
Wi-Fi?              ↙       ↘
ISP?               SIM      NÃO
                   ↓         ↓
             servidor/CDN   PC/VPN/
             rota/peering   segurança/
                            armazenamento

Esse mapa já evita grande parte das conclusões erradas.

Exemplo avançado 1: gargalo no servidor

Plano:

600 Mbps

Speedtest:

580 Mbps

Servidor A:

68 MB/s

Servidor B:

14 MB/s

Outro computador:

Servidor A → 66 MB/s
Servidor B → 15 MB/s

A evidência aponta fortemente para algo relacionado ao servidor B ou ao caminho até ele.

Exemplo avançado 2: gargalo no PC

Plano:

500 Mbps

PC A:

Speedtest → 480 Mbps
Download → 54 MB/s

PC B:

Speedtest → 95 Mbps
Download → 11 MB/s

Verificamos:

PC B Ethernet → 100 Mbps

O gargalo está próximo do PC B.

Exemplo avançado 3: gargalo no Wi-Fi

Notebook:

Wi-Fi → 140 Mbps

Mesmo notebook por Ethernet:

485 Mbps

Outro PC por cabo:

490 Mbps

A operadora e o roteador conseguem entregar a velocidade.

A investigação passa para:

sinal;
frequência;
canal;
adaptador;
distância;
interferência.

Exemplo avançado 4: VPN

Sem VPN:

Speedtest → 490 Mbps
Download → 56 MB/s

Com VPN:

Speedtest → 170 Mbps
Download → 18 MB/s

O comportamento muda de maneira consistente com a VPN.

Agora investigamos o túnel antes de alterar cabo, DNS ou placa de rede.

diagnóstico completo no Windows e como encontrar o gargalo

Nas duas primeiras partes, vimos que um resultado de 500 Mbps no Speedtest e um download de 20 MB/s não são informações contraditórias por si só.

Primeiro, precisamos comparar as unidades corretamente:

20 MB/s × 8 = 160 Mbps

Depois, precisamos lembrar que o Speedtest mede a capacidade da conexão em um cenário específico, enquanto um download depende de toda a cadeia entre o computador e o servidor que fornece o arquivo.

Agora vamos reunir tudo em um procedimento prático para descobrir onde a velocidade está sendo limitada.

A ideia é evitar o erro mais comum em problemas de Internet: alterar DNS, reinstalar driver, resetar o roteador ou até formatar o Windows sem antes saber qual componente realmente está apresentando o gargalo.

A ordem correta do diagnóstico

Quando um download parece lento, siga esta sequência:

1. Conferir Mbps x MB/s
2. Testar Speedtest
3. Verificar velocidade do link
4. Comparar Ethernet e Wi-Fi
5. Testar outro computador
6. Testar outro servidor
7. Observar CPU, disco e rede
8. Verificar VPN e proxy
9. Investigar rota/CDN
10. Só então suspeitar da operadora

Essa ordem reduz bastante as chances de perder tempo com hipóteses erradas.

Passo 1: confirme a unidade

Se o navegador mostra:

20 MB/s

converta:

20 × 8 = 160 Mbps

Se mostra:

55 MB/s

temos aproximadamente:

440 Mbps

Em uma conexão de 500 Mbps, 55 MB/s pode ser um resultado bastante coerente.

Já:

11 MB/s

equivale aproximadamente a:

88 Mbps

Esse número merece atenção, pois pode indicar um enlace limitado próximo de 100 Mbps.

Passo 2: execute um Speedtest

Faça o teste preferencialmente quando a rede estiver com pouca atividade.

Anote:

download;
upload;
ping.

Não olhe apenas para o número de download.

Se o resultado estiver muito abaixo do contratado, por exemplo:

Plano: 500 Mbps
Teste: 90 Mbps

o diagnóstico começa antes do servidor de download.

Se estiver:

Plano: 500 Mbps
Teste: 480 Mbps

mas apenas um download é lento, o foco muda.

Passo 3: verifique a velocidade negociada da placa de rede

No PowerShell:

Get-NetAdapter

Observe o adaptador ativo.

Queremos encontrar algo como:

LinkSpeed
1 Gbps

ou:

100 Mbps

Se o computador possui plano de 500 Mbps, mas a Ethernet está negociando apenas 100 Mbps, o máximo prático ficará muito abaixo da capacidade contratada.

Valores que servem como pistas

Link negociado	Máximo teórico aproximado
100 Mbps	12,5 MB/s
1 Gbps	125 MB/s
2,5 Gbps	312,5 MB/s

Se seus downloads ficam constantemente perto de 10–12 MB/s, vale conferir imediatamente se algum enlace está em 100 Mbps.

Se ficam perto de 100–110 MB/s, pode ser que o limite esteja em um link Gigabit.

Esses números não são provas absolutas, mas são pistas muito úteis.

Passo 4: compare Ethernet e Wi-Fi

Quando possível, faça o mesmo teste nas duas conexões.

Exemplo:

Wi-Fi
Speedtest: 180 Mbps

Ethernet
Speedtest: 490 Mbps

Nesse cenário, a conexão externa é capaz de entregar a velocidade.

A investigação passa para:

sinal Wi-Fi;
interferência;
distância;
canal;
adaptador;
roteador.

Agora outro cenário:

Wi-Fi: 180 Mbps
Ethernet: 190 Mbps

Aqui precisamos continuar investigando.

O gargalo não parece estar apenas no Wi-Fi.

Passo 5: use outro computador como controle

Conecte outro computador à mesma rede.

Se possível, use o mesmo tipo de conexão.

Resultado A

PC 1 → 500 Mbps
PC 2 → 120 Mbps

Suspeita maior em:

PC 2;
cabo;
adaptador;
driver;
VPN;
software;
configuração.

Resultado B

PC 1 → 120 Mbps
PC 2 → 125 Mbps

Agora o problema pode estar em algo compartilhado:

roteador;
operadora;
Wi-Fi;
horário;
destino.

Essa comparação é uma das mais eficientes em suporte técnico.

Passo 6: teste mais de uma fonte

Não utilize um único site.

Imagine:

Fonte A → 55 MB/s
Fonte B → 52 MB/s
Fonte C → 9 MB/s

O padrão aponta para a Fonte C.

Agora:

Fonte A → 9 MB/s
Fonte B → 10 MB/s
Fonte C → 11 MB/s

A investigação muda para a conexão ou o computador.

O número isolado importa menos que o padrão.

Passo 7: observe o Gerenciador de Tarefas

Durante o download, abra:

Ctrl + Shift + Esc

Depois vá em Desempenho.

Observe:

Ethernet ou Wi-Fi;
CPU;
Disco;
Memória.

Também veja a guia Processos.

Queremos descobrir se outro programa está utilizando recursos.

Cenário: rede baixa, disco alto

Imagine:

Rede: 150 Mbps
Disco: 100%
CPU: 20%

O armazenamento merece investigação.

Pode haver:

outro processo usando o disco;
antivírus verificando arquivos;
dispositivo externo lento;
HD mecânico ocupado.

Cenário: rede alta, CPU alta

Exemplo:

Rede: 450 Mbps
CPU: 100%
Disco: normal

Agora precisamos descobrir qual processo está consumindo CPU.

Pode ser:

VPN;
descompactação;
navegador;
software de segurança;
outra aplicação.

Cenário: rede baixa, CPU e disco normais

Exemplo:

Rede: 90 Mbps
CPU: 15%
Disco: 10%

Nesse caso, o gargalo pode estar antes do computador:

link negociado;
Wi-Fi;
servidor;
rota;
VPN.

Verifique se outro programa está usando a Internet

Na guia Processos, observe a coluna de rede.

Pode haver:

OneDrive;
Google Drive;
Windows Update;
Steam;
backup;
sincronização;
torrent;
navegador com outra aba.

Uma conexão de 500 Mbps pode estar sendo compartilhada.

Se outro processo está usando 300 Mbps, sobra menos capacidade para o download observado.

Windows Update pode consumir banda

O Windows pode baixar atualizações em segundo plano.

Em muitos casos, isso ocorre sem chamar muita atenção do usuário.

Antes de concluir que a Internet está lenta, verifique se existem processos de atualização ou sincronização ativos.

O objetivo não é desativá-los permanentemente.

É entender se estão participando da medição.

OneDrive e outros serviços de nuvem

Serviços de sincronização podem realizar:

upload;
download;
comparação de arquivos;
atualização de várias pastas.

Se um grande backup começou, a velocidade disponível para outras transferências pode mudar.

Novamente, isso não significa defeito.

É uso simultâneo da conexão.

Verifique a VPN

Se houver VPN ativa, repita os testes sem ela, quando for seguro e apropriado.

Compare:

Sem VPN
Speedtest: 490 Mbps
Download: 55 MB/s

com:

Com VPN
Speedtest: 180 Mbps
Download: 20 MB/s

Se a diferença é consistente, a VPN passa a ser a principal suspeita.

Não altere cabo ou driver antes de investigar o componente que mudou.

Verifique o proxy

No Prompt de Comando:

netsh winhttp show proxy

Também verifique as configurações de proxy do Windows.

Em redes empresariais, um proxy pode:

filtrar;
inspecionar;
limitar;
redirecionar;
autenticar.

O download pode estar passando por ele enquanto outros testes seguem outro comportamento.

Teste o link local

Se houver dois computadores na mesma rede, uma ferramenta como iperf3 pode ajudar a medir o throughput da LAN.

O objetivo é separar:

PC
↓
rede local
↓
PC

da Internet externa.

Se a LAN consegue transferir próximo do esperado, mas a Internet não, a investigação avança para fora da rede local.

Se a própria LAN está lenta, temos um problema mais próximo.

Como interpretar um teste local rápido

Suponha:

iPerf entre PCs: 930 Mbps
Internet: 500 Mbps
Download externo: 80 Mbps

A rede local parece saudável.

O gargalo do download externo está em outro ponto.

Agora outro cenário:

iPerf: 95 Mbps
Internet: 500 Mbps

A rede local já possui uma limitação importante.

Não adianta trocar DNS.

Quando suspeitar da operadora?

A operadora passa a ser uma suspeita mais forte quando:

Speedtest para diferentes servidores está abaixo do contratado;
vários dispositivos apresentam o mesmo problema;
Ethernet e Wi-Fi mostram resultados semelhantes;
não há VPN;
não há consumo interno relevante;
o problema persiste em diferentes horários;
a velocidade negociada dos dispositivos está correta.

Quanto mais desses pontos se confirmam, mais razoável é abrir chamado.

Quando não culpar a operadora

Se temos:

Speedtest: 490 Mbps

Download de um único servidor: 20 MB/s

não existe evidência suficiente para afirmar que a operadora está limitando a conexão.

Precisamos testar outras fontes.

Horário também importa

Alguns problemas aparecem apenas em determinados períodos.

Exemplo:

08:00 → 480 Mbps
14:00 → 470 Mbps
20:30 → 180 Mbps
23:30 → 460 Mbps

Esse padrão sugere algo relacionado a:

congestionamento;
uso compartilhado;
infraestrutura;
horário.

Registrar os horários ajuda muito em um chamado técnico.

Faça testes reproduzíveis

Anote:

data;
hora;
conexão usada;
servidor;
resultado;
se havia VPN;
se outros dispositivos estavam ativos.

Exemplo:

Hora	Conexão	Speedtest	Download
09:00	Ethernet	490 Mbps	55 MB/s
14:00	Ethernet	485 Mbps	54 MB/s
20:00	Ethernet	170 Mbps	18 MB/s

Esse registro vale muito mais que dizer:

“À noite fica ruim.”

Não altere DNS para resolver download lento

Esse é um erro bastante comum.

DNS resolve nomes.

Depois que o download já começou, a maior parte da transferência não depende de novas consultas DNS para cada pedaço do arquivo.

Trocar DNS pode mudar o destino em alguns serviços por causa de CDN, mas não é uma solução universal para velocidade de download.

Se o gargalo é:

Wi-Fi;
cabo;
servidor;
VPN;
disco;

trocar DNS não corrige a causa.

Não reinstale o driver imediatamente

Antes de reinstalar a placa de rede, verifique:

velocidade negociada;
outro computador;
Ethernet versus Wi-Fi;
VPN;
resultados em diferentes servidores.

Se o adaptador negocia corretamente e outros testes apontam para um servidor específico, reinstalar o driver dificilmente será a primeira medida correta.

Não resete o roteador sem motivo

Reiniciar o roteador pode alterar temporariamente:

conexão;
sessão;
rota;
cache.

Se o problema desaparecer, ainda não sabemos por quê.

Antes de reiniciar, tente registrar:

velocidade;
horário;
destino;
comportamento.

Assim, se o sintoma voltar, teremos dados para comparar.

Fluxograma completo

DOWNLOAD LENTO
      │
      ▼
Converter MB/s em Mbps
      │
      ▼
Speedtest está normal?
   ┌──┴──┐
  NÃO   SIM
  │      │
  ▼      ▼
Testar   Todos os downloads
Ethernet estão lentos?
outro PC   ┌──┴──┐
           SIM  NÃO
           │     │
           ▼     ▼
       PC/rede  Servidor/CDN
       VPN      rota/peering
       segurança
       disco
       │
       ▼
Velocidade do link correta?
   ┌──┴──┐
  NÃO   SIM
  │      │
  ▼      ▼
Cabo/   CPU, disco,
porta   processos,
100 Mbps VPN, proxy

Esse fluxograma não substitui o diagnóstico técnico, mas ajuda a escolher o próximo teste com base no resultado anterior.

Casos práticos

Caso 1 — Link em 100 Mbps

Plano:

500 Mbps

Speedtest:

94 Mbps

Download:

11 MB/s

Get-NetAdapter:

LinkSpeed: 100 Mbps

Diagnóstico:

O gargalo está no enlace local.

Caso 2 — Servidor lento

Plano:

500 Mbps

Speedtest:

490 Mbps

Downloads:

Servidor A: 56 MB/s
Servidor B: 54 MB/s
Servidor C: 8 MB/s

Outro computador apresenta o mesmo comportamento.

Diagnóstico:

O problema está relacionado ao servidor C ou ao caminho até ele.

Caso 3 — Wi-Fi

Plano:

500 Mbps

Wi-Fi:

160 Mbps

Ethernet:

485 Mbps

Diagnóstico:

Investigar Wi-Fi, não a operadora.

Caso 4 — VPN

Sem VPN:

490 Mbps
55 MB/s

Com VPN:

170 Mbps
18 MB/s

Diagnóstico:

O túnel VPN é o principal candidato ao gargalo.

Caso 5 — Computador específico

PC A:

480 Mbps

PC B:

120 Mbps

Mesmo roteador, mesmo cabo, mesmo horário.

Diagnóstico:

Investigar PC B, adaptador, driver, software ou configuração.

Perguntas frequentes

Tenho 500 Mbps. Quanto deveria aparecer em MB/s?

A conversão matemática é de aproximadamente 62,5 MB/s. Na prática, a taxa útil pode ser um pouco menor por causa de overhead e das condições da transferência.

Por que o Speedtest mostra 500 Mbps e o download apenas 20 MB/s?

Porque o Speedtest mede a conexão em um cenário específico, enquanto o download depende também do servidor, CDN, rota, protocolo, computador e outros fatores.

20 MB/s é ruim em uma conexão de 500 Mbps?

20 MB/s correspondem a cerca de 160 Mbps. É abaixo da capacidade teórica da conexão, mas não prova, sozinho, que a operadora esteja com problema.

Download de 11 MB/s pode indicar cabo ruim?

Pode ser uma pista. 11 MB/s equivalem a aproximadamente 88 Mbps, valor próximo de um enlace de 100 Mbps após considerar overhead. Vale verificar a velocidade negociada.

Wi-Fi pode impedir que eu use os 500 Mbps?

Sim. O desempenho do Wi-Fi depende de distância, interferência, frequência, canal, roteador e adaptador.

Trocar DNS aumenta a velocidade do download?

Normalmente, não. DNS resolve nomes. Depois que a transferência começa, outros fatores costumam determinar a taxa.

VPN reduz velocidade?

Pode reduzir, dependendo do servidor, protocolo, criptografia, rota e capacidade do túnel.

O disco pode deixar o download lento?

Pode, especialmente se o armazenamento estiver muito ocupado ou se o arquivo estiver sendo gravado em um dispositivo lento.

Um servidor pode limitar minha velocidade?

Sim. O servidor ou o serviço pode limitar a taxa por usuário, por conexão ou por capacidade disponível.

Como saber se o problema é meu computador?

Compare com outro computador na mesma rede, usando o mesmo servidor e condições semelhantes. Se apenas um PC estiver lento, a investigação deve se concentrar nele.

Conclusão

Quando o Speedtest mostra perto de 500 Mbps, mas um download fica em 20 MB/s, o primeiro passo não é reclamar da operadora nem começar a alterar configurações do Windows.

Primeiro, precisamos comparar as unidades corretamente.

Depois, precisamos lembrar que uma transferência real depende de uma cadeia completa:

Computador
↓
Wi-Fi ou Ethernet
↓
Roteador
↓
Operadora
↓
Interconexões da Internet
↓
CDN
↓
Servidor
↓
Armazenamento local

O gargalo pode estar em qualquer ponto dessa cadeia.

A maneira mais eficiente de encontrá-lo é comparar:

Mbps com MB/s;
Speedtest com downloads reais;
diferentes servidores;
outro computador;
Ethernet e Wi-Fi;
com e sem VPN;
uso de CPU, disco e rede.

Quando esses testes são feitos de forma organizada, a pergunta deixa de ser simplesmente “minha Internet está lenta?” e passa a ser muito mais precisa:

“Qual componente está limitando esta transferência?”

Essa mudança de abordagem evita alterações desnecessárias e leva a um diagnóstico muito mais confiável.

Precisa descobrir por que seus downloads estão mais lentos do que o Speedtest indica?

A VMIA – Manutenção e Configuração realiza diagnóstico de desempenho de Internet, Wi-Fi, Ethernet, roteadores, VPNs e computadores Windows.

Problemas como:

Speedtest mostra a velocidade contratada, mas os downloads são lentos;
apenas um computador apresenta baixa velocidade;
Wi-Fi não aproveita toda a conexão;
Ethernet negocia apenas 100 Mbps;
VPN reduz o desempenho;
downloads oscilam ou travam;

podem exigir uma análise da rede e do computador para identificar exatamente onde está o gargalo.

A VMIA oferece atendimento técnico com agendamento, incluindo suporte remoto quando o problema pode ser analisado à distância e atendimento presencial quando é necessário verificar a infraestrutura local.