Por que é que os proxies ficam lentos? Diagnóstico avançado: rastreamento, MTR e análise de cabeçalhos.

31 de março de 2026

Por que é que os proxies ficam lentos? Diagnóstico avançado: rastreamento, MTR e análise de cabeçalhos.

Você compra um proxy estático premium, configura-o no seu navegador antidetect, abre o site desejado... e a página demora uma eternidade para carregar. O primeiro pensamento é lógico: "Venderam-me um proxy ruim".

No entanto, a internet não é um tubo direto entre o seu computador e o site de destino. É uma rede logística complexa, composta por dezenas de nós de trânsito, cabos de fibra ótica submarinos e protocolos de segurança. A velocidade pode cair em qualquer uma dessas etapas.

Neste artigo, vamos analisar métodos avançados de diagnóstico de conexões de rede. Você aprenderá a encontrar a causa real dos atrasos e a falar com o suporte técnico dos provedores na mesma linguagem técnica.


🌍 Causa 1: Física e Roteamento

A causa mais comum de lentidão é ignorar as leis da física. A velocidade da luz é finita e os dados são transmitidos por cabos de fibra ótica.

Se você está fisicamente em Berlim, compra um proxy em Los Angeles e, através dele, abre um site cujo servidor está em Paris, seus dados fazem uma viagem transatlântica duas vezes.

Rota: Berlim ➡️ Los Angeles ➡️ Paris ➡️ Los Angeles ➡️ Berlim.

O Ping (tempo de resposta) nesse esquema será inevitavelmente de 200–300 milissegundos. Para carregar um site pesado com muitos scripts, isso resultará em segundos de espera.

Como resolver: Tente sempre selecionar o GEO do proxy de forma que ele esteja o mais próximo possível da sua localização física ou dos servidores do recurso de destino.


🕵️‍♂️ Causa 2: Problemas na rede principal (Usando MTR)

Mesmo que o servidor proxy seja potente e o site de destino funcione perfeitamente, pode surgir um problema no meio do caminho entre eles. Os provedores trocam tráfego através de nós de comunicação (operadores Tier-1). Se ocorrer um acidente ou sobrecarga em um desses nós em Frankfurt ou Amsterdã, seu tráfego sofrerá perdas.

Para encontrar esse nó "quebrado", os profissionais usam o MTR (My Traceroute). É um utilitário que combina as funções de ping e traceroute. Ele envia pacotes de dados por toda a cadeia e mostra estatísticas de cada elo.

Como fazer o diagnóstico:

  1. Para Windows, baixe o programa gratuito WinMTR. Para macOS/Linux, o MTR é instalado via terminal (ex: brew install mtr).

    👉 Link para o repositório GitHub

  2. No campo Host, insira o endereço IP do seu servidor proxy (ex: [IP_DO_SEU_PROXY]) e clique em Start.

  3. Detalhe técnico importante: Muitos tentam ativar o proxy no sistema, colocar no WinMTR o endereço do site final (ex: google.com) e esperam que o tráfego passe pelo proxy. Isso não funciona. Proxies (HTTP/SOCKS5) não conseguem passar tráfego ICMP de baixo nível, no qual o ping e o WinMTR operam. Se você fizer isso, o programa mostrará apenas sua rota doméstica direta, ignorando o proxy.

    Por isso, no campo Host, deve-se inserir exclusivamente o endereço IP do seu servidor proxy. Assim, verificamos a qualidade da conexão no trecho "Você ➡️ Proxy".

  4. Deixe o programa rodar por 1–2 minutos para enviar pelo menos 100 pacotes.

Interface do programa WinMTR
Fig. 1. Interface do programa WinMTR

Ao realizar o teste (enviar pelo menos 100–200 pacotes), o resultado deve ser registrado. No WinMTR, existem quatro botões na parte superior para isso:

  • Copy Text/HTML to clipboard: Copia rápida para colar em um e-mail ou chat de suporte.

  • Export TEXT/HTML: Salva um arquivo completo. A versão HTML é melhor visualmente, pois mantém a estrutura da tabela.

Exemplo de resultado do teste:

Host

Loss %

Sent

Recv

Best

Avrg

Wrst

Last

Home-Router

0

1272

1272

2

3

326

2

ISP-Gateway

1

1269

1268

5

7

74

7

Local-ISP-Node-A

3

1145

1112

5

6

31

6

Local-ISP-Node-B

1

1268

1267

5

8

171

6

Transit-Gateway-X

100

258

2

0

6

7

7

Regional-Hub-1

0

1273

1273

6

9

86

7

Regional-Hub-2

85

293

46

0

7

23

9

Regional-Hub-3

4

1136

1100

6

7

27

7

Regional-Hub-4

53

413

196

0

7

19

7

Regional-Hub-5

19

733

595

7

8

25

8

Global-Transit-A

0

1273

1273

7

