Comment résoudre l’erreur “L’adresse IP du serveur est introuvable”

L’erreur "Impossible de trouver l’adresse IP du serveur" signifie que votre navigateur a soumis une requête DNS pour un nom de domaine et n’a reçu aucune adresse IP valide en réponse — aucune connexion TCP n’a donc jamais été tentée. La cause principale est presque toujours une défaillance quelque part dans la chaîne de résolution DNS : un cache local obsolète, un résolveur mal configuré, un délai de propagation après une modification d’enregistrement DNS, ou une véritable panne côté serveur.

Ce guide couvre chaque couche de cette chaîne — du cache DNS propre au navigateur jusqu’au résolveur récursif de votre FAI et au serveur de noms faisant autorité — avec des commandes précises, des détails au niveau du registre, et les cas particuliers que les tutoriels génériques omettent.

Ce qui se passe réellement lors de la résolution DNS

Avant de résoudre les problèmes, comprendre le chemin de résolution évite les efforts inutiles. Lorsque vous saisissez une URL dans un navigateur, la séquence de recherche suivante s’exécute dans l’ordre :

1. Cache DNS du navigateur — Chrome, Firefox et Edge maintiennent chacun leur propre cache DNS en mémoire, distinct du système d’exploitation.
2. Cache du résolveur du système d’exploitation — Le service Windows DNS Client ou macOS mDNSResponder vérifie son cache local.
3. Fichier hosts — Un fichier de substitution statique qui a la priorité sur toute résolution basée sur le réseau.
4. Résolveur DNS configuré — Généralement votre routeur (agissant comme redirecteur) ou un résolveur public directement configuré comme `8.8.8.8`.
5. Résolveur récursif du FAI — Le résolveur de votre FAI interroge la hiérarchie DNS mondiale s’il n’a pas de réponse en cache.
6. Serveur de noms faisant autorité — La source de vérité finale pour les enregistrements A/AAAA du domaine.

Une défaillance à l’une de ces étapes produit la même erreur générique dans le navigateur. Savoir quelle couche est défaillante détermine quelle correction appliquer en premier.

Étape 1 : Vérifier l’URL et tester la portée

Cette étape semble triviale mais élimine immédiatement deux des causes les plus courantes.

• Vérifiez les fautes de frappe dans la barre d’adresse, y compris les TLD incorrects (`.co` vs `.com`, `.net` vs `.org`).
• Testez un second domaine que vous savez actif (par ex., `google.com`). Si celui-ci échoue également, le problème est à l’échelle du réseau sur votre machine, et non spécifique au domaine.
• Testez depuis un appareil mobile en données cellulaires (pas en Wi-Fi). Si le site se charge, le problème est local à votre réseau ou à votre machine.
• Effectuez une recherche DNS rapide depuis la ligne de commande pour contourner entièrement le navigateur :

“`bash

Windows / macOS / Linux

nslookup example.com

“`

Si `nslookup` renvoie une adresse IP mais que le navigateur affiche toujours une erreur, le problème est spécifique au navigateur. Si `nslookup` échoue également, le problème se situe au niveau du résolveur du système d’exploitation ou plus profondément.

Étape 2 : Vider le cache DNS interne du navigateur

Chaque navigateur majeur met en cache les enregistrements DNS indépendamment du système d’exploitation. Vider uniquement le cache du système d’exploitation en ignorant le cache du navigateur est une erreur courante.

Google Chrome et Edge (basés sur Chromium) :

Accédez à l’URL interne suivante dans la barre d’adresse :

“`

chrome://net-internals/#dns

“`

Cliquez sur "Clear host cache". Puis accédez à :

“`

chrome://net-internals/#sockets

“`

Cliquez sur "Flush socket pools" pour également effacer toutes les connexions TCP obsolètes liées aux anciennes adresses IP.

Firefox :

Firefox n’expose pas d’interface directe pour vider le DNS. La méthode la plus fiable est :

1. Ouvrez `about:config` dans la barre d’adresse.
2. Recherchez `network.dnsCacheExpiration`.
3. Définissez temporairement la valeur sur `0`, rechargez la page, puis restaurez-la à `60` (la valeur par défaut).

Alternativement, redémarrer Firefox avec tous les onglets fermés vide complètement son cache DNS.

Vider les cookies et les fichiers en cache du navigateur peut également aider lorsqu’une boucle de redirection ou une réponse obsolète est impliquée :

• Chrome : Menu > Plus d’outils > Effacer les données de navigation > sélectionnez Images et fichiers en cache et Cookies et autres données des sites > Effacer les données.

