Comment modifier le fichier Hosts sous Linux : Guide technique complet

Le fichier `/etc/hosts` sous Linux est une table de correspondance statique qui associe des noms d’hôtes à des adresses IP, traitée par le système d’exploitation *avant* l’envoi de toute requête DNS. En ajoutant ou en modifiant des entrées dans ce fichier, vous pouvez remplacer la résolution DNS pour des domaines spécifiques sur une machine donnée — sans toucher à votre serveur DNS, votre routeur ou les paramètres de votre bureau d’enregistrement.

Ce mécanisme est contrôlé par le Name Service Switch (NSS), configuré dans `/etc/nsswitch.conf`. La ligne `hosts:` par défaut indique généralement `files dns`, ce qui signifie que le système consulte d’abord `/etc/hosts`, puis se rabat sur les résolveurs DNS définis dans `/etc/resolv.conf`. Comprendre cet ordre est essentiel : si un nom d’hôte existe dans `/etc/hosts`, la requête DNS ne quitte jamais la machine.

Ce qu’est le fichier Hosts et comment il fonctionne

Le fichier `/etc/hosts` est antérieur au système DNS moderne. À l’époque de l’ARPANET, un unique fichier `HOSTS.TXT` maintenu par le Stanford Research Institute était distribué à chaque machine connectée au réseau. Le fichier `/etc/hosts` d’aujourd’hui est le descendant direct de ce concept — une couche de substitution locale et faisant autorité que tout système d’exploitation conforme à POSIX continue d’honorer.

Chaque ligne non commentée du fichier suit cette syntaxe :

“`

IP_address canonical_hostname [alias1] [alias2] …

“`

• Les lignes commençant par `#` sont des commentaires et sont ignorées.
• Les espaces blancs (espaces ou tabulations) séparent les champs.
• Une seule adresse IP peut être associée à plusieurs noms d’hôtes sur la même ligne.
• Les entrées IPv4 et IPv6 coexistent dans le même fichier.

Un fichier `/etc/hosts` minimal par défaut sur une installation Linux fraîche ressemble à ceci :

“`

127.0.0.1 localhost

127.0.1.1 myhostname.local myhostname

::1 localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

“`

L’entrée `127.0.1.1` est spécifique à Debian/Ubuntu et associe le FQDN de la machine à une adresse de bouclage lorsqu’aucune IP statique n’est assignée. La supprimer peut casser des outils comme `sudo` qui dépendent de la résolution du nom d’hôte.

Pourquoi modifier le fichier Hosts

Les cas d’utilisation vont de la simple commodité pour les développeurs aux tâches d’infrastructure critiques pour la sécurité :

Environnements de développement local et de staging

Pointez un domaine de production (par ex., `myapp.com`) vers `127.0.0.1` ou une IP LAN pendant la construction ou les tests, sans modifier les enregistrements DNS en production. C’est le cas d’utilisation le plus courant pour les développeurs qui exécutent un environnement VPS Hosting localement ou sur un serveur distant.

Tests d’applications multi-serveurs

Lors de la migration d’un site vers un nouveau serveur, pointez le domaine vers l’IP du nouveau serveur uniquement sur votre machine locale. Vous pouvez vérifier que le nouvel environnement est entièrement fonctionnel avant de mettre à jour l’enregistrement DNS public — éliminant ainsi le risque de temps d’arrêt.

Blocage de domaines malveillants ou indésirables

Rediriger un domaine vers `0.0.0.0` (préférable à `127.0.0.1` pour le blocage) provoque l’échec immédiat de la connexion sans attendre un refus de connexion sur localhost. Des projets comme `StevenBlack/hosts` agrègent des millions de domaines publicitaires, de traceurs et de logiciels malveillants dans une seule liste de blocage au format hosts.

Réseau de conteneurs et de microservices

Dans les environnements Docker ou LXC sans résolveur DNS personnalisé, les entrées `/etc/hosts` à l’intérieur des conteneurs (ou sur l’hôte) fournissent une découverte de services légère. L’option `–add-host` de Docker injecte des entrées directement dans le fichier `/etc/hosts` d’un conteneur au moment de l’exécution.