9

74

8

Global-Transit-B

18

764

634

31

33

46

46

No response from host

100

257

0

0

0

0

0

Backbone-EU-AMS

1

1246

1240

196

197

278

197

Backbone-EU-LIL

1

1257

1253

191

192

207

193

Backbone-EU-PAR

1

1269

1268

198

199

227

201

Backbone-EU-SBG

0

1272

1272

208

212

313

249

ns3261405.ip-51-77-190.eu

1

1268

1267

205

206

229

206

Como ler os resultados do WinMTR: Preste atenção na coluna Loss % (porcentagem de pacotes perdidos).

  • Se as perdas começam nos primeiros 1-2 passos — o problema está no seu roteador doméstico ou no seu provedor de internet local.

  • Se as perdas estão no meio da lista (em nós com nomes estranhos como ae1.level3.net) — o problema está em um canal de trânsito global.

Hostname

Loss %

Sent

Recv

Best

Avrg

Wrst

Last

192.168.1.1

0

1304

1304

2

3

326

3

...intermediate-node...

100

301

47

0

7

23

7

be102.ams-gsa1-sbb2-nc5.nl.eu

1

1277

1270

196

197

278

197

ns3261405.ip-51-77-190.eu

1

1300

1299

205

206

229

206

  • Se você vir 100% de perda (No response from host) em um dos nós intermediários, mas o endereço final não tiver perdas — não entre em pânico. O nó está apenas configurado para ignorar pings, mas deixa passar o tráfego principal normalmente.

  • Se as perdas ocorrem apenas no último passo (o endereço do seu proxy) — significa que o servidor está realmente sobrecarregado.

Uma captura de tela do MTR com perdas em um nó principal é a melhor prova para o suporte técnico e economizará horas de conversa.

E como verificar a rota do proxy até o site de destino? O WinMTR mostrou que os pacotes chegam perfeitamente ao proxy, mas o site continua lento? Use serviços públicos de Looking Glass. Basta pesquisar no Google por "Looking Glass [país do seu proxy]". Nesses sites, você pode rodar ping e traceroute diretamente da localização do proxy para o site de destino.


⏱️ Causa 3: Handshakes TLS e Verificações Ocultas (cURL)

Às vezes, o MTR mostra uma imagem perfeita, mas o site ainda carrega devagar. Aqui entram em jogo os protocolos de criptografia e sistemas de proteção (como Cloudflare).

Para entender onde o tempo está sendo gasto, use a ferramenta de console cURL. Abra o terminal e execute uma requisição estendida:

bash
curl -x socks5://user:pass@IP:PORT -w "DNS: %{time_namelookup}s \nConnect: %{time_connect}s \nTLS: %{time_appconnect}s \nTTFB: %{time_starttransfer}s \nTotal: %{time_total}s \n" -o /dev/null -s https://google.com

Resultado da requisição:

bash
DNS: 0.000616s
Connect: 0.209187s
TLS: 3.170403s
TTFB: 3.947665s
Total: 3.948056s

O que significam essas métricas:

  • DNS: Tempo para encontrar o IP do site.

  • Connect: Tempo para estabelecer a conexão TCP.

  • TLS: Tempo do "aperto de mão" criptográfico (configuração do HTTPS).

  • TTFB (Time To First Byte): Tempo de espera pelo primeiro byte do servidor.

Se o Connect for rápido, mas o TTFB levar 5 segundos — o proxy está ótimo, mas o site de destino está atrasando a resposta propositalmente (sistemas antifraude fazendo verificações em segundo plano).


📝 Causa 4: Cabeçalhos "Sujos" (Header Analysis)

A lentidão pode ser causada pelo uso de proxies HTTP gratuitos que não oferecem anonimato real. Alguns proxies adicionam cabeçalhos como:

  • X-Forwarded-For: [seu IP real]

  • Via: 1.1 proxy.server

Quando sistemas de segurança detectam isso, eles podem bloquear ou limitar a conexão (o que parece "lentidão").

Solução: Use o protocolo SOCKS5. Diferente do HTTP, ele opera em um nível de rede mais baixo e não interage com cabeçalhos HTTP, transmitindo seus dados de forma pura. Ou escolha proxies HTTP Elite que garantidamente removem esses cabeçalhos.


Resumo: Checklist de Velocidade

Se o seu proxy ficou lento, siga estes 4 passos:

  1. Verifique a lógica GEO: Você está mandando dados para o outro lado do mundo e de volta?

  2. Troque o protocolo: Se usa HTTP, mude para SOCKS5 (ou vice-versa).

  3. Faça o rastreamento: Rode o WinMTR para o IP do proxy. Se a perda for na rede principal, aguarde o reparo do provedor.

  4. Colete provas para o suporte: Se o WinMTR mostrar perdas no último nó, envie o print para o provedor. Sua solicitação ganhará prioridade máxima.