Étape 3 : Vider le cache DNS du système d’exploitation

Le cache du résolveur DNS au niveau du système d’exploitation stocke les enregistrements jusqu’à l’expiration de leur TTL. Si un domaine a récemment modifié ses enregistrements DNS (par ex., une migration de serveur ou un changement d’IP), votre machine peut conserver l’ancien enregistrement désormais invalide bien au-delà de son TTL en raison d’un bug du résolveur ou d’un TTL d’origine très élevé.

Windows (toutes versions) :

Ouvrez l’invite de commandes en tant qu’administrateur et exécutez :

“`cmd

ipconfig /flushdns

“`

Résultat attendu : `Successfully flushed the DNS Resolver Cache.`

Pour une réinitialisation plus complète, videz également le cache NetBIOS :

“`cmd

nbtstat -R

“`

macOS (commandes spécifiques à la version) :

Linux (systemd-resolved) :

“`bash

sudo systemd-resolve –flush-caches

sudo systemd-resolve –statistics # Verify cache was cleared

“`

Si vous utilisez `nscd` à la place :

“`bash

sudo service nscd restart

“`

Étape 4 : Redémarrer votre routeur et renouveler votre bail IP

Votre routeur domestique agit généralement comme un redirecteur DNS — il reçoit vos requêtes DNS et les transmet au résolveur de votre FAI. Un routeur avec une table ARP corrompue ou un bail DHCP obsolète peut provoquer des échecs DNS identiques aux problèmes côté serveur.

Procédure de redémarrage du routeur :

1. Éteignez le routeur et débranchez-le de la source d’alimentation.
2. Attendez 30 secondes complètes (les condensateurs doivent se décharger pour un vrai redémarrage à froid).
3. Rallumez-le et attendez que tous les voyants se stabilisent avant de tester.

Renouvelez votre adresse IP après le redémarrage du routeur :

*Windows :*

“`cmd

ipconfig /release

ipconfig /renew

“`

*macOS :*

Accédez à Réglages Système > Réseau > sélectionnez votre interface active > Détails > TCP/IP > Renouveler le bail DHCP.

*Linux :*

“`bash

sudo dhclient -r && sudo dhclient

“`

Cas particulier : Si vous êtes sur un réseau d’entreprise ou universitaire avec des réservations DHCP, le renouvellement du bail peut ne pas changer votre IP mais actualisera les affectations de serveurs DNS transmises par l’option DHCP 6. Cela seul peut résoudre le problème si votre équipe informatique a récemment modifié ses adresses de serveurs DNS internes.

Étape 5 : Passer à un résolveur DNS public fiable

Le résolveur récursif de votre FAI est souvent le maillon le plus faible. Les résolveurs des FAI peuvent souffrir d’empoisonnement de cache, de détournement NXDOMAIN (redirection des recherches échouées vers des pages publicitaires), ou de simples pannes. Passer à un résolveur public bien maintenu est souvent la correction la plus rapide.

Comparaison des résolveurs DNS

Comment changer le DNS sous Windows :

1. Ouvrez le Panneau de configuration > Centre Réseau et partage > Modifier les paramètres de la carte.
2. Faites un clic droit sur votre adaptateur réseau actif > Propriétés.
3. Sélectionnez Protocole Internet version 4 (TCP/IPv4) > Propriétés.
4. Sélectionnez Utiliser les adresses de serveur DNS suivantes et saisissez le résolveur choisi.
5. Répétez pour Protocole Internet version 6 (TCP/IPv6) en utilisant les adresses IPv6 du résolveur choisi (par ex., Cloudflare IPv6 : `2606:4700:4700::1111` et `2606:4700:4700::1001`).
6. Cliquez sur OK et exécutez à nouveau `ipconfig /flushdns` pour effacer toutes les entrées en cache de l’ancien résolveur.

Comment changer le DNS sous macOS :

1. Réglages Système > Réseau > sélectionnez votre interface > Détails > DNS.
2. Cliquez sur le bouton + et ajoutez vos adresses DNS préférées.
3. Supprimez les anciennes entrées assignées par le FAI.
4. Cliquez sur OK > Appliquer.

Nuance importante : Modifier le DNS au niveau du système d’exploitation n’affecte pas les applications qui utilisent leur propre résolution DNS intégrée (par ex., certains clients VPN, certains navigateurs avec DNS-over-HTTPS activé). Vérifiez séparément les paramètres DNS de votre navigateur.

Étape 6 : Inspecter et corriger le fichier hosts