Remplacement du DNS split-horizon

Dans les réseaux d’entreprise où les DNS internes et externes renvoient des enregistrements différents pour le même nom d’hôte, une entrée dans le fichier hosts vous donne un contrôle déterministe sur une machine spécifique.

Tests de validation de certificat SSL

Lors du test d’un déploiement de Certificats SSL sur un serveur de staging, pointer le domaine vers l’IP de staging dans `/etc/hosts` vous permet de vérifier la poignée de main TLS complète, la chaîne de certificats et le comportement de redirection HTTPS avant la mise en production.

Étape par étape : comment modifier le fichier Hosts sous Linux

Étape 1 : Ouvrir un terminal

Accédez à un émulateur de terminal. Sur les distributions de bureau, le raccourci `Ctrl + Alt + T` fonctionne sur GNOME, KDE et XFCE. Sur un serveur sans interface graphique, vous êtes déjà dans une session shell via SSH.

Confirmez votre utilisateur actuel et votre niveau de privilège :

“`bash

whoami

id

“`

Étape 2 : Sauvegarder le fichier Hosts actuel

Créez toujours une sauvegarde horodatée avant de modifier un fichier système. Un fichier générique `hosts.backup` peut être écrasé accidentellement ; un horodatage est sans ambiguïté :

“`bash

sudo cp /etc/hosts /etc/hosts.bak.$(date +%Y%m%d_%H%M%S)

“`

Vérifiez que la sauvegarde a été créée :

“`bash

ls -lh /etc/hosts*

“`

Étape 3 : Vérifier les permissions et la propriété du fichier

Avant de modifier, confirmez la propriété et les permissions actuelles du fichier :

“`bash

ls -la /etc/hosts

“`

Résultat attendu :

“`

-rw-r–r– 1 root root 221 Jan 10 09:00 /etc/hosts

“`

Le fichier doit appartenir à `root:root` avec les permissions `644`. Si les permissions diffèrent, examinez la situation avant de continuer — un fichier `/etc/hosts` accessible en écriture par tous est une vulnérabilité de sécurité.

Étape 4 : Ouvrir le fichier Hosts avec un éditeur de texte

Avec nano (recommandé pour la plupart des utilisateurs) :

“`bash

sudo nano /etc/hosts

“`

Avec vim :

“`bash

sudo vim /etc/hosts

“`

Avec gedit (interface graphique, bureau GNOME) :

“`bash

sudo gedit /etc/hosts

“`

Avec tee pour les ajouts non interactifs/scriptés (sans éditeur requis) :

“`bash

echo "192.168.1.50 staging.myapp.com" | sudo tee -a /etc/hosts

“`

L’option `-a` ajoute au fichier plutôt que de l’écraser. C’est la méthode la plus sûre pour les scripts d’automatisation et les playbooks Ansible.

Étape 5 : Ajouter, modifier ou supprimer des entrées

Naviguez jusqu’à la fin du fichier et ajoutez vos entrées. Respectez strictement ces règles de formatage :

• Une entrée par ligne.
• L’adresse IP en premier, puis un ou plusieurs noms d’hôtes séparés par des espaces blancs.
• Utilisez `#` en ligne pour annoter les entrées pour référence future.

Rediriger un domaine vers un serveur de développement local :

“`

127.0.0.1 myproject.local # Local dev – remove before production

“`

Pointer un domaine vers un serveur de staging distant :

“`

203.0.113.45 staging.myapp.com # Staging server – pre-DNS cutover

“`

Bloquer un domaine (méthode préférée avec 0.0.0.0) :

“`

0.0.0.0 ads.example.com

0.0.0.0 tracker.analytics-provider.com

“`

Ajouter une entrée IPv6 :

“`

::1 ipv6-service.local

“`

Associer plusieurs alias à une seule IP (utile pour les hôtes virtuels) :

“`

127.0.0.1 app.local api.local static.local

“`

Étape 6 : Enregistrer et quitter l’éditeur

Dans nano :

• Enregistrer : `Ctrl + O`, puis `Enter` pour confirmer le nom du fichier.
• Quitter : `Ctrl + X`.

