Le réseau VPS ne se limite pas à la bande passante : identifier l'authenticité de la ligne avec l'ASN et le chemin de retour

Transformez la qualité réseau en un audit de données reproductible.

Mis à jour 2026-08-16 · CloudWorth

ASNchemin de retourtest de vitesse réseauaudit de lignerapport qualité-prix VPSCloudWorthSteal TimeSurvente VPSBenchmark VPS

La combinaison de l'attribution ASN, du chemin de retour et de la latence en recoupement permet d'identifier l'authenticité de la ligne et les surfacturations.

Que révèle l'attribution ASN

Lors de l'achat d'un VPS, on regarde d'abord les chiffres de bande passante, mais les cas de "port gigabit" qui se transforment en diaporama aux heures de pointe sont trop nombreux. La bande passante n'est qu'une limite supérieure ; la véritable qualité de la ligne dépend du chemin réel emprunté par le trafic — la première chose à faire est de vérifier l'attribution ASN. Avec whois ou des outils de recherche ASN en ligne pour examiner l'ASN de l'IP, on peut immédiatement déterminer à quel centre de données ou opérateur appartient cette plage d'IP. Par exemple, si un fournisseur annonce "CN2 GIA" mais que l'ASN s'avère être Cogent ou NTT ordinaire, il y a de fortes chances que ce soit de la fausse publicité ou de la revente NAT.

Plus important encore, l'ASN peut révéler la stratégie de routage. Différentes plages d'IP du même fournisseur peuvent annoncer des ASN différents, entraînant d'énormes différences de chemins de retour pour les trois grands réseaux. En utilisant MTR pour examiner l'ASN à chaque saut, si le chemin passe par les États-Unis ou l'Europe, la latence et la perte de paquets seront naturellement élevées. Cela explique aussi pourquoi la même offre VPS peut donner une expérience radicalement différente selon la plage d'IP. Lors de la vérification inverse, il faut aussi comparer la cohérence entre le Route Registry et le WHOIS, afin d'éviter que le fournisseur ne falsifie le numéro ASN.

D'un point de vue coût cloud, l'attribution ASN est directement liée au taux de prime FinOps. Les ASN de qualité (comme Telecom 4134, Unicom 9929) ont des coûts de bande passante bien supérieurs aux lignes internationales ordinaires. On peut évaluer si cette prime dans le prix du fournisseur est raisonnable grâce à un audit ASN. Beaucoup de machines en survente économisent sur la qualité en utilisant des fournisseurs en amont moins chers, ce que l'ASN révèle immédiatement. En utilisant l'outil de test de vitesse de ce site puis en combinant avec le WHOIS ASN, on peut transformer la qualité du réseau en un audit de données reproductible. Si vous souhaitez également identifier les risques opérationnels derrière les fournisseurs de cloud, consultez le guide d'identification des fournisseurs de services cloud pour croiser l'authenticité de la ligne et la crédibilité du fournisseur.

Comment mesurer le chemin de retour

L'essentiel du test de vitesse réseau d'un VPS ne réside pas dans la bande passante, mais dans le chemin de retour. Commencez par distinguer l'aller et le retour : de votre local vers le VPS, c'est l'aller ; du VPS vers votre local, c'est le retour. La plupart des fournisseurs n'optimisent que l'aller, et le retour qui transite par les États-Unis ou l'Europe se révèle alors. Utilisez MTR pour envoyer des paquets en continu et observer la latence et la perte de paquets à chaque saut, c'est plus fiable qu'un simple traceroute :

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

Ensuite, concentrez-vous sur l'attribution ASN de chaque saut. Ne regardez pas seulement l'adresse IP, utilisez WHOIS ou bgp.he.net pour vérifier l'ASN du préfixe de ce saut, et déterminez si le trafic passe par le nœud attendu. Par exemple, pour un accès depuis China Telecom, si le retour passe par AS4134 (China Telecom), c'est normal ; si AS4809 ou AS174 (Cogent) apparaît, il y a de fortes chances que le trafic soit détourné, et la latence ainsi que la perte de paquets augmenteront nettement.