Le fichier hosts est une substitution DNS statique locale qui a une priorité absolue sur toute résolution basée sur le réseau. Une seule entrée malformée ou malveillante peut silencieusement bloquer un domaine entier. Les malwares ciblent fréquemment ce fichier pour rediriger ou bloquer des domaines spécifiques.

Emplacement du fichier hosts sous Windows :

“`

C:WindowsSystem32driversetchosts

“`

Ouvrez-le avec le Bloc-notes exécuté en tant qu’administrateur. Un fichier hosts légitime ne devrait contenir que :

“`

127.0.0.1 localhost

::1 localhost

“`

Toute entrée supplémentaire pointant un domaine vers `0.0.0.0`, `127.0.0.1`, ou toute adresse IP inattendue doit être examinée et supprimée si non autorisée.

Fichier hosts sous macOS / Linux :

“`bash

sudo nano /etc/hosts

“`

Recherchez les lignes qui ne sont pas des commentaires (lignes commençant par `#`) et qui référencent le domaine que vous essayez d’atteindre. Supprimez-les, enregistrez le fichier (`Ctrl+X`, puis `Y` dans nano), et videz le cache DNS comme décrit à l’étape 3.

Conseil pro : Après avoir modifié le fichier hosts sous Windows, vous devez vider le cache DNS avec `ipconfig /flushdns` pour que la modification prenne effet immédiatement sans redémarrage.

Étape 7 : Désactiver les conflits VPN, proxy et DNS-over-HTTPS

Les clients VPN et les configurations proxy sont parmi les causes les plus négligées des échecs de résolution DNS, particulièrement dans les environnements d’entreprise.

Fuites et échecs DNS liés au VPN :

Lorsqu’un VPN est actif, il installe généralement un adaptateur réseau virtuel et redirige toutes les requêtes DNS à travers le tunnel VPN vers le résolveur interne du fournisseur. Si la connexion VPN se coupe mais que l’adaptateur virtuel reste actif, les requêtes DNS sont envoyées dans un tunnel mort et expirent. Désactivez entièrement le client VPN (pas seulement la déconnexion) et testez.

Désactiver le proxy sous Windows :

Paramètres > Réseau et Internet > Proxy > désactivez Utiliser un serveur proxy et Détecter automatiquement les paramètres (ce dernier peut provoquer des délais via la découverte WPAD).

Conflits DNS-over-HTTPS (DoH) :

Chrome, Firefox et Edge peuvent être configurés pour utiliser un fournisseur DoH spécifique, contournant entièrement le résolveur du système d’exploitation. Si ce fournisseur DoH est inaccessible ou mal configuré, la résolution DNS échoue silencieusement.

• Chrome : Paramètres > Confidentialité et sécurité > Sécurité > Utiliser le DNS sécurisé — vérifiez le fournisseur configuré ou passez à "Avec votre fournisseur de service actuel".
• Firefox : Paramètres > Général > faites défiler jusqu’à Paramètres réseau > Paramètres > vérifiez l’option Activer le DNS via HTTPS et le fournisseur configuré.

Étape 8 : Mettre à jour ou réinstaller les pilotes de l’adaptateur réseau

Des pilotes d’adaptateur réseau corrompus ou obsolètes peuvent provoquer des échecs DNS intermittents, des pertes de paquets et des coupures de connexion qui se manifestent sous forme d’erreurs DNS.

Windows :

1. Appuyez sur `Win + X` > Gestionnaire de périphériques.
2. Développez Cartes réseau.
3. Faites un clic droit sur votre adaptateur actif > Mettre à jour le pilote > Rechercher automatiquement des pilotes.
4. Si Windows ne trouve pas de mise à jour, visitez le site Web du fabricant de l’adaptateur (Intel, Realtek, Broadcom) et téléchargez directement le dernier pilote.
5. Pour une réinstallation complète : faites un clic droit sur l’adaptateur > Désinstaller le périphérique > cochez Supprimer le logiciel pilote de ce périphérique > redémarrez. Windows réinstallera un pilote propre au redémarrage.

Réinitialisation avancée de la pile réseau Windows (à utiliser lorsque les mises à jour de pilotes n’aident pas) :

“`cmd

netsh winsock reset

netsh int ip reset

ipconfig /flushdns

ipconfig /registerdns

“`

Redémarrez après avoir exécuté les quatre commandes. Cela réinitialise le catalogue Winsock et la pile TCP/IP à leurs valeurs par défaut, résolvant les problèmes causés par des malwares, des désinstallations de logiciels VPN échouées, ou des entrées de pile corrompues.

