Global Ping
Le ping mondial lance une mesure — ping, HTTP, DNS, traceroute ou MTR — depuis des sondes dans des réseaux du monde entier au même moment, pour que vous voyiez si un problème est partout ou seulement sur votre chemin. Choisissez une mesure, nommez une cible, choisissez jusqu’à quatre lieux et comparez les réponses côte à côte.
Vous voulez une surveillance depuis de nombreux lieux, 24 h/24 ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Une mesure, de nombreux points de vue
Chaque test réseau que vous lancez depuis votre bureau répond à une question plus étroite que vous ne le pensez : non pas « cet hôte est-il en ligne ? », mais « est-il en ligne depuis ici, via mon fournisseur, via mon peering, en ce moment même ? ». Internet n’a aucun point de vue unique, et la plupart des pannes déroutantes sont locales d’une manière invisible de l’intérieur — une route cassée dans une région, un résolveur empoisonné dans un pays, un nœud anycast qui tombe pour un continent en servant joyeusement un autre. Le ping mondial retire votre propre chemin de l’équation en lançant la mesure identique depuis des sondes bénévoles dans des réseaux sans rapport, au même moment. Quand chaque sonde s’accorde à dire que la cible est tombée, elle est tombée. Quand une ville échoue et que les autres passent sans encombre, le problème vit sur un chemin, pas à la destination — et cette seule distinction fait généralement la moitié du travail de débogage.
Les cinq mesures répondent à des suites différentes. Le ping donne le temps aller-retour et la perte de paquets, la santé brute de la joignabilité. HTTP chronomètre une vraie requête et renvoie le code de statut, attrapant la grande classe de pannes où un hôte répond au ping mais où le service ne fonctionne pas. DNS interroge les résolveurs locaux de chaque sonde, ce qui permet d’attraper une réponse correcte à Francfort et fausse à Singapour. Traceroute liste les sauts de la sonde à la cible, pour voir où les chemins divergent. MTR combine les deux, en pingant chaque saut à répétition, ce qui sépare « le dernier saut est lent » de « un lien du milieu perd des paquets et tout ce qui suit ne fait qu’hériter du blâme ».
Comment lire un résultat partagé
Commencez par l’accord. Si toutes les sondes rapportent des temps similaires et les mêmes réponses, votre propre problème se trouve presque sûrement entre vous et l’internet au sens large — votre fournisseur, votre VPN ou votre résolveur local. Si un seul lieu est en désaccord, soupçonnez la géographie : le routage se fait par réseau, et le mauvais chemin d’un seul fournisseur de transit peut engloutir une région en laissant tous les autres intacts. Si les réponses DNS diffèrent selon le lieu pour un nom qui n’est pas volontairement géo-dirigé, c’est une faute, pas une fonction — les résolveurs devraient converger vers les mêmes enregistrements une fois les caches expirés. Et quand une cible se résout à dessein à des adresses différentes selon les lieux, vous regardez l’anycast ou le geo-DNS fonctionner comme prévu : comparez chaque sonde à l’adresse qu’elle a réellement atteinte, que cette page imprime, plutôt que d’attendre une seule vraie réponse.
Outils associés : le bilan de santé du site pour le tableau complet d’un site depuis le serveur de sysosx, le vérificateur de propagation DNS pour savoir si quatre grands résolveurs publics s’accordent sur un nom, et l’article compagnon est-ce en panne, ou est-ce juste vous ?, sur l’usage de nombreux points de vue pour trancher exactement cette question.
Attribution et honnêteté : les mesures tournent sur le réseau Globalping de jsDelivr, exécutées par des sondes bénévoles hébergées dans des réseaux du monde entier — traitez le réseau comme la ressource partagée qu’il est. Cette page utilise le niveau gratuit partagé, donc des limites par visiteur s’appliquent, les cibles populaires sont mises en cache brièvement, et aux moments chargés le service amont lui-même peut saturer, ce que la page signale au lieu de le déguiser en panne de la cible.
Cinq termes qui rendent les résultats lisibles
| Sonde | Un petit agent qui tourne dans le réseau de quelqu’un d’autre — une connexion domestique, une VM cloud, une université — qui effectue la mesure là où il se trouve et rapporte le résultat. |
| Point de vue | L’endroit d’où une mesure est prise ; la même cible peut paraître saine depuis un point de vue et cassée depuis un autre, et les deux observations peuvent être vraies. |
| Anycast | Annoncer la même adresse IP depuis de nombreux lieux à la fois, pour que chaque utilisateur atteigne l’instance la plus proche — c’est pourquoi des sondes différentes atteignent légitimement des machines différentes à une même adresse. |
| Perte de paquets | La part des paquets envoyés qui ne revient jamais ; un peu de perte sur un long chemin est survivable, une perte soutenue signifie que quelque chose sur le chemin jette du trafic. |
| MTR | Un hybride de ping et de traceroute qui pingue chaque saut du chemin à répétition, montrant perte et latence par saut au lieu du seul point de destination. |
Questions fréquentes
Pourquoi les lieux doivent-ils être tapés en anglais ?
L’API Globalping compare les noms de lieux à son propre répertoire géographique en anglais de villes, régions et pays. « Frankfurt », « New York » et « Singapore » correspondent de façon fiable ; un nom de ville traduit ne correspond généralement à rien, et la mesure ne peut pas démarrer. Les quatre cases sont donc étiquetées honnêtement : tapez le lieu en anglais et utilisez la liste de suggestions, qui propose dix villes bien couvertes. Une sonde est sélectionnée pour chaque lieu que vous nommez.
Une sonde dit hors ligne ou en échec. La cible est-elle tombée ?
Non — ce résultat parle de la sonde, pas de la cible. Une sonde peut passer hors ligne, perdre sa propre connectivité ou être incapable d’exécuter un type de mesure ; les résultats des autres sondes restent valables. Jugez la cible d’après les sondes qui ont terminé : si elles s’accordent, leur verdict est la réponse, et une seule sonde en échec est du bruit sur le réseau de mesure lui-même.
Pourquoi les résultats sont-ils parfois mis en cache, et pourquoi ces limites ?
Les mesures consomment un réseau partagé et bénévole, sur un niveau gratuit au budget horaire modeste partagé par tous ceux qui l’utilisent via ce site. Pour que ce soit équitable, chaque visiteur dispose d’un nombre limité de mesures fraîches, et répéter la même mesure dans une courte fenêtre renvoie la copie en cache, signalée comme telle. Si le niveau gratuit amont lui-même est épuisé, la page le dit clairement au lieu d’inventer un résultat.
Le ping fonctionne mais HTTP échoue (ou l’inverse). Qu’est-ce que cela signifie ?
Ils testent des couches différentes. Le ping prouve que la pile réseau de l’hôte répond à ICMP ; il ne dit rien du serveur web, qui peut être tombé, mal configuré ou renvoyer des erreurs — un résultat HTTP avec un code 5xx, c’est un réseau qui fonctionne et un service cassé. L’inverse — HTTP fonctionne, le ping expire — est aussi fréquent et généralement innocent : beaucoup d’hôtes et de pare-feux jettent volontairement l’ICMP tout en servant le trafic normalement.
Puis-je tester depuis plus de quatre lieux, ou lancer cela en continu ?
Cette page lance jusqu’à quatre sondes par mesure pour rester dans le niveau gratuit partagé. Pour une vérification continue depuis de nombreux lieux — la version « réveille-moi quand ça casse quelque part » de cet outil — un service de surveillance est la bonne forme ; le lien sous le formulaire propose une surveillance gratuite via myeventwatch. Pour une question ponctuelle, quatre lieux bien répartis suffisent généralement à séparer « tombé partout » de « tombé seulement pour certains ».