Fichier hosts : où il se trouve et comment le modifier (Windows, macOS, Linux)

Le fichier hosts est un petit fichier texte présent sur tous les systèmes d’exploitation : il associe un nom de machine à une adresse IP, et il est consulté avant les serveurs DNS. C’est ce qui permet de faire pointer www.monsite.fr vers une machine de test sans toucher à la zone DNS publique — l’usage le plus courant avant une migration. Sous Windows, il se trouve dans C:\Windows\System32\drivers\etc\hosts, sous macOS et Linux dans /etc/hosts.

À quoi sert le fichier hosts ?

Un ordinateur ne sait pas joindre « demarcq.net » : il sait joindre une adresse IP. Avant d’envoyer la moindre requête, il lui faut donc traduire un nom en adresse. Pour cela, il interroge plusieurs sources, dans un ordre précis :

1. son cache DNS local (une réponse récente qu’il garde en mémoire) ;
2. le fichier hosts ;
3. les serveurs DNS configurés (box, fournisseur d’accès, résolveur public).

Le fichier hosts passe donc avant le DNS. Toute correspondance qu’on y écrit s’impose à tout le système, pour toutes les applications : navigateur, client de messagerie, terminal, script de sauvegarde. C’est un interrupteur local, propre à une machine, invisible depuis l’extérieur — et c’est exactement ce qui le rend utile pour tester.

Son format est d’une simplicité désarmante : une adresse IP, un ou plusieurs espaces ou tabulations, un ou plusieurs noms d’hôte, puis éventuellement un commentaire précédé d’un #.

# adresse IP        nom d'hôte
87.98.190.151       www.demarcq.net demarcq.net
127.0.0.1           localhost
::1                 localhost ip6-localhost

Où se trouve le fichier hosts ?

Système	Emplacement	Droits nécessaires
Windows 10 / 11	C:\Windows\System32\drivers\etc\hosts	Administrateur
Windows Server	C:\Windows\System32\drivers\etc\hosts	Administrateur
macOS (toutes versions)	/etc/hosts	sudo
Linux (Debian, Ubuntu, RHEL, Alpine…)	/etc/hosts	sudo
Android / iOS	non modifiable sans root ou jailbreak	—

Le fichier n’a pas d’extension : il s’appelle hosts, tout court. C’est la première cause d’échec quand on croit l’avoir modifié — l’éditeur a enregistré hosts.txt, et le système continue de lire l’original.

Modifier le fichier hosts sous Windows

1. Ouvrez le Bloc-notes en tant qu’administrateur : menu Démarrer, clic droit sur « Bloc-notes », « Exécuter en tant qu’administrateur ». Sans ce niveau de droits, l’enregistrement sera refusé.
2. Dans le Bloc-notes, Fichier → Ouvrir, puis naviguez jusqu’à C:\Windows\System32\drivers\etc. La boîte de dialogue masque les fichiers sans extension : choisissez « Tous les fichiers (*.*) » pour voir hosts.
3. Ajoutez votre ligne à la fin du fichier : adresse IP, espace, nom d’hôte. Exemple : 87.98.190.151 www.monsite.fr.
4. Enregistrez (Ctrl+S). Si Windows refuse, c’est que le Bloc-notes n’a pas été lancé en administrateur — ou que l’antivirus protège le fichier (certains le verrouillent, à juste titre).
5. Videz le cache DNS : ouvrez une invite de commandes et lancez ipconfig /flushdns. Sans cette étape, votre navigateur peut continuer à utiliser l’ancienne réponse.

Deux pièges classiques sous Windows : l’encodage (enregistrez en ANSI ou en UTF-8 sans BOM ; un BOM en début de fichier casse la première ligne) et la protection en lecture seule héritée d’un ancien nettoyage. Vérifiez les propriétés du fichier si l’enregistrement échoue malgré les droits administrateur.

Modifier le fichier hosts sous macOS et Linux

Un terminal et les droits d’administration suffisent. Sur macOS comme sur Linux :