Étape 9 : Diagnostiquer les problèmes côté serveur et de propagation DNS

Si toutes les étapes côté client échouent, le problème peut être externe — soit les enregistrements DNS du domaine ne se résolvent pas globalement, soit le serveur lui-même est inaccessible.

Vérifiez si le domaine se résout depuis des points d’observation externes :

Utilisez ces outils pour interroger le domaine depuis plusieurs emplacements mondiaux simultanément :

• dnschecker.org — Affiche la propagation des enregistrements A sur plus de 100 serveurs de noms mondiaux.
• whatsmydns.net — Vérifie la propagation DNS pour les enregistrements A, CNAME, MX et autres types d’enregistrements.
• downforeveryoneorjustme.com — Confirme si le site est globalement inaccessible ou uniquement inaccessible depuis votre emplacement.

Délais de propagation DNS :

Si un domaine a récemment eu son enregistrement A, ses serveurs de noms ou son hébergement modifiés, la propagation peut prendre de quelques minutes à 48 heures selon la valeur TTL définie sur l’ancien enregistrement. Pendant cette période, certains résolveurs dans le monde retourneront l’ancienne adresse IP (désormais invalide) tandis que d’autres retourneront la nouvelle. Il s’agit d’un problème côté serveur/administration DNS, et non d’un problème côté client.

Si vous gérez vous-même le domaine et avez récemment migré votre site vers un nouveau serveur — par exemple, en passant à un environnement Hébergement VPS — vérifiez que l’enregistrement A dans votre zone DNS pointe vers l’adresse IP du nouveau serveur et que l’ancien TTL a complètement expiré.

Vérifiez directement le serveur de noms faisant autorité :

“`bash

Query the authoritative nameserver directly, bypassing all caches

nslookup example.com ns1.yourdnshost.com

“`

Si le serveur de noms faisant autorité renvoie la bonne IP mais que votre résolveur local ne le fait pas, le problème est la propagation du cache. Si le serveur de noms faisant autorité lui-même ne renvoie aucun enregistrement ou un enregistrement incorrect, la configuration de la zone DNS doit être corrigée.

Étape 10 : Contacter votre FAI ou votre hébergeur

Si le domaine se résout correctement depuis des points d’observation externes mais pas depuis votre réseau, le résolveur de votre FAI peut filtrer, bloquer ou renvoyer des résultats incorrects pour ce domaine. C’est plus courant que la plupart des utilisateurs ne le réalisent — certains FAI implémentent un blocage au niveau DNS pour la conformité réglementaire, et ces blocages touchent parfois des domaines légitimes.

Testez en utilisant temporairement un résolveur différent (comme décrit à l’étape 5). Si le domaine se résout correctement avec `8.8.8.8` mais pas avec le résolveur de votre FAI, contactez votre FAI et signalez le domaine spécifique comme incorrectement bloqué ou mis en cache.

Si vous êtes le propriétaire du site et que vos utilisateurs signalent cette erreur, le problème peut provenir de votre configuration d’hébergement. Vérifiez :

• L’enregistrement A de votre domaine pointe vers la bonne IP du serveur.
• Vos Certificats SSL sont valides et ne provoquent pas de boucles de redirection empêchant la connexion initiale.
• Vos serveurs de noms sont correctement définis chez votre fournisseur d’Enregistrement de domaine.
• Votre serveur fonctionne réellement et le service web (Apache, Nginx) est actif.

Pour les sites à fort trafic ou critiques, envisagez de passer à un Serveur dédié pour éliminer les problèmes de ressources partagées pouvant provoquer des défaillances DNS ou de connectivité intermittentes.

Comparaison : Causes côté client vs côté serveur

Matrice de décision pratique et points clés

Suivez cette liste de contrôle dans l’ordre pour minimiser le temps de diagnostic :

