Ping

Ping est un outil gratuit qui vérifie si un site web, un serveur ou un port est accessible, puis indique son temps de réponse, son code d'état ou l'erreur rencontrée.

Que vérifie réellement un test ping ?

Un test ping détermine si un système distant répond depuis le réseau où le contrôle est exécuté. La vérification exacte dépend du protocole sélectionné.

• HTTP(s) teste une URL web en HTTP ou HTTPS. Ce protocole convient aux sites web, aux API et aux services web, car il peut renvoyer un code d'état HTTP.
• Ping (ICMP) vérifie si un hôte répond aux requêtes d'écho du protocole Internet Control Message Protocol. C'est le sens traditionnel du terme "ping" en réseau.
• Hôte / Port vérifie si un port réseau précis est accessible sur un hôte. Il peut par exemple s'agir d'un serveur de messagerie SMTP, d'un serveur POP ou du point de terminaison d'une base de données.

Ces contrôles répondent à des questions légèrement différentes. Une réponse ICMP montre qu'un hôte accepte ce type de trafic réseau et y répond, mais ne prouve pas que son site web ou son service de messagerie fonctionne. Une réponse HTTP fournit un code d'état susceptible de signaler un problème. Si le test d'un port réussit, cela signifie que ce port est accessible, pas qu'une connexion à l'application ou qu'une requête de base de données aboutira.

Comment utiliser l'outil Ping ?

Sélectionne le Protocole Ping adapté, saisis l'adresse correspondante, puis lance le test. Utilise le type de saisie attendu par le protocole choisi.

1. Choisis HTTP(s) et saisis une URL complète, par exemple https://www.example.com/status, pour diagnostiquer un site web, un point de terminaison d'API ou un service web.
2. Choisis Ping (ICMP) et saisis un hôte, par exemple server.example.com ou une adresse IP, pour vérifier si un serveur répond au trafic ICMP.
3. Choisis Hôte / Port, saisis l'hôte, puis indique le port sous forme numérique. Par exemple, un service d'envoi SMTP utilise couramment le port 587, tandis que HTTPS utilise généralement le port 443.

N'ajoute pas de chemin d'URL lors d'un test portant uniquement sur un hôte. À l'inverse, un contrôle HTTP peut nécessiter le chemin complet si le problème touche une route d'API ou une page précise plutôt que l'ensemble du domaine. Les numéros de port de transport sont des valeurs sur 16 bits comprises entre 0 et 65535. Le port 0 est réservé et n'est normalement pas utilisé comme port de service. Les espaces, les virgules et les indications telles que "port 443" ne font pas partie d'un numéro de port.

Le test Ping s'exécute sur le serveur. Les données saisies dans Ping sont transmises à ce serveur via HTTPS et ne sont pas stockées. Évite d'inclure des mots de passe, des clés d'API ou d'autres informations confidentielles dans une URL, car ils pourraient être exposés au service distant et à d'autres composants de l'infrastructure web habituelle.

Comment interpréter le résultat du ping ?

Commence par vérifier la disponibilité, puis examine le temps de réponse, l'état HTTP ou l'erreur pour mieux cerner le problème.

Par exemple, un résultat HTTP fictif pourrait afficher En ligne, un temps de réponse de 180 ms et le code d'état 200. Le code 200 indique que la requête a réussi. Une réponse 404 signifie que le serveur d'origine n'a trouvé aucune représentation actuelle de la ressource ciblée, ou qu'il refuse de révéler qu'une telle représentation existe. Une réponse 5xx (erreur serveur) appartient à la catégorie des erreurs serveur. Sa cause exacte dépend du code d'état concerné.

Un résultat Hors ligne ne signifie pas toujours que toute la machine est hors ligne. Un pare-feu peut bloquer ICMP alors que HTTPS continue de fonctionner, ou un port peut être fermé tandis que d'autres services restent disponibles. Lance le test correspondant au service auquel les utilisateurs tentent d'accéder.

Problèmes courants détectés par un ping

Si un site web ne se charge pas, commence par tester son URL exacte avec HTTP(s). Si le domaine répond, mais qu'une page renvoie une erreur 404, vérifie la route, les règles de réécriture ou le déploiement. Si le navigateur affiche un avertissement de certificat avec HTTPS, utilise la Recherche SSL pour obtenir les détails du certificat au lieu de te fier uniquement au ping. La Recherche des en-têtes HTTP peut également afficher les redirections et les en-têtes de réponse.

Si les e-mails n'arrivent pas, utilise Hôte / Port avec le nom d'hôte du serveur de messagerie et le port configuré dans l'application d'envoi ou de réception. Le fait qu'un port SMTP soit accessible ne prouve pas que le serveur acceptera un message donné. Les échecs d'authentification, le filtrage antispam, les enregistrements DNS de messagerie et les règles appliquées aux destinataires dépassent le cadre d'un simple test de port.

Après avoir déplacé un site vers un nouvel hébergeur, teste son nom d'hôte avec ICMP ou HTTP, selon le cas. Vérifie l'enregistrement DNS et tiens compte des réponses conservées en cache. La Recherche Whois peut aider à confirmer les informations d'enregistrement du domaine, mais elle n'indique pas la réponse DNS actuellement détenue par chaque résolveur.

Pourquoi le cache DNS peut-il donner l'impression qu'un résultat correct est faux ?

À cause du cache DNS, le serveur de l'outil et ton propre appareil peuvent temporairement résoudre le même nom d'hôte vers des adresses différentes. Les résolveurs récursifs conservent les réponses DNS pendant leur durée de vie, souvent appelée TTL. Certaines applications et certains systèmes d'exploitation utilisent également des caches locaux.

Le terme "propagation" est couramment employé pour désigner ce délai, même si les enregistrements DNS ne se diffusent pas partout selon un processus coordonné. Chaque cache expire selon son propre calendrier. Un enregistrement récemment modifié peut donc fonctionner sur une connexion, tandis qu'une autre utilise encore l'ancienne adresse.

Comme cet outil exécute le test sur son serveur, le résultat reflète le chemin réseau et la vue DNS de ce serveur au moment du contrôle. Il ne peut pas prouver que tous les fournisseurs d'accès britanniques, réseaux mobiles ou résolveurs d'entreprise voient la même destination. Si le comportement varie selon l'emplacement, compare ce résultat avec un test local et interroge les enregistrements DNS concernés.

Questions fréquentes

Que se passe-t-il avec les noms de domaine accentués ou non latins ?

IDNA convertit les libellés de domaine Unicode compatibles en libellés ASCII appelés A-labels. Punycode est l'algorithme d'encodage utilisé dans les A-labels concernés. Les navigateurs convertissent souvent automatiquement la forme lisible, mais les champs d'hôte et les systèmes de diagnostic peuvent exiger la forme A-label. Vérifie soigneusement l'orthographe, car des caractères Unicode visuellement similaires peuvent renvoyer vers des domaines différents.

Un temps de réponse faible restera-t-il toujours faible ?

Non. Le temps de réponse varie selon le routage, la congestion du réseau, la charge du serveur et la distance physique. Effectue plusieurs tests à des moments comparables et examine les changements durables, plutôt que de considérer une seule réponse lente comme la preuve d'un dysfonctionnement.

Avant de modifier les paramètres DNS, du pare-feu ou du serveur, vérifie que tu as testé le nom d'hôte, le chemin d'URL et le port exacts utilisés par le service concerné. Note l'heure du résultat et compare-la aux journaux locaux afin de faire correspondre les deux côtés de la connexion.