Utiliser des sous-domaines sur localhost en développement local

**Le moyen le plus rapide d’utiliser des sous-domaines sur localhost : utilisez tout simplement *.localhost.** Les navigateurs modernes résolvent tout app.localhost, api.localhost ou tenant1.localhost vers 127.0.0.1 automatiquement, sans aucune configuration. Quand vous avez besoin d’un domaine personnalisé, du HTTPS ou d’un routage vers différents ports, mappez des sous-domaines fixes dans le fichier hosts, ou utilisez dnsmasq pour les wildcards. Voici les trois approches et quand choisir chacune.

Option 1 — Sous-domaines *.localhost gratuits (sans config)

Selon le RFC 6761, localhost et tout ce qui en dépend est réservé au bouclage. Chrome, Edge et Firefox résolvent tout nom *.localhost vers 127.0.0.1 sans édition hosts ni config DNS :

http://app.localhost:3000
http://api.localhost:3000
http://tenant-acme.localhost:3000

Idéal pour les applis multi-tenant ou routées par sous-domaine : votre serveur lit l’en-tête Host et sert le bon tenant, tandis que chaque sous-domaine pointe vers le même serveur local. Aucun droit admin, rien à nettoyer ensuite. Pour comprendre le nom sous-jacent, voir qu’est-ce que localhost ?.

Limites :

• Cela résout toujours vers 127.0.0.1 — impossible de pointer un sous-domaine vers une autre IP ainsi.
• Certains outils/runtimes anciens n’honorent pas *.localhost ; si un client hors navigateur échoue, repliez sur l’Option 2.

Option 2 — Sous-domaines fixes via le fichier hosts

Quand vous voulez un TLD personnalisé (ex. .test) ou que le nom doit résoudre hors navigateur, listez chaque sous-domaine dans le fichier hosts :

127.0.0.1 monprojet.test
127.0.0.1 app.monprojet.test
127.0.0.1 api.monprojet.test
127.0.0.1 admin.monprojet.test

Vous pouvez aussi grouper des noms sur une ligne : 127.0.0.1 app.monprojet.test api.monprojet.test. Le fichier hosts ne reconnaît que les noms exacts — pas de motif — donc ajoutez une ligne par sous-domaine. Voir comment modifier le fichier hosts et le guide de syntaxe du fichier hosts. Préférez .test à .local (qui entre en conflit avec mDNS/Bonjour) : quel TLD utiliser pour le développement local.

Après édition, videz le DNS pour que les nouveaux noms résolvent tout de suite (ex. ipconfig /flushdns sous Windows, ou l’équivalent macOS/Linux).

Option 3 — Sous-domaines wildcard avec dnsmasq

Si les sous-domaines sont dynamiques ou trop nombreux à lister (tenant-1, tenant-2… ou générés par PR), le fichier hosts est le mauvais outil. Utilisez dnsmasq pour résoudre un domaine et tous ses sous-domaines avec une seule règle :

# macOS (Homebrew)
brew install dnsmasq
echo 'address=/monapp.test/127.0.0.1' >> $(brew --prefix)/etc/dnsmasq.conf
sudo brew services start dnsmasq
sudo mkdir -p /etc/resolver
echo 'nameserver 127.0.0.1' | sudo tee /etc/resolver/test

Désormais nimporte.monapp.test résout vers 127.0.0.1 sans toucher au fichier hosts. Étapes Linux complètes et vérification : domaines locaux wildcard avec dnsmasq.

Quelle approche choisir ?

• Beaucoup de sous-domaines sur 127.0.0.1, dans le navigateur ? *.localhost (Option 1).
• Quelques sous-domaines fixes, TLD personnalisé, ou clients hors navigateur ? Fichier hosts (Option 2).
• **Sous-domaines dynamiques/illimités, ou HTTPS pour *.monapp.test ?** dnsmasq (Option 3), avec un certificat mkcert wildcard.

Router les sous-domaines vers différents ports

Le DNS mappe un nom vers une IP, pas vers un port. Pour servir app.monprojet.test et api.monprojet.test depuis des backends différents sur une seule machine, placez un reverse proxy (Caddy, nginx, Traefik) devant, sur le port 80/443, qui route selon l’en-tête Host vers le port de chaque appli. Tous les sous-domaines résolvent vers 127.0.0.1 ; le proxy fait le reste.

Pièges fréquents

• Le sous-domaine refuse la connexion : le nom a résolu mais le serveur n’écoute pas ou n’accepte pas cet hôte. Vérifiez le port et les hôtes autorisés du serveur de dev — voir localhost n’autorise pas la connexion.
• Avertissement HTTPS sur un sous-domaine : le certificat doit le couvrir ; générez mkcert monprojet.test "*.monprojet.test".
• Ancienne IP après changements : videz le DNS et le cache hôte du navigateur.

Pour les mappings fixes du quotidien, Locahl gère les entrées hosts avec des bascules sûres par projet et un flush DNS automatique, pour des sous-domaines bien rangés ; vous ne sortez dnsmasq que pour de vrais wildcards.

_Dernier test : juin 2026 sur Windows 11, macOS 26 Tahoe et Ubuntu 24.04._

Sources et ressources externes

• RFC 6761 — Special-Use Domain Names (IETF)
• Documentation dnsmasq
• Le fichier hosts expliqué (Wikipédia)