Tutoriais de VPS
Como testar rotas de ida, volta e ida e volta de VPS (2026): por que olhar só o ping leva a comprar errado
Muitas pessoas, antes de comprar um VPS, só fazem ping, veem latência baixa e acham que a rota é boa. Só quando entra em produção descobrem: rápido de dia, colapsa à noite; a ida parece bonita, a volta dá voltas; a latência média está ok, mas o jitter e a perda de pacotes derrubam o negócio. O problema não é que o ping não sirva, mas que ele só responde "dá para chegar?" e "mais ou menos quão rápido agora?", não "como chega?", "como é o caminho de volta?" nem "vai oscilar no horário de pico?".
Muitas pessoas, antes de comprar um VPS, têm a mesma primeira reação:
- Fazer ping primeiro
- Ver se a latência é alta
- Se a latência for baixa, achar que a rota é boa
Esse passo não está errado, mas se você parar por aqui, é muito fácil comprar errado.
Porque o ping só consegue responder uma pequena parte das perguntas:
- Esta máquina está acessível agora
- Qual é aproximadamente a latência de ida e volta atual
Ele não consegue responder estas perguntas mais críticas:
- Como os pacotes vão
- O caminho de volta é outra rota
- Vai oscilar de repente no pico da noite
- Passa pelo Japão, Estados Unidos ou até mais longe no meio
- A perda de pacotes é porque o roteador não quer responder, ou porque o link realmente tem problema
Então o foco deste artigo não é ensinar você a decorar conceitos, mas explicar com clareza a ordem de testes mais prática:
- O que são rota de ida, de volta e de ida e volta
- O que ping, traceroute e MTR conseguem mostrar cada um
- Por que olhar só o ping faz uma rota comum ser mal julgada como "até que não está ruim"
- Como testar de verdade antes de comprar um VPS para chegar mais perto da experiência real
Muitas pessoas acham:
- Ping baixo = rota boa
- Ping estável = máquina estável
Isso só vale em um nível muito grosseiro.
Falando com mais precisão:
- O ping serve para um "check-up rápido"
- Não serve como única base para "decidir a compra"
Porque o ping, em essência, é apenas:
- Enviar um ICMP Echo Request ao destino
- Ver se o outro lado responde
- Medir de passagem o tempo de ida e volta (RTT)
Por isso ele é muito bom para:
- Julgar rapidamente se há conectividade
- Dar uma referência básica de latência
Mas não é bom para:
- Dizer como a rota vai
- Distinguir diferenças entre ida e volta
- Identificar oscilações do link no pico da noite
- Localizar em qual salto o problema começa
Em uma frase:
- O ping tem valor, mas é mais parecido com um termômetro do que com uma tomografia.
Se você não entender primeiro esses três termos, muitos testes depois vão parecer confusos.
A rota de ida é:
- Como vai o caminho da sua rede -> VPS
Por exemplo, se você está na China Telecom em Xangai testando um VPS do Japão, a rota de ida mostra:
- Sua rede saindo do local
- Por quais nós de operadora passa
- Finalmente chegando ao data center do Japão
A rota de volta é:
- Como vai o caminho do VPS -> sua rede
Esse passo é muito crítico, porque uma realidade muito comum na internet é:
- Na ida vai pela rota A
- Na volta vem pela rota B
O que as pessoas costumam chamar de:
- Roteamento assimétrico
Ida e volta é olhar os dois lados.
Ou seja, o que realmente te importa não é:
- Se você consegue conectar a este VPS
Mas sim:
- Como vai a ida
- Como vai a volta
- Se os dois lados são estáveis
Se você só testar a ida, pode julgar errado; só testar a volta também pode deixar problemas passarem.
Então a forma realmente confiável de comprar costuma ser:
- Ida: ver se a rota é limpa
- Volta: ver se a linha está realmente otimizada
- Olhar as duas juntas para chegar perto da experiência real
Esta é a seção mais importante do artigo.
Você vê 80ms e provavelmente acha que não está ruim.
Mas como esses 80ms surgem?
- São 80ms indo direto
- Ou deu uma volta enorme e justo agora não há congestionamento, então também são 80ms
Com só o ping, você não sabe.
E ao comprar um VPS, muitos problemas estão justamente escondidos no "processo".
Um RTT que você mede representa:
- Uma ida
- Uma volta
Mas ele não vai te dizer:
- A ida é fluida, a volta é ruim
- Ou a ida dá voltas, a volta na verdade é normal
E em muitas das chamadas "rotas otimizadas", a parte realmente valiosa está na volta.
Por exemplo, se você compra Hong Kong, Japão ou EUA CN2 ou AS9929, mais da metade do valor é:
- Uma volta mais estável
Se você só olha o ping, provavelmente não vai perceber isso de jeito nenhum.
Agora você faz ping 20 vezes, média de 65ms, parece confortável.
Mas no negócio real, o que os usuários sentem muitas vezes não é a média, mas:
- Jitter
- Perda de pacotes
- Latência de cauda P95 / P99
- Oscilações repentinas no pico da noite
Então acontece um fracasso clássico:
- De dia o ping parece ótimo
- À noite o negócio continua lento a ponto de duvidar da vida
Alguns problemas de rota não são o destino inacessível, mas o meio estranho:
- Alguns saltos intermediários descartam muito ICMP
- Certo link dá voltas com frequência
- Certa operadora fica congestionada no pico
Com só o ping, você vai achar erradamente que "ainda conecta, então não tem problema".
Mas a experiência real do negócio já começou a oscilar há tempos.
A forma mais prática de entendê-los não é decorar detalhes do protocolo, mas saber do que cada um é responsável.
| Ferramenta | O que você pode ver | Maior limitação |
|---|---|---|
ping | Conectividade, RTT básico | Não vê a rota |
traceroute / tracert | Por quais nós a rota passa | Apenas um instantâneo |
mtr | Rota + estatísticas contínuas + tendência de jitter/perda | Ainda exige interpretação correta |
Bom para:
- Ver a latência rapidamente
- Ver rapidamente se há conectividade
Não é bom para:
- Usar sozinho para decidir a compra
Bom para:
- Ver a rota
- Julgar se dá voltas
- Ver se aparecem nós-chave da linha, como
59.43,9929, etc.
Limitação:
- É mais parecido com uma foto tirada em um momento
- Não é observação contínua
O MTR basicamente pode ser entendido como:
- Uma versão combinada de
ping + traceroute
O valor dele está em:
- Teste contínuo
- Ver estatísticas de latência de cada salto
- Ver Loss%, Avg, Best, Worst, StDev
Então, se você testa a rota de um VPS a sério, o MTR costuma ter mais valor de referência do que um traceroute único.
Quando muitas pessoas veem MTR pela primeira vez, o que mais assusta é isto:
- Um salto intermediário perde 30%
- Ou até 50%
E a primeira reação é:
- Acabou, essa rota quebrou
Mas esse julgamento muitas vezes está errado.
Documentação de rede autorizada e artigos de operação insistem repetidamente em um ponto:
- Se um salto intermediário perde pacotes, mas os saltos seguintes, especialmente o destino final, não perdem, normalmente não é um problema real do link.
Os motivos comuns incluem:
- Roteadores limitam a taxa de ICMP
- Dispositivos dão baixa prioridade ao tráfego de diagnóstico
- Alguns nós não querem responder, mas o encaminhamento real continua funcionando normalmente
O que realmente merece atenção é:
- A perda começar em certo salto
- E todos os saltos seguintes até o destino final perderem de forma contínua
Isso se parece mais com o ponto onde um problema real começa.
Então, ao olhar o MTR, a disciplina mais importante é:
- Não fique se assustando olhando um único salto intermediário; primeiro veja se o destino final também está falhando.
O teste de ida mais comum é:
traceroute -n <VPS_IP>
No Windows você pode usar:
tracert <VPS_IP>
Ao olhar a ida, preste atenção nestas coisas:
- Se há voltas evidentes
- Se aparecem as marcas de linha que te interessam
- Se o número de saltos é anormalmente alto
- Se antes de chegar à região de destino passa por países irrelevantes
Por exemplo, alguns pontos típicos de identificação de rota:
59.43.*.*costuma ser usado para identificar rotas relacionadas ao CN2 da rede premium da China TelecomAS9929costuma ser uma marca importante da rede premium da China Unicom
Mas atenção:
- Ver uma vez não significa que todo o percurso é ótimo
- Ver uma boa ida não significa que a volta é igualmente boa
Então a ida é só o primeiro passo, não o fim.
Para muitas pessoas que compram um VPS, a volta na verdade é mais crítica.
Porque o que realmente te importa costuma ser:
- Usuários acessando seu site
- O conteúdo da página voltando do VPS para os usuários
- Arquivos, APIs e respostas voltando do servidor para a rede nacional
Se esse passo der voltas, a experiência piora diretamente.
Os métodos comuns para testar a volta incluem:
- Looking Glass do provedor
MTR/BestTrace/NextTrace- Teste reverso do VPS para sua rede local ou sondas públicas nacionais
Para muitas das chamadas "rotas otimizadas", isto é justamente o que você mais deveria verificar:
- Se a volta é realmente otimizada, e não só a ida bonita.
Especialmente nestes cenários:
- Hong Kong CN2 / CMI
- Japão SoftBank / CN2
- Europa AS9929
- EUA CN2 GIA
Sem testar a volta, em muitos casos é como não ter testado nada.
Se você não quer complicar demais o processo, sugiro seguir esta ordem.
ping -c 20 <VPS_IP>
O que você olha:
- Latência básica
- Estabilidade aproximada
traceroute -n <VPS_IP>
O que você olha:
- Rota de ida
- Se dá voltas
- Se há características de linha identificáveis
mtr -rwzc 200 <VPS_IP>
O que você olha:
- Jitter
- Perda de pacotes
- Comportamento contínuo de cada salto
Se o provedor tem Looking Glass, BestTrace, NextTrace ou scripts de volta, olhe a volta também.
Este ponto é muito crítico.
Muitas rotas comuns de dia parecem decentes e só à noite mostram a verdadeira cara.
Então o que realmente precisa ser olhado antes de comprar não é "se um resultado parece bonito", mas:
- Se ela muda de cara no pico da noite
Aqui vai o framework de julgamento mais simples.
- A ida não dá grandes voltas evidentes
- A volta mostra as características de otimização que você quer
- O jitter e a perda no pico da noite continuam controláveis
- O Loss% do destino final é estável
- Os resultados de vários testes não diferem muito
- Ping baixo, mas traceroute dá voltas evidentes
- De dia parece ótimo, à noite oscila de repente
- Nós intermediários saltam de forma estranha e o destino final também perde pacotes continuamente
- O provedor só te dá teste de ping, sem entrada para Looking Glass / teste de volta
- A página só diz "rota otimizada", mas não explica de jeito nenhum como verificar
Se você vir o segundo grupo de sinais, não faça um pedido por impulso só porque "a latência média não é alta".
Veem:
- 40ms / 60ms / 80ms
E acham que são quase iguais.
Na verdade, o que realmente determina a experiência de carregamento da página costuma ser:
- Jitter no horário de pico
- Perda de pacotes contínua em pequena porcentagem
- Congestionamento na volta
De dia muitas rotas conseguem parecer perfeitamente normais.
A verdadeira diferença aparece no pico da noite.
As capturas do provedor só podem mostrar:
- Que eles mediram um bom resultado uma vez
Não podem mostrar:
- Que sua região, sua operadora e seu horário também serão iguais
Conseguir entrar por SSH só significa que a máquina não está morta.
Ainda está longe de "servir para sustentar um negócio".
Se você só lembrar de uma frase, espero que seja esta:
- O ping pode ser olhado primeiro, mas de jeito nenhum você pode parar por aí.
A ordem mais completa deveria ser:
- ping para latência básica
- traceroute para a rota de ida
- MTR para jitter e perda contínuos
- ferramentas de volta para a rota de volta
- novo teste no pico da noite para o desempenho real
Só juntando tudo isso, o que você vê chega mais perto de "como este VPS vai ser depois de entrar em produção".
Muitas pessoas compram o VPS errado não porque não sabem ler a configuração, mas porque entendem a qualidade de rede de forma simples demais.
O que realmente afeta a experiência nunca é uma captura de ping, mas:
- Como vai a ida
- Como vai a volta
- Se é estável no horário de pico
- Se a perda de pacotes continua até o destino
- Se esta rota é adequada para o seu público de usuários
Então a forma mais segura não é perguntar:
- O ping deste VPS é alto?
Mas sim perguntar:
- Esta rota, na rede dos meus usuários reais, é estável, dá voltas, aguenta o horário de pico?
Quando você tiver isso claro, a probabilidade de comprar a rota errada cai imediatamente uma boa parte.