sudo nano /etc/hosts

Ajoutez la ligne, puis Ctrl+O pour enregistrer et Ctrl+X pour quitter. Avec vim, i pour éditer, Échap puis :wq pour enregistrer. Ne modifiez pas les permissions du fichier (chmod) : ce n’est pas nécessaire, et c’est une mauvaise habitude à prendre sur un serveur — l’éditeur élevé par sudo suffit.

Videz ensuite le cache DNS, qui diffère d’un système à l’autre :

# macOS (Mojave et suivants)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux avec systemd-resolved
sudo resolvectl flush-caches

# Linux sans systemd-resolved : redémarrer le service de résolution
sudo systemctl restart nscd

Les usages concrets du fichier hosts

1. Tester un site sur un nouveau serveur avant la migration

C’est l’usage professionnel, et de loin le plus fréquent. Le site en production reste servi normalement ; seules les machines qui ont la ligne dans leur fichier hosts voient la nouvelle version. Vous validez le rendu, les formulaires, les certificats et les performances avant de basculer le DNS pour tout le monde. Si quelque chose ne va pas, vous effacez une ligne : la production n’a jamais bougé.

Condition à ne pas oublier : le nouveau serveur doit répondre au nom d’hôte demandé (bon VirtualHost, certificat valide pour ce nom, ou exception acceptée le temps du test). Un fichier hosts correct avec un serveur mal configuré donne une erreur 403 ou un avertissement de certificat — ce n’est pas le fichier hosts qui est en cause.

2. Bloquer un domaine sur une machine

0.0.0.0      exemple-de-site-a-bloquer.com
0.0.0.0      www.exemple-de-site-a-bloquer.com

L’adresse 0.0.0.0 (ou 127.0.0.1) renvoie la machine vers elle-même : la connexion échoue immédiatement. C’est la méthode utilisée par les listes de blocage publicitaires. Elle ne protège qu’une machine à la fois, et seulement tant que l’utilisateur n’a pas les droits d’administration.

3. Épingler une adresse pour un accès stable

Sur un poste d’administration, fixer l’adresse d’un serveur dans le fichier hosts évite de dépendre d’un DNS interne défaillant le jour où il faut intervenir. C’est un dépannage, pas une architecture : un serveur ne doit pas dépendre d’un fichier hosts pour être joignable.

4. Faire cohabiter plusieurs environnements

Sur une machine de développement, on associe souvent un nom de recette à l’adresse d’une VM ou d’un conteneur : 192.168.1.40 recette.monsite.local. Aucun DNS à maintenir, aucun certificat public à demander.

Le fichier hosts et la sécurité : ce qu’il faut savoir

Parce qu’il passe avant le DNS et qu’il est consulté par tous les programmes, le fichier hosts est une cible classique des logiciels malveillants. Une ligne ajoutée à votre insu peut rediriger votre banque, votre messagerie ou un site de mise à jour vers un serveur pirate — sans que l’adresse affichée dans le navigateur change.

Les signes qui doivent alerter :

• un site connu qui affiche un certificat invalide ou une page différente ;
• des résolutions DNS qui « ne prennent pas » malgré une zone correcte ;
• un fichier hosts anormalement long, avec des dizaines de domaines inconnus ;
• un fichier hosts en lecture seule alors que personne ne l’a verrouillé.

Le réflexe est simple : ouvrez le fichier, lisez-le. Un fichier hosts sain contient quelques lignes — localhost, éventuellement une entrée IPv6, et vos entrées de test. Tout le reste est à examiner. Sauvegardez-le avant nettoyage, puis videz le cache DNS.

À l’inverse, les « optimiseurs » qui proposent de remplacer votre fichier hosts par une liste de plusieurs milliers de domaines publicitaires sont à manier avec prudence : ces listes ralentissent la résolution, cassent parfois des services légitimes, et personne ne les met à jour pour vous.

Les erreurs qui font perdre une heure

