Rede VPS não é apenas largura de banda: use ASN e rota de retorno para identificar a autenticidade da rota
Transforme a qualidade de rede em uma auditoria de dados reproduzível.
Origem do ASN + caminho de retorno + verificação cruzada de latência são necessários para identificar a autenticidade da rota e o prêmio.
O que a atribuição de ASN pode expor
Ao comprar uma VPS, as pessoas primeiro prestam atenção aos números de largura de banda, mas os casos em que a porta gigabit trava no horário de pico são demais. A largura de banda é apenas o limite; a qualidade real da rota depende do caminho que o tráfego realmente percorre — a primeira coisa é verificar a atribuição do ASN. Usando whois ou ferramentas online de consulta de ASN para ver o ASN do IP, você pode determinar imediatamente a qual datacenter ou operadora pertence aquele bloco de IPs. Por exemplo, se o provedor anuncia CN2 GIA, mas o ASN revela que é um Cogent ou NTT comum, provavelmente é propaganda enganosa ou revenda NAT.
Mais importante ainda, o ASN expõe a estratégia de roteamento. O mesmo provedor pode anunciar ASNs diferentes para blocos de IP distintos, resultando em grandes diferenças nas rotas de retorno das três principais redes (China Telecom, China Unicom, China Mobile). Usando o MTR para ver o ASN em cada salto, se o caminho passar pelos EUA ou pela Europa, a latência e a perda de pacotes serão naturalmente altas. Isso também explica por que diferentes blocos de IP da mesma VPS têm experiências tão diferentes. Ao fazer a análise reversa, é necessário verificar a consistência entre o Route Registry e o WHOIS, a fim de evitar que o provedor falsifique o número do ASN.
Do ponto de vista do custo da nuvem, a atribuição do ASN está diretamente relacionada à taxa de prêmio do FinOps. ASNs de qualidade (como Telecom 4134, Unicom 9929) têm custos de largura de banda muito mais altos do que linhas internacionais comuns. Se o prêmio no preço do provedor é razoável, pode ser avaliado por meio de uma auditoria de ASN. Muitas máquinas sobrevendidas cortam custos usando upstreams baratos; isso é visível apenas olhando o ASN. Use a ferramenta de teste de velocidade do site para rodar uma análise e, combinada com o WHOIS do ASN, você pode transformar a qualidade da rede em uma auditoria de dados reproduzível. Se você também quiser identificar os riscos operacionais por trás dos provedores de nuvem, consulte o Guia de identificação de provedores de nuvem, e faça uma verificação cruzada da autenticidade da rota com a credibilidade do provedor.
Como medir o caminho de retorno
VPS o segredo do teste de velocidade de rede não está na largura de banda, mas no caminho de retorno. Primeiro, separe "ida" e "volta": do local até o VPS é a ida, e do VPS de volta ao local é o retorno. A maioria dos provedores otimiza apenas a ida, e o retorno passando pelos EUA ou Europa fica evidente. Usar MTR com envio contínuo de pacotes para ver latência e perda em cada salto é mais confiável do que um traceroute único:
mtr -r -c 20 --no-dns <seu IP>Em seguida, foque na atribuição de ASN de cada salto. Não olhe apenas o IP; use WHOIS ou bgp.he.net para consultar o ASN do prefixo daquele salto e verificar se passa pelo nó esperado. Por exemplo, ao acessar da China via Telecom, se o retorno passar por AS4134 (Telecom), está normal; se aparecer AS4809 ou AS174 (Cogent), provavelmente está desviando, e a latência e a perda de pacotes aumentarão visivelmente.
Armadilha: provedores anunciam "ASN falso". Verificar se o Route Registry e o WHOIS são consistentes pode revelar se a rota é real.
Cruzar isso: é a mesma lógica forense da identificação de provedores de nuvem. Você usa o ASN para verificar a autenticidade da rota, assim como usa faturas para conferir a taxa de prêmio do FinOps — trocar o "CN2/GIA" divulgado pelo retorno real mostra se o prêmio valeu a pena. Da mesma forma, a ideia de redução de recursos abordada em /guides/cloud-serve também pode ser comprovada com dados de retorno. Depois de medir o retorno, somando largura de banda e latência, é possível transformar a qualidade da rede em uma auditoria de dados reproduzível.
Como comprovar largura de banda inflada
Os números de largura de banda são apenas a “fachada”; o que realmente determina a experiência é o caminho. Para coletar evidências, primeiro divida o “teste de velocidade” em três camadas: throughput, latência e rota de retorno. Use MTR ou traceroute para enviar 100 pacotes, registrando o ASN de cada salto — o comando whois -h whois.radb.net -- '-i origin ASXXXX' permite identificar a origem. Se um VPS afirma ser “CN2 GIA”, mas no terceiro salto já pula para Level3 ou Telia, provavelmente é um anúncio falso ou otimização parcial. Execute novamente no horário de pico (20:00–23:00) e observe a variação de RTT e a localização da perda de pacotes: se a perda estiver concentrada em um segmento de peer de determinado operador, isso indica limitação de QoS, não congestionamento de rede.
Uma abordagem mais avançada é comparar a consistência entre o Route Registry e o WHOIS. Alguns provedores anunciam prefixos ASN que não existem. Use bgpq4 ou bgp.he.net para verificar a origem da rota — uma consulta já revela a fraude. Outro ponto sutil: para o mesmo modelo de VPS, em diferentes intervalos de IP, a rota de retorno pode ser completamente oposta — um pode passar pela China Telecom 163 e outro pela China Unicom CUVIP, dependendo do upstream que o provedor comprou para cada bloco, não de uma “distribuição aleatória”.
Resuma esses dados em uma tabela: propriedade do ASN, rota de retorno, latência no horário de pico, taxa de perda de pacotes — e compare com as descrições da página do produto do provedor. Se o plano anuncia “1000Mbps”, mas o iperf3 em thread única entrega apenas 30Mbps, e a janela TCP é pequena, então é limitação de velocidade ou overprovisioning. Nesse caso, use o script de teste de rede VPS para executar um benchmark padrão — os resultados são reproduzíveis.
Por fim, não se esqueça de converter os resultados da investigação em perspectiva de custo: na mesma faixa de preço, um VPS com rota que passa pelos EUA, mesmo com largura de banda maior, tem custo real de throughput muito mais alto do que uma rota direta — é isso que o índice de prêmio do FinOps desconta como “margem de lucro fictícia”. A identificação de provedores de nuvem é semelhante: a propriedade do ASN e a qualidade da rota de retorno indicam se o fornecedor realmente usa largura de banda dedicada ou se está disfarçando banda compartilhada como dedicada. Da próxima vez que alguém gabar-se de “banda larga”, peça primeiro a tabela de ASN e a taxa de perda de pacotes no horário de pico.
Como identificar congestionamento e limitação de velocidade
Por mais bonitos que sejam os números de largura de banda, o congestionamento no horário de pico noturno revela a verdade. Para avaliar a limitação, não basta olhar apenas o pico instantâneo do Speedtest; é preciso observar a janela de congestionamento — use mtr por 5 minutos contínuos e monitore a taxa de perda de pacotes e o jitter (variação de latência). Se a latência saltar de 20ms para 200ms acompanhada de perda de pacotes acima de 5%, é praticamente certo que há congestionamento no peer upstream ou QoS/limitação imposta pelo provedor.
O mais importante é verificar a origem do IP de cada salto:
for ip in $(mtr -r -c 10 8.8.8.8 | awk '{print $2}' | grep -v '^|' | tail -n +2); do whois $ip | grep -E 'origin|netname' | head -2; echo "---"; doneCompare com os registros de ASN e Route Registry. Se o provedor anuncia CN2 GIA, mas o caminho de retorno real mostra ASNs da Level3 ou Telia, é bem provável que seja uma rota falsa. Essa verificação cruzada ajuda a identificar VPS "disfarçados" — muitos provedores de nuvem (especialmente revendedores de baixo custo) usam rotas comuns se passando por rotas otimizadas, e a checagem de ASN desmascara isso.
Aliás, do ponto de vista de FinOps: se você paga 30% a mais por "baixa latência", mas o MTR mostra que a taxa de transferência cai para um décimo em caso de congestionamento, esse prêmio está efetivamente pagando a conta de um provedor superdimensionado (overselling). As máquinas que realmente valem manter são aquelas com ASN de retorno estável, diferença de latência inferior a 20ms entre as três redes principais e perda de pacotes zero no horário de pico. Usar esse método de auditoria é muito mais confiável do que olhar as páginas de propaganda do provedor.
Taxa de prêmio e decisões de compra
Quando a autenticidade da rota é confirmada por três vias — atribuição de ASN, caminho de retorno e latência em tempo real — a "taxa de prêmio" deixa de ser misticismo. Costumo aplicar uma perspectiva de custo no estilo FinOps à compra de VPS: primeiro, executo um vps network speed test (o script YABS serve), depois uso mtr -z para extrair o ASN de cada salto, combino com whois para confirmar a origem da divulgação e, por fim, faço a validação cruzada com a taxa de perda de pacotes do return path durante o pico noturno por 3 dias consecutivos. Com esse procedimento, as "redes premium" e as "rotas comuns" dos provedores ficam bem expostas.
Taxa de prêmio = (throughput realmente medido + pontuação de qualidade do caminho de retorno) / custo anual. Por exemplo, um provedor anuncia 1 Gbps de banda, mas o ASN mostra que seus peers são em sua maioria IXs pouco conhecidos, o caminho de retorno passa pelos EUA e a perda de pacotes no pico noturno é de 8%; nesse caso, isso vale apenas US$ 20/ano. Por outro lado, se o ASN está diretamente conectado à CN2 da Telecom, o caminho de retorno tem conexão direta nas três redes e o packet loss se aproxima de zero, mesmo custando US$ 60 a mais, vale a pena. Ao comparar com configurações semelhantes em nuvens públicas, essa auditoria ajuda a enxergar, no nível de "identificação do provedor de nuvem", se você está pagando um "imposto de inteligência de rota".
Lista de decisão:
- Verificar ASN:
whois -h whois.radb.net -- -i origin ASxxxxx, confira se corresponde ao que o provedor declara - Medir o caminho de retorno:
mtr -r -c 100 -z IP_do_destino, veja se o ASN dos últimos três saltos é do backbone das três redes - Calcular o prêmio: largura de banda ÷ latência × fator de perda de pacotes, depois divida pelo preço e obtenha o índice de custo-benefício
Por fim, não esqueça: a boa reputação vem de dados reproduzíveis, não de capturas de tela do provedor. Arquive os resultados de cada teste; na próxima seleção ou downgrade, basta consultar o histórico e também comparar com a linha de base de nuvens públicas em /guides/cloud-serve para reduzir a margem de prêmio.
FAQ
Como usar o ASN para identificar a autenticidade da rota de um VPS?
Consulte a origem do ASN e compare se o data center anunciado no site oficial e o número AS são consistentes.
Como o caminho de retorno valida a qualidade da rede do VPS?
Use traceroute para visualizar os nós de retorno; se houver desvio ou perda de pacotes, a rota é instável.
Como cruzar ASN, rota de retorno e latência?
Combine a origem do ASN, os nós de retorno e a variação de latência; somente com consistência a rota é considerada de qualidade.