Dans vim :

• Retourner en mode normal : `Esc`
• Enregistrer et quitter : `:wq` puis `Enter`
• Quitter sans enregistrer : `:q!` puis `Enter`

Étape 7 : Vérifier le contenu du fichier

Confirmez que vos entrées ont été correctement écrites :

“`bash

cat /etc/hosts

“`

Pour les fichiers hosts volumineux, utilisez `grep` pour trouver des entrées spécifiques :

“`bash

grep "myproject.local" /etc/hosts

“`

Vérifiez les erreurs de syntaxe — une entrée avec une IP manquante ou une adresse malformée sera silencieusement ignorée par le résolveur :

“`bash

sudo python3 -c "

with open('/etc/hosts') as f:

for i, line in enumerate(f, 1):

line = line.strip()

if line and not line.startswith('#'):

parts = line.split()

if len(parts) < 2:

print(f'Line {i} may be malformed: {line}')

"

“`

Étape 8 : Vider le cache DNS

Les modifications apportées à `/etc/hosts` prennent effet immédiatement pour les nouvelles connexions sur la plupart des systèmes. Cependant, si votre système exécute un démon de mise en cache DNS local, vous devez vider son cache pour voir les modifications.

systemd-resolved (Ubuntu 18.04+, la plupart des distributions modernes) :

“`bash

sudo systemd-resolve –flush-caches

sudo systemd-resolve –statistics # Verify cache was cleared

“`

nscd (Name Service Cache Daemon) :

“`bash

sudo systemctl restart nscd

“`

dnsmasq :

“`bash

sudo systemctl restart dnsmasq

“`

NetworkManager avec le plugin dnsmasq :

“`bash

sudo systemctl restart NetworkManager

“`

Les navigateurs maintiennent leur propre cache DNS indépendamment. Chrome et Firefox mettent en cache les enregistrements DNS jusqu’à 60 secondes. Pour vider le cache DNS interne de Chrome, naviguez vers `chrome://net-internals/#dns` et cliquez sur « Clear host cache ».

Étape 9 : Tester la résolution

Utilisez `getent` plutôt que `ping` pour un test plus fiable de la chaîne de résolution NSS :

“`bash

getent hosts myproject.local

“`

`getent` interroge directement le Name Service Switch du système, en respectant `/etc/nsswitch.conf`, et vous montrera exactement ce que le système d’exploitation résout — et non ce que renvoie un serveur DNS. C’est le test définitif.

De plus :

“`bash

ping -c 3 myproject.local

“`

“`bash

curl -v http://myproject.local

“`

Si `getent` renvoie la bonne IP mais que `ping` ne le fait pas, le problème se situe dans la pile réseau ou le pare-feu, et non dans le fichier hosts.

Fichier Hosts vs. DNS : quand utiliser lequel

Pour les équipes gérant plusieurs serveurs — comme une flotte de Serveurs Dédiés — la gestion DNS centralisée est toujours supérieure à la distribution manuelle des modifications du fichier hosts. Le fichier hosts est un outil par machine, pas un outil d’infrastructure.

Techniques avancées et cas particuliers

Utilisation du fichier Hosts avec les hôtes virtuels dans Apache et Nginx

Lors de l’exécution de plusieurs sites web sur un seul serveur avec l’hébergement virtuel, le fichier hosts sur votre *machine cliente* doit pointer le domaine vers l’IP du serveur. Le serveur web utilise ensuite l’en-tête HTTP `Host:` pour router la requête vers le bon hôte virtuel. L’entrée du fichier hosts et la configuration de l’hôte virtuel du serveur doivent utiliser le même nom d’hôte.

Par exemple, si vous avez un hôte virtuel Apache configuré pour `myapp.local` sur un VPS avec cPanel, ajoutez l’IP du serveur à votre fichier hosts local :

“`

198.51.100.10 myapp.local

“`

Accédez ensuite à `http://myapp.local` dans votre navigateur. Apache lit l’en-tête `Host: myapp.local` et sert le bon site.

Protection du fichier Hosts contre les modifications non autorisées

