La red de un VPS no solo depende del ancho de banda: verifica la autenticidad de la ruta con ASN y retorno

Convierte la calidad de red en una auditoría de datos reproducible.

Actualizado 2026-08-16 · CloudWorth

ASNruta de retornoprueba de velocidad de redauditoría de rutasrelación calidad-precio del VPSCloudWorthSteal TimeSobreventa VPSBenchmark VPS

Solo la combinación de propiedad del ASN, ruta de retorno y verificación cruzada de latencia permite identificar rutas auténticas y precios inflados.

¿Qué puede revelar la atribución del ASN?

Al comprar una VPS, todos se fijan primero en las cifras de ancho de banda, pero hay demasiados casos de puertos de "gigabit" que en las horas punta nocturnas se quedan como una presentación de diapositivas. El ancho de banda es solo el límite superior; la calidad real de la ruta depende del camino que realmente toman los datos. Lo primero es verificar la atribución del ASN. Usa whois o herramientas en línea de consulta de ASN para ver el ASN de la IP, y así podrás determinar de inmediato a qué centro de datos y a qué proveedor pertenece ese rango de IPs. Por ejemplo, si un proveedor promociona "CN2 GIA", pero el ASN resulta ser de Cogent o NTT común, lo más probable es que sea publicidad falsa o reventa NAT.

Lo más importante es que el ASN puede revelar la estrategia de enrutamiento. Diferentes rangos de IP del mismo proveedor pueden anunciar diferentes ASN, lo que da lugar a grandes diferencias en las rutas de retorno de las tres redes principales (China Telecom, China Unicom, China Mobile). Con MTR puedes observar el ASN de cada salto; si la ruta da un rodeo por Estados Unidos o Europa, la latencia y la pérdida de paquetes serán naturalmente altas. Esto también explica por qué diferentes rangos de IP de la misma VPS pueden ofrecer experiencias totalmente distintas. Al hacer el análisis inverso, también hay que comprobar la coherencia entre el Route Registry y el WHOIS para evitar que los proveedores falsifiquen los números de ASN.

Desde la perspectiva del costo de la nube, la atribución del ASN está directamente relacionada con la tasa de prima de FinOps. El costo de ancho de banda de los ASN de alta calidad (como Telecom 4134, Unicom 9929) es mucho mayor que el de las líneas internacionales comunes. La razonabilidad de esta prima en el precio del proveedor puede evaluarse mediante una auditoría del ASN. Muchas máquinas "sobrevendidas" recortan gastos cambiando a proveedores de nivel superior más baratos, y esto se detecta fácilmente con el ASN. Puedes ejecutar la herramienta de medición de velocidad de este sitio y, combinándola con el WHOIS del ASN, convertir la calidad de la red en una auditoría de datos reproducible. Si además quieres identificar los riesgos operativos detrás de los proveedores de nube, puedes consultar la Guía para identificar proveedores de servicios en la nube y verificar de forma cruzada la autenticidad de la ruta con la credibilidad del proveedor.

Cómo medir la ruta de retorno

El factor clave en la prueba de velocidad de red de un VPS no es el ancho de banda, sino la ruta de retorno. Primero separa la "ruta de ida" de la "ruta de retorno": desde el equipo local hasta la VPS es la ruta de ida, y desde la VPS de vuelta al equipo local es la ruta de retorno. La mayoría de los proveedores solo optimizan la ruta de ida, así se hace evidente cuando la ruta de retorno da rodeos por Estados Unidos o Europa. Usar MTR para enviar paquetes de forma continua y ver la latencia y pérdida de paquetes en cada salto es más fiable que un traceroute único:

mtr -r -c 20 --no-dns <你的IP>

A continuación, céntrate en la pertenencia ASN de cada salto. No mires solo la IP; usa WHOIS o bgp.he.net para consultar el ASN del prefijo de ese salto y determinar si pasa por el nodo esperado. Por ejemplo, para accesos desde China Telecom, si el retorno pasa por AS4134 (China Telecom) es normal; si aparece AS4809 o AS174 (Cogent), lo más probable es que haya un rodeo, y la latencia y la pérdida de paquetes aumentarán notablemente.

Trampa: el proveedor anuncia un "ASN falso". Verifica si el Route Registry y el WHOIS coinciden para deducir si la ruta es real.

Cruza los datos: esta es la misma lógica forense que la identificación de proveedores de nube. Usas el ASN para verificar la autenticidad de la línea, igual que usas las facturas para comprobar la tasa de sobreprecio en FinOps: sustituyes el "CN2/GIA" promocionado por el retorno real, y entonces sabes si el sobreprecio valió la pena. De manera similar, las ideas de reducción de configuración que se mencionan en /guides/cloud-serve también pueden respaldarse con los datos de retorno. Una vez que se mide el retorno, si se añaden el ancho de banda y la latencia, se puede convertir la calidad de la red en una auditoría de datos reproducible.

Cómo verificar la exageración del ancho de banda

Los números de ancho de banda son solo la "fachada"; lo que realmente determina la experiencia es la ruta. Para obtener pruebas, primero desglose la "prueba de velocidad" en tres capas: rendimiento, latencia y ruta de retorno. Use MTR o traceroute con 100 paquetes, registre el ASN de cada salto: el comando whois -h whois.radb.net -- '-i origin ASXXXX' puede revertir la consulta de propiedad; si el VPS afirma ser "CN2 GIA", pero en el tercer salto ya salta a Level3 o Telia, probablemente sea una falsa difusión u optimización de medio camino. Vuelva a ejecutarlo durante las horas pico (20:00–23:00) y observe la fluctuación del RTT y la ubicación de la pérdida de paquetes: si la pérdida se concentra en el segmento peer de un operador, indica limitación de QoS, no congestión de la línea.