Piège : les fournisseurs annoncent de « faux ASN ». Vérifiez la cohérence entre le Route Registry et le WHOIS pour déduire si le routage est réel.

Recoupez : c'est la même logique d'investigation que pour l'identification des fournisseurs cloud. Vous utilisez l'ASN pour vérifier l'authenticité de la ligne, comme vous utiliseriez une facture pour vérifier le taux de majoration FinOps — en remplaçant le « CN2/GIA » annoncé par le chemin de retour réel, vous saurez si la majoration en vaut la peine. De même, l'approche de réduction de configuration abordée dans /guides/cloud-serve peut être corroborée par les données du chemin de retour. Une fois le retour mesuré, ajoutez la bande passante et la latence, et vous transformerez la qualité du réseau en un audit de données reproductible.

Comment prouver la surévaluation de la bande passante

Le chiffre de bande passante n'est qu'une vitrine ; c'est le chemin qui détermine réellement l'expérience. Pour recueillir des preuves, commencez par décomposer le « test de vitesse » en trois couches : débit, latence et chemin de retour. Utilisez MTR ou traceroute pour envoyer 100 paquets et notez l'ASN de chaque saut. La commande whois -h whois.radb.net -- '-i origin ASXXXX' permet de retrouver le propriétaire. Si un VPS prétend être « CN2 GIA » mais qu'au troisième saut il passe par Level3 ou Telia, il s'agit probablement d'une fausse annonce ou d'une optimisation partielle du chemin. Relancez le test aux heures de pointe (20h00–23h00) pour observer la gigue de RTT et l'emplacement des pertes de paquets. Si les pertes sont concentrées sur un segment de peering d'un opérateur, cela indique une limitation QoS plutôt qu'une congestion du réseau.

Une approche plus avancée consiste à comparer la cohérence entre le Route Registry et le WHOIS. Certains fournisseurs annoncent des préfixes ASN inexistants. Avec bgpq4 ou bgp.he.net, vous pouvez vérifier l'origine de la route et les démasquer rapidement. Un autre point subtil : pour un même VPS, selon la plage IP, le chemin de retour peut être totalement différent — l'un passe par China Telecom 163, l'autre par China Unicom CUVIP. Cela dépend de l'upstream acheté par le fournisseur pour chaque segment, et non d'une « attribution aléatoire ».

Regroupez ces données dans un tableau : propriétaire de l'ASN, chemin de retour, latence en heure de pointe, taux de perte de paquets, puis comparez avec la description de la page produit du fournisseur. Si la bande passante annoncée est de « 1000 Mbps » mais qu'iperf3 en monothread ne donne que 30 Mbps avec une fenêtre TCP minuscule, il s'agit d'une limitation de débit ou de survente. À ce stade, utilisez le script de test de débit réseau VPS pour exécuter un benchmark standard ; les résultats sont reproductibles.

Enfin, n'oubliez pas de traduire les résultats en termes de coût : à prix égal, un VPS dont le trafic passe par les États-Unis aura un coût de débit réel bien supérieur à celui d'une connexion directe, même avec une bande passante plus large. C'est exactement la « marge fictive » que le taux de prime FinOps doit déduire. Il en va de même pour l'identification des fournisseurs de cloud : l'attribution de l'ASN et la qualité du chemin de retour indiquent si le vendeur utilise réellement une bande passante dédiée ou s'il la fait passer pour de la bande passante partagée. La prochaine fois que quelqu'un vante une « grande bande passante », exigez d'abord ses tables ASN et son taux de perte de paquets en heure de pointe.

Comment détecter la congestion et la limitation de débit