Les logiciels malveillants ciblent fréquemment `/etc/hosts` pour rediriger des domaines légitimes (par ex., des sites bancaires) vers des serveurs de phishing. Utilisez `chattr` pour rendre le fichier immuable :

“`bash

sudo chattr +i /etc/hosts

“`

Cela empêche toute modification, même par root, jusqu’à ce que l’attribut immuable soit explicitement supprimé :

“`bash

sudo chattr -i /etc/hosts # Remove immutability to edit

“`

Vérifiez l’attribut :

“`bash

lsattr /etc/hosts

“`

Gestion des versions de votre fichier Hosts

Pour les équipes ou les environnements de développement complexes, suivez les modifications de `/etc/hosts` avec Git :

“`bash

sudo cp /etc/hosts ~/dotfiles/hosts

cd ~/dotfiles && git add hosts && git commit -m "Add staging.myapp.com entry"

“`

Des outils comme etckeeper gèrent automatiquement les versions de l’ensemble du répertoire `/etc` en utilisant Git ou d’autres backends VCS, fournissant une piste d’audit complète des modifications des fichiers système.

Fichier Hosts dans Docker et Kubernetes

Dans Docker, vous pouvez injecter des entrées du fichier hosts au démarrage du conteneur sans modifier le système hôte :

“`bash

docker run –add-host=myservice.local:192.168.1.100 myimage

“`

Dans Kubernetes, `hostAliases` dans la spécification d’un Pod obtient le même résultat :

“`yaml

spec:

hostAliases:

• ip: "192.168.1.100"

hostnames:

• "myservice.local"

“`

Ces approches sont préférables à la modification du fichier `/etc/hosts` de l’hôte lorsqu’on travaille dans des environnements conteneurisés.

Le débat `0.0.0.0` vs. `127.0.0.1` pour le blocage

Les deux adresses sont utilisées pour bloquer des domaines, mais elles se comportent différemment :

• `127.0.0.1` : Route la connexion vers l’interface de bouclage local. Si rien n’écoute sur le port 80/443 localement, la connexion est refusée — mais le système d’exploitation tente quand même de l’établir, provoquant un bref délai.
• `0.0.0.0` : Représente une destination invalide sur la plupart des systèmes. La connexion échoue immédiatement sans tentative de poignée de main TCP, ce qui entraîne des chargements de page plus rapides lors du blocage d’un grand nombre de domaines publicitaires/traceurs.

Pour les cas d’utilisation de listes de blocage, `0.0.0.0` est le choix techniquement supérieur.

Erreurs courantes et dépannage

Les modifications ne prennent pas effet après l’édition :

• Confirmez que l’entrée est syntaxiquement correcte (IP en premier, puis nom d’hôte).
• Videz le cache DNS local (voir Étape 8).
• Vérifiez `/etc/nsswitch.conf` — si `dns` apparaît avant `files` dans la ligne `hosts:`, le DNS est interrogé en premier et le fichier hosts est contourné pour les entrées en cache.

Erreur `sudo: unable to resolve host` après l’édition :

• Vous avez probablement supprimé ou corrompu la ligne associant le nom d’hôte de votre machine à `127.0.1.1` ou `127.0.0.1`. Restaurez immédiatement la sauvegarde : `sudo cp /etc/hosts.bak.TIMESTAMP /etc/hosts`.

Entrée ignorée pour une application spécifique :

• Certaines applications (notamment celles utilisant `getaddrinfo` avec des configurations NSS personnalisées, ou celles avec des résolveurs liés statiquement) contournent entièrement `/etc/nsswitch.conf` et interrogent directement le DNS. C’est courant dans les binaires Go compilés avec CGO désactivé. Vérifiez avec `strace -e trace=network yourapp`.

Le fichier hosts fonctionne localement mais pas dans un conteneur Docker :

• La mise en réseau des conteneurs est isolée. Le conteneur possède son propre fichier `/etc/hosts`. Utilisez `–add-host` ou `hostAliases` comme décrit ci-dessus.

Points techniques clés : liste de contrôle décisionnelle

Avant de modifier `/etc/hosts`, parcourez cette liste de contrôle :