• Le fichier a été enregistré en hosts.txt : le système lit toujours l’ancien fichier.
• Le cache DNS n’a pas été vidé : la modification semble sans effet.
• Le BOM UTF-8 en tête de fichier invalide la première ligne.
• Les jokers ne fonctionnent pas : *.monsite.fr n’a aucun effet ; il faut écrire chaque nom.
• Les ports ne se mettent pas dans le fichier hosts : on y associe un nom à une IP, pas à un service (www.monsite.fr:8080 est invalide).
• Le nom testé n’est pas celui de l’URL : monsite.fr et www.monsite.fr sont deux entrées distinctes.
• Redirection HTTP → HTTPS vers un autre nom, ou certificat émis pour un autre domaine : la page s’affiche quand même sur le mauvais serveur, ou pas du tout.
• IPv6 prioritaire : si vous épinglez une adresse IPv4 mais que le domaine publie une AAAA, le système peut préférer l’IPv6. Ajoutez l’entrée IPv6 ou testez avec curl -4.

Fichier hosts ou DNS : lequel modifier ?

Le fichier hosts est local : il ne concerne qu’une machine, ne se propage pas, et ne demande aucune autorisation. Le DNS est public : il concerne tous les visiteurs, se propage selon le TTL, et engage la disponibilité du site.

• Tester avant une migration → fichier hosts, sur les postes qui doivent voir la nouvelle version.
• Basculer le site pour tout le monde → zone DNS, après validation. Voir migrer son site web sans coupure et le suivi de propagation DNS.
• Contourner un DNS interne cassé, ponctuellement → fichier hosts, le temps du dépannage.
• Faire pointer un domaine vers un serveur de façon durable → DNS. Le fichier hosts n’est jamais une solution d’architecture.

Questions fréquentes

Où se trouve le fichier hosts sous Windows 11 ?

Dans C:\Windows\System32\drivers\etc\hosts. Il faut l’ouvrir avec un éditeur lancé en administrateur pour pouvoir l’enregistrer, et choisir « Tous les fichiers » dans la boîte de dialogue, car il n’a pas d’extension.

Faut-il redémarrer après avoir modifié le fichier hosts ?

Non. En revanche, il faut vider le cache DNS : ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder sous macOS, sudo resolvectl flush-caches sous Linux. Le navigateur peut aussi garder sa propre connexion en cache : fermez-le ou testez en navigation privée.

Le fichier hosts peut-il bloquer un site pour tout un réseau ?

Seulement si vous centralisez la résolution sur un serveur DNS qui distribue une zone modifiée. Modifier un fichier hosts sur un poste ne protège que ce poste.

Peut-on mettre un port dans le fichier hosts ?

Non. Le fichier hosts associe un nom à une adresse IP, pas à un port ni à un protocole. Pour tester un service sur un port précis, utilisez l’adresse complète dans le navigateur ou un tunnel.

Pourquoi ma modification est-elle ignorée ?

Trois causes, dans cet ordre : fichier enregistré ailleurs (souvent hosts.txt), cache DNS non vidé, ou nom d’hôte différent de celui réellement demandé (avec ou sans www). Sur un système géré, une stratégie d’entreprise ou un antivirus peut aussi réécrire le fichier.

Modifier le fichier hosts est-il dangereux ?

Non, à condition de savoir revenir en arrière : c’est un fichier texte, local et réversible. Les risques viennent des modifications faites à votre insu, pas des vôtres. Gardez une copie du fichier d’origine avant de le nettoyer.

Préparer une migration proprement

Le fichier hosts permet de valider un nouveau serveur sans risque. Il ne remplace pas une méthode de bascule : TTL abaissé à l’avance, contenu synchronisé, base répliquée ou exportée, certificats en place, plan de retour arrière écrit. C’est exactement le travail que nous faisons lors des migrations que nous accompagnons.

Décrire votre migration

Pour aller plus loin : migrer son site web vers un nouveau serveur sans coupure, vérifier une délégation et une propagation DNS, l’infogérance de serveur et l’hébergement haute disponibilité.