Vider le cache DNS Chrome sur Mac

Chrome peut garder une ancienne résolution DNS même après un flush DNS macOS. Pour vider le cache DNS Chrome sur Mac, ouvrez :

chrome://net-internals/#dns

Cliquez ensuite sur "Clear host cache". Si le domaine pointe encore vers l'ancienne IP, videz aussi les sockets Chrome et le cache DNS macOS.

Correction rapide

Procédez dans cet ordre :

• Ouvrez chrome://net-internals/#dns.
• Cliquez sur "Clear host cache".
• Ouvrez chrome://net-internals/#sockets.
• Cliquez sur "Close idle sockets" puis "Flush socket pools".
• Lancez la commande macOS :

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Rechargez ensuite le site dans un nouvel onglet.

Pourquoi Chrome a son propre cache

macOS maintient un cache DNS système, mais Chrome optimise aussi les connexions réseau. Il peut donc conserver :

• Une résolution DNS interne.
• Une connexion ouverte vers l'ancien serveur.
• Un état de navigation dans un onglet déjà chargé.

C'est pour cela qu'un domaine local peut rester bloqué dans Chrome alors qu'il fonctionne dans Safari ou avec ping.

Après modification du fichier hosts

Après avoir changé /etc/hosts :

• Sauvegardez le fichier.
• Videz le DNS macOS.
• Videz le cache DNS Chrome.
• Videz les sockets Chrome.
• Testez dans un nouvel onglet ou une fenêtre privée.

Pour le diagnostic complet, lisez fichier hosts ne fonctionne pas sur Mac.

Vérifier que Chrome est bien responsable

Dans le Terminal :

dscacheutil -q host -a name monprojet.test
ping monprojet.test
curl -I http://monprojet.test

Si ces commandes affichent la bonne IP mais Chrome reste bloqué, le problème vient probablement de Chrome. Si elles affichent aussi l'ancienne IP, corrigez d'abord le cache système avec le guide flush DNS Mac.

Erreurs fréquentes

Réutiliser un ancien onglet

Ouvrez un nouvel onglet après le nettoyage. Les anciens onglets peuvent garder un état réseau.

Oublier les sockets

Le cache DNS et les sockets ne sont pas la même chose. Si Chrome garde une connexion ouverte, vider les sockets peut débloquer la situation.

Utiliser .local

.local peut interagir avec Bonjour. Pour le développement local, préférez .test.

Oublier IPv6

Ajoutez parfois ::1 en plus de 127.0.0.1 :

127.0.0.1 monprojet.test
::1       monprojet.test

Diagnostic par symptôme

Chrome affiche ERR_NAME_NOT_RESOLVED

Chrome ne résout pas le domaine. Vérifiez d'abord macOS :

dscacheutil -q host -a name monprojet.test
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Si macOS ne retourne pas la bonne IP, corrigez le fichier hosts avant de continuer côté Chrome.

Chrome affiche ERR_CONNECTION_REFUSED

Le domaine est résolu, mais aucun serveur ne répond :

lsof -i :3000
curl -I http://127.0.0.1:3000
curl -I http://monprojet.test:3000

Si l'IP directe fonctionne mais pas le domaine, c'est un problème DNS/hosts. Si les deux échouent, redémarrez le serveur local.

Chrome affiche une erreur de certificat

Le cache DNS n'est peut-être pas en cause. Vérifiez que le certificat mkcert couvre le domaine exact :

mkcert monprojet.test "*.monprojet.test"

Puis redémarrez complètement Chrome.

Workflow développeur

Après chaque changement de domaine local :

1. Sauvegardez le fichier hosts ou le profil Locahl. 2. Videz le DNS macOS. 3. Videz le cache hôte Chrome. 4. Videz les socket pools Chrome. 5. Ouvrez un nouvel onglet. 6. Vérifiez avec curl -I.

Cette séquence évite les redémarrages aléatoires et indique quelle couche pose problème.

Checklist si le problème revient souvent

Si Chrome garde souvent de mauvaises résolutions DNS, standardisez vos projets :

• Utilisez .test plutôt que .local.
• Évitez de réutiliser le même domaine pour plusieurs projets.
• Ajoutez IPv4 et IPv6 dans le fichier hosts.
• Gardez un port stable par projet.
• Rangez les certificats HTTPS dans un dossier certs/.
• Documentez l'URL locale dans le README.

Exemple :

URL app : https://app.monprojet.test
URL API : https://api.monprojet.test
Port frontend : 3000
Port API : 4000
Reset DNS : flushdns + cache hôte Chrome

Workflow équipe

En équipe, partagez la même convention de domaines locaux. Si une personne utilise localhost:3000, une autre monprojet.local, et une troisième app.test, les cookies, CORS et callbacks OAuth deviennent difficiles à diagnostiquer.

Avec Locahl, vous pouvez exporter/importer les profils hosts et activer les mêmes mappings sur chaque poste. Ajoutez aussi une note de dépannage :

• Vider le DNS macOS après activation du profil.
• Vider Chrome si l'ancienne app s'ouvre.
• Régénérer mkcert si HTTPS affiche une alerte.
• Redémarrer le serveur dev après changement de hostname.

Quand le flush Chrome ne suffit pas

Si Chrome reste bloqué après "Clear host cache", le problème peut venir d'une autre couche :

• Le fichier hosts contient une erreur de syntaxe.
• Le serveur local n'écoute pas sur le port attendu.
• Le domaine pointe vers IPv6 alors que le serveur écoute seulement en IPv4.
• Un proxy, VPN ou outil de sécurité intercepte la requête.
• Le certificat HTTPS ne couvre pas le hostname exact.

Testez avec une commande simple :

curl -Iv http://monprojet.test:3000

Pour HTTPS :

curl -Iv https://monprojet.test:3000

Si curl échoue aussi, Chrome n'est probablement pas la cause principale. Si curl réussit mais Chrome échoue, concentrez-vous sur le cache Chrome, les sockets, les extensions, le profil utilisateur ou une politique d'entreprise.

Bonnes pratiques pour les domaines locaux

Pour limiter les problèmes DNS dans Chrome :

• Réservez un domaine par projet.
• Utilisez des sous-domaines explicites : app., api., admin..
• Évitez de changer l'IP d'un même hostname plusieurs fois par jour.
• Nettoyez Chrome après chaque bascule staging/production.
• Gardez la même convention dans les variables d'environnement.

Exemple :

NEXT_PUBLIC_APP_URL=https://app.monprojet.test
API_URL=https://api.monprojet.test
COOKIE_DOMAIN=.monprojet.test

Cette cohérence aide aussi pour OAuth, CORS, cookies SameSite et HTTPS local.

Conclusion

Quand Chrome ignore une modification hosts sur Mac, traitez les deux couches : Chrome et macOS. Videz le cache hôte, les sockets, puis le cache DNS système. C'est la séquence la plus fiable pour les domaines locaux.