• Vérification de la portée : Cette modification est-elle nécessaire sur une seule machine ? Si plusieurs machines en ont besoin, utilisez DNS ou un outil comme Ansible pour distribuer la modification.
• Sauvegarde d’abord : Créez toujours une sauvegarde horodatée (`hosts.bak.YYYYMMDD_HHMMSS`) avant toute modification.
• Utilisez `0.0.0.0` pour le blocage : Échec plus rapide, sans surcharge de bouclage.
• Videz le bon cache : Identifiez si votre système utilise `systemd-resolved`, `nscd` ou `dnsmasq` avant de redémarrer le mauvais service.
• Testez avec `getent` : Plus fiable que `ping` pour confirmer la résolution NSS.
• Protégez le fichier : Utilisez `chattr +i` sur les systèmes de production ou sensibles à la sécurité.
• Documentez vos entrées : Ajoutez des commentaires en ligne (`# reason – added YYYY-MM-DD`) à chaque entrée non par défaut.
• Supprimez les entrées temporaires : Les entrées dev/test laissées dans les fichiers hosts de production sont une source courante de bugs de routage difficiles à diagnostiquer.

Si vous gérez un flux de travail de développement sur plusieurs environnements, envisagez d’associer la gestion locale du fichier hosts à une configuration Panneaux de contrôle VPS correctement configurée pour centraliser la gestion des hôtes virtuels et réduire la dérive de configuration par machine.

Pour les projets impliquant l’Enregistrement de domaines et des déploiements progressifs, le fichier hosts reste le moyen le plus fiable d’effectuer un test complet de bout en bout d’une nouvelle configuration de serveur avant la fin de la propagation DNS — vous offrant une fenêtre de validation sans risque avant que le public ne voie le moindre changement.

FAQ

La modification de `/etc/hosts` nécessite-t-elle un redémarrage du système ?

Non. Les modifications apportées à `/etc/hosts` prennent effet immédiatement pour les nouvelles connexions. Si vous disposez d’un démon de mise en cache DNS local (`systemd-resolved`, `nscd` ou `dnsmasq`), vous devez vider son cache. Les navigateurs maintiennent également des caches DNS indépendants qui peuvent nécessiter un vidage manuel.

Pourquoi mon entrée dans le fichier hosts fonctionne-t-elle dans le terminal mais pas dans mon navigateur ?

Les navigateurs mettent en cache les enregistrements DNS indépendamment du résolveur du système d’exploitation. Chrome met en cache les enregistrements jusqu’à 60 secondes. Naviguez vers `chrome://net-internals/#dns` et videz le cache des hôtes, ou attendez l’expiration du TTL.

Puis-je utiliser des caractères génériques dans `/etc/hosts` ?

Non. Le fichier `/etc/hosts` ne prend pas en charge les entrées avec caractères génériques. Chaque nom d’hôte doit être listé explicitement. Si vous avez besoin d’une résolution par caractères génériques (par ex., `*.local`), utilisez un résolveur DNS local comme `dnsmasq` ou `unbound`.

Quel est le nombre maximum d’entrées dans `/etc/hosts` ?

Il n’existe pas de limite codée en dur imposée par le noyau ou glibc. Cependant, les performances se dégradent avec des fichiers très volumineux car le fichier est analysé linéairement pour chaque recherche. Les fichiers contenant des dizaines de milliers d’entrées (courant avec les listes de blocage publicitaire) peuvent ajouter une latence mesurable à la résolution des noms d’hôtes. Pour les grandes listes de blocage, un sinkhole DNS dédié comme Pi-hole est plus efficace.

Est-il sûr de supprimer les entrées par défaut dans `/etc/hosts` ?

Non. Les entrées par défaut (`127.0.0.1 localhost`, `::1 localhost` et l’association du nom d’hôte de la machine) sont nécessaires au bon fonctionnement du système. Les supprimer peut casser `sudo`, les connexions de socket locales et les applications qui dépendent de la résolution de bouclage. Ajoutez ou modifiez uniquement des entrées ; ne supprimez jamais les valeurs par défaut sans une raison spécifique et bien comprise.