Quelle que soit la beauté des chiffres de bande passante, la congestion en heure de pointe révèle la réalité. Pour juger de la limitation de débit, il ne faut pas se fier uniquement au pic instantané de Speedtest, mais surveiller la fenêtre de congestion — en exécutant mtr en continu pendant 5 minutes, en observant le taux de perte de paquets et la gigue (jitter). Si la latence passe de 20 ms à 200 ms avec une perte de paquets de 5% ou plus, on peut raisonnablement conclure à une congestion du peer en amont ou à une limitation QoS de la part du fournisseur.

Le plus important est de vérifier la propriété des IP de chaque saut :

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

Croisez-les avec les enregistrements ASN et Route Registry. Si le fournisseur annonce du CN2 GIA mais que le chemin de retour contient des ASN de Level3 ou Telia, il y a de fortes chances que ce soit une fausse ligne. Cette vérification croisée vous aide à identifier les VPS « déguisés » — de nombreux fournisseurs cloud (en particulier les revendeurs à bas prix) font passer des lignes ordinaires pour des lignes optimisées ; un simple contrôle de la propriété des ASN suffit à les démasquer.

D'un point de vue FinOps : supposons que vous payiez 30% de plus pour une « faible latence », mais que le MTR montre que le débit chute au dixième en cas de congestion. Cette prime finance en réalité un fournisseur en survente. Une machine qui vaut la peine d'être conservée est celle dont l'ASN de retour est stable, dont la différence de latence entre les trois réseaux est inférieure à 20 ms, et qui présente une perte de paquets nulle en heure de pointe. Utiliser cette méthode pour auditer est bien plus fiable que de se fier aux pages publicitaires des fournisseurs.

Taux de prime et décisions d'achat

Lorsque l'authenticité de la ligne est verrouillée par l'attribution ASN, le chemin de retour et la latence en temps réel, le « taux de prime » n'est plus de la métaphysique. J'applique généralement une perspective de coûts de type FinOps à l'achat de VPS : d'abord exécuter un vps network speed test (le script YABS est suffisant), puis utiliser mtr -z pour extraire l'ASN de chaque saut, confirmer la source de diffusion avec whois, et enfin recouper avec le taux de perte de paquets du return path pendant les heures de pointe pendant 3 jours consécutifs. Après cette série, le « réseau premium » et la « ligne ordinaire » des marchands sont exposés très clairement.

Taux de prime = (débit mesuré réel + score de qualité du chemin de retour) / coût annuel. Par exemple, un marchand annonce une bande passante de 1 Gbps, mais l'ASN montre que ses pairs sont surtout des IX peu fréquentés, le chemin de retour passe par les États-Unis, avec 8 % de perte de paquets en heure de pointe : il ne vaut alors que 20 $/an ; à l'inverse, si l'ASN est directement connecté à Telecom CN2, que le chemin de retour est direct pour les trois réseaux et que la packet loss tend vers zéro, même 60 $ de plus valent le coup. Comparé à des configurations de cloud public similaires, cet audit vous aide à voir, au niveau de l'« identification des fournisseurs de cloud », si l'on vous facture une « taxe de crédulité » pour la ligne.

Liste de décision :

• Vérifier l'ASN : whois -h whois.radb.net -- -i origin ASxxxxx, confirmer la cohérence avec les annonces du marchand
• Tester le chemin de retour : mtr -r -c 100 -z target IP, vérifier si les ASN des trois derniers sauts sont des backbones des trois réseaux
• Calculer la prime : débit ÷ latence × facteur de perte, puis diviser par le prix, obtenir l'indice de rapport qualité-prix

Enfin, n'oubliez pas que la véritable réputation vient de données reproductibles, pas de captures d'écran du marchand. Archivez chaque résultat de test, récupérez directement les historiques lors de la prochaine sélection ou réduction de configuration, et comparez avec la ligne de base du cloud public dans /guides/cloud-serve pour réduire la marge de prime.