• Confirmez d’abord la portée. L’erreur affecte-t-elle un domaine, un navigateur, un appareil ou l’ensemble du réseau ? Cette seule question élimine 80 % des étapes non pertinentes.
• Exécutez `nslookup` avant de modifier tout paramètre. Si l’IP est résolue, la correction est au niveau du navigateur. Si cela échoue, la correction est au niveau du système d’exploitation ou plus profondément.
• Videz dans le bon ordre : cache DNS du navigateur en premier, puis cache DNS du système d’exploitation, puis redémarrage du routeur. Faire l’inverse fait perdre du temps.
• Videz toujours le cache DNS du système d’exploitation après avoir modifié les paramètres du serveur DNS. Le nouveau résolveur ne sera pas interrogé pour les domaines déjà mis en cache sous l’ancien résolveur tant que le cache n’est pas vidé.
• Vérifiez le fichier hosts si le domaine fonctionnait récemment et s’est soudainement arrêté. C’est un indicateur fort de malware ou d’un outil de sécurité mal configuré.
• Utilisez `netsh winsock reset` sous Windows uniquement en dernier recours — cela réinitialise toutes les entrées Winsock, y compris les entrées légitimes ajoutées par des logiciels comme les clients VPN, qui pourraient nécessiter une réinstallation par la suite.
• Si vous êtes propriétaire d’un site, vérifiez vos enregistrements de zone DNS immédiatement après toute migration de serveur. Si vous exploitez votre site sur un VPS avec cPanel, l’éditeur de zone DNS WHM fournit un accès direct à tous les enregistrements. Si vous êtes sur un Hébergement Web mutualisé, utilisez la section de gestion DNS du panneau de contrôle d’hébergement pour confirmer que l’enregistrement A est à jour.
• Pour les échecs DNS liés aux e-mails (enregistrements MX non résolus), vérifiez séparément la configuration des serveurs de noms de votre fournisseur d’Hébergement e-mail — les enregistrements MX sont indépendants des enregistrements A et peuvent échouer indépendamment.

FAQ

Pourquoi l’erreur "Impossible de trouver l’adresse IP du serveur" apparaît-elle uniquement dans Chrome mais pas dans Firefox ?

Chrome et Firefox maintiennent des caches DNS internes séparés et peuvent être configurés pour utiliser différents fournisseurs DNS-over-HTTPS. Si Chrome a une entrée de cache obsolète ou corrompue, ou si son fournisseur DoH est inaccessible, il échouera tandis que Firefox réussira en utilisant le résolveur du système d’exploitation. Accédez à `chrome://net-internals/#dns` et cliquez sur "Clear host cache" pour résoudre ce problème.

Combien de temps prend la propagation DNS après la modification de l’enregistrement A d’un domaine ?

Le temps de propagation dépend de la valeur TTL (Time To Live) définie sur l’enregistrement avant la modification. Si l’ancien TTL était de 3600 secondes (1 heure), la plupart des résolveurs mettront en cache l’ancien enregistrement pendant jusqu’à une heure. Si le TTL était de 86400 secondes (24 heures), la propagation peut prendre jusqu’à 48 heures dans des cas extrêmes. Réduire le TTL à 300 secondes plusieurs heures avant une migration planifiée réduit considérablement le temps de propagation.

Un pare-feu ou un antivirus peut-il provoquer cette erreur DNS ?

Oui. Les logiciels de sécurité incluant un filtrage DNS (Windows Defender, Malwarebytes, Kaspersky, etc.) peuvent intercepter et bloquer les requêtes DNS pour des domaines signalés comme malveillants. Si l’erreur est apparue immédiatement après l’installation ou la mise à jour d’un logiciel de sécurité, désactivez temporairement le composant de protection DNS (pas l’antivirus entier) et testez. Vérifiez également si le logiciel a ajouté des entrées dans votre fichier hosts.

Quelle est la différence entre `ipconfig /flushdns` et `netsh winsock reset` ?

`ipconfig /flushdns` vide uniquement le cache du résolveur DNS Windows — il supprime les enregistrements DNS mis en cache afin que la prochaine requête soit envoyée au résolveur configuré de façon fraîche. `netsh winsock reset` réinitialise l’intégralité du catalogue de l’API Windows Sockets à son état par défaut, corrigeant une corruption plus profonde dans la pile réseau elle-même. La réinitialisation Winsock nécessite un redémarrage et ne doit être utilisée que lorsque le vidage DNS et les mises à jour de pilotes n’ont pas résolu le problème.

Si le domaine se résout correctement via `nslookup` mais que le navigateur affiche toujours l’erreur, que dois-je vérifier ?

Ce scénario pointe généralement vers l’une de ces trois causes : le cache DNS interne du navigateur contient toujours un enregistrement obsolète (videz-le via `chrome://net-internals/#dns`), le pool de sockets du navigateur a une connexion obsolète (videz-le via `chrome://net-internals/#sockets`), ou une extension de navigateur (notamment les extensions proxy ou VPN) intercepte et fait échouer la requête DNS. Désactivez toutes les extensions et testez dans une fenêtre privée/incognito pour isoler les interférences des extensions.