J'utilise OS X 10.8.5 et Chrome 30.
J'ai ajouté 127.0.0.1 youtube.com
à mon fichier /etc/hosts
de telle sorte qu'il contienne maintenant ceci:
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
127.0.0.1 youtube.com
Lorsque j'exécute la commande traceroute youtube.com
, je reçois les résultats attendus (YouTube.com est résolu en 127.0.0.1):
traceroute to youtube.com (127.0.0.1), 64 Hops max, 52 byte packets
1 localhost (127.0.0.1) 0.272 ms 0.118 ms 0.063 ms
Toutefois, lorsque je tape youtube.com dans Chrome, mon navigateur n'établit pas de connexion avec 127.0.0.1 mais avec l'adresse IP "normale" de YouTube. Je m'attendrais à ce que Chrome résolve youtube.com en 127.0.0.1.
J'ai configuré Chrome pour utiliser les paramètres de proxy de mon système. Sous OS X, lorsque je vais dans Préférences Système> Réseau> "Avancé ..."> Proxy, j'ai sélectionné "Détection automatique du proxy".
Pourquoi Chrome ignore-t-il apparemment mon fichier /etc/hosts
?
Essayez d’ajouter www.youtube.com
à votre fichier hosts. youtube.com
est redirigé en permanence vers www.youtube.com
. Aussi longtemps que vous avez visité youtube.com
une fois, votre navigateur met cette réponse en cache et vous redirige vers www.youtube.com
. Cette adresse ne figure pas dans votre fichier hosts. Par conséquent, chrome le résout logiquement correctement.
Google Chrome ignore votre fichier hosts et effectue des recherches DNS réelles (malgré ce que d’autres pensent, /etc/hosts
ne fait pas partie du DNS, c’est ce qui était utilisé avant pour DNS). Bien que Google Chrome devrait respecter ces entrées de fichier d'hôtes, il ne le fait pas. Le fichier hosts, étant une alternative au DNS, sera lu si aucun serveur DNS n'est disponible (comme si vous avez désactivé votre connexion réseau).
Vous pouvez tester cela en ajoutant "127.0.0.1 foobar.dev" à votre fichier hosts, puis en activant Wireshark et en surveillant votre interface réseau. Ouvrez Chrome et mettez http://foobar.dev/
dans votre barre d’adresse et c'est parti. Vous verrez une requête DNS dans Wireshark, quelque chose comme:
2 1.668727000 192.168.32.104 8.8.8.8 DNS 75 Standard query 0x663a A foobar.dev
FWIW, Google DNS renvoie 127.0.53.53 pour foobar.dev.
3 1.706484000 8.8.8.8 192.168.32.104 DNS 91 Standard query response 0x663a A 127.0.53.53
Une solution de contournement consisterait à utiliser HostAdmin , une extension plus ancienne de Chrome permettant à Chrome d'utiliser les hôtes. Cependant, les versions plus récentes de Chrome (> 38, apparemment) ne le prennent plus en charge.
J'ai résolu le problème en: désactivez l'option "Protégez vous et votre appareil des sites dangereux" dans les préférences avancées de Chrome.
La "protection" intégrée de Chrome inclut la vérification directe d'un domaine par rapport à son propre DNS et le contournement de certains types d'entrées d'hôte qu'il juge "suspectes" ou d'entrées de sites existants qui sont remplacés, ce qui signifie que la plupart des entrées d'hôte personnalisées sont ignorées. Surtout les entrées * .dev et * .local utilisées pour le développement.
Désactiver cette option a résolu le problème 100% du temps pour moi. Cela me rendait fou pendant des mois lorsque je travaillais au développement local et je ne trouvais pas la réponse indiquée nulle part, tout le monde n'arrêtait pas de dire que cela ne pouvait pas se produire. Il s'avère que c'était une simple bascule dans les paramètres avancés. J'espère que cela vous aide aussi, applaudissements.
Localhost est une convention pour l'adresse 127.0.0.1 qui est une adresse interne pour tcp/ip. Cependant, Chrome n'utilise pas le fichier/etc/hosts pour résoudre l'adresse, il utilise un serveur DNS. Par conséquent, aucune adresse ne provient de votre/etc/hosts, mais à partir d’un serveur DNS, s’il utilisait le fichier/etc/hosts, il devra contenir l’ensemble des noms d’hôte www pour résoudre toute adresse.
J'espère que cela t'aides.