Un enfoque más avanzado es comparar la coherencia entre el Route Registry y WHOIS. Algunos proveedores difunden prefijos ASN inexistentes; use bgpq4 o bgp.he.net para verificar el origen de la ruta y se descubrirá rápidamente. Otro punto sutil: el mismo modelo de VPS con diferentes rangos de IP puede tener rutas de retorno completamente opuestas: uno pasa por Telecom 163, otro por Unicom CUVIP; esto depende del upstream que el proveedor compró para cada rango, no es una "asignación aleatoria".

Resuma estos datos en una tabla: propiedad del ASN, ruta de retorno, latencia en horas pico, tasa de pérdida de paquetes, y compárelos con la descripción de la página del producto del proveedor. Si dice "1000Mbps" pero iperf3 con un solo hilo solo obtiene 30Mbps y la ventana TCP es pequeña, entonces hay limitación o sobresuscripción. En este punto, ejecute un benchmark estándar con el script de prueba de red VPS y los resultados serán reproducibles.

Por último, no olvide convertir los resultados de las pruebas a una perspectiva de costos: al mismo precio, un VPS con una ruta que da rodeos por Estados Unidos, incluso con mayor ancho de banda, tiene un costo de rendimiento real mucho más alto que una ruta directa; esto es exactamente la "tasa de ganancia falsa" que la prima de FinOps debe deducir. Lo mismo aplica para la identificación de proveedores de nube: la propiedad del ASN y la calidad de la ruta de retorno están relacionadas con si el proveedor realmente usa ancho de banda dedicado o se hace pasar por ancho de banda compartido. La próxima vez que alguien alardee de "gran ancho de banda", pídale primero que entregue la tabla de ASN y la tasa de pérdida de paquetes en horas pico.

Cómo determinar la congestión y la limitación de velocidad

Por muy bonitos que sean los números de ancho de banda, la congestión en hora punta los delata. Para juzgar la limitación, no basta con mirar el pico instantáneo de Speedtest; hay que fijarse en la ventana de congestión: usa mtr durante 5 minutos y observa la pérdida de paquetes y la fluctuación de latencia (jitter). Si la latencia salta de 20ms a 200ms con una pérdida de paquetes superior al 5%, se puede concluir que hay congestión en el peer de subida o que el proveedor ha aplicado limitación por QoS.

Lo más importante es verificar la propiedad de la 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 "---"; done

Compara con los registros ASN y Route Registry. Si el proveedor anuncia CN2 GIA pero en la ruta de retorno aparecen ASN de Level3 o Telia, lo más probable es que sea una ruta falsa. Esta verificación cruzada te ayuda a identificar VPS "disfrazados": muchos proveedores de la nube (especialmente revendedores de bajo costo) hacen pasar rutas comunes por rutas optimizadas; una simple consulta de ASN lo desenmascara.

De paso, un comentario desde la perspectiva FinOps: supón que pagas un 30% más por la "baja latencia", pero MTR muestra que el rendimiento cae a una décima parte durante la congestión. Ese sobreprecio en realidad está pagando por los proveedores sobresuscritos. Las máquinas que realmente merecen conservarse son aquellas con un ASN de retorno estable, una diferencia de latencia entre las tres redes inferior a 20ms y una pérdida de paquetes del 0% en hora punta. Auditar con este método es mucho más fiable que mirar la página promocional del proveedor.

Prima de precio y decisiones de compra

Cuando la autenticidad de la ruta está confirmada por la atribución ASN, la ruta de retorno y la latencia en tiempo real, la "prima de precio" deja de ser una mística. Suelo aplicar una perspectiva de costes al estilo FinOps a la compra de VPS: primero ejecuto vps network speed test (con el script YABS basta), luego uso mtr -z para extraer el ASN de cada salto, confirmo la fuente de difusión con whois, y finalmente cruzo la tasa de pérdida de paquetes de la ruta de retorno durante los picos de la tarde durante 3 días consecutivos. Con este proceso, las "redes premium" y las "rutas ordinarias" de los proveedores quedan al descubierto.

Prima de precio = (rendimiento medido + puntuación de calidad de la ruta de retorno) / coste anual. Por ejemplo, si un proveedor anuncia 1 Gbps de ancho de banda, pero el ASN muestra que sus peers son en su mayoría IX poco conocidos, la ruta de retorno pasa por Estados Unidos y la pérdida de paquetes en hora punta es del 8%, entonces solo vale $20/año; por el contrario, si el ASN se conecta directamente a CN2 de Telecom, la ruta de retorno es directa a las tres redes y la pérdida de paquetes tiende a cero, aunque cueste $60 más, merece la pena. Comparando con configuraciones similares en nubes públicas, esta auditoría te ayuda a ver desde la perspectiva de "identificación del proveedor de nube" si te están cobrando un "impuesto por la inteligencia de la ruta".

Lista de verificación:

• Consultar ASN: whois -h whois.radb.net -- -i origin ASxxxxx, verificar que coincide con lo que afirma el proveedor.
• Probar la ruta de retorno: mtr -r -c 100 -z IP_objetivo, observar si el ASN de los últimos tres saltos es del backbone de las tres redes.
• Calcular la prima: ancho de banda ÷ latencia × factor de pérdida de paquetes, y luego dividir por el precio para obtener el índice de relación calidad-precio.

Por último, recuerda que la verdadera reputación proviene de datos reproducibles, no de capturas del proveedor. Archiva los resultados de cada prueba y, la próxima vez que elijas o reduzcas la configuración, consulta directamente el historial, comparando también con la línea base de la nube pública en /guides/cloud-serve para reducir el margen de la prima.