Pourquoi Chrome ignore-t-il / etc / hosts sur OS X?

27

J'utilise OS X 10.8.5 et Chrome 30.

J'ai ajouté 127.0.0.1 youtube.comà mon /etc/hostsfichier de 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.comje 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

Cependant, 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'attendais à 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é ..."> Proxys, j'ai sélectionné "Découverte de proxy automatique".

Pourquoi Chrome semble-t-il ignorer mon /etc/hostsfichier?

— Jonathan
source

4

Êtes-vous certain qu'il essaie de résoudre youtube.com et non www.youtube.com? Il se peut également que youtube.com ait une redirection 301 qui est mise en cache par le navigateur afin qu'il n'essaye même pas de contacter youtube.com (pas sur mon ordinateur pour vérifier).

— user2313067

@ user2313067 Merci! J'ai révisé / etc / hosts pour avoir également une ligne pour www.youtube.com résolvant à 127.0.0.1 et cela a fait l'affaire.

— Jonathan

@ user2313067 Vous voudrez peut-être publier votre commentaire comme réponse.

— Blacklight Shining

2

Duplication possible de Pourquoi le chrome contourne-t-il / etc / hosts et dnsmasq?

— Scott

vous utilisez probablement un VPN ou une extension chrome qui MODIFIE votre connexion d'une manière ou d'une autre

— user1735921

8

Essayez d'ajouter www.youtube.comà votre fichier d'hôtes. youtube.comest redirigé en permanence vers www.youtube.com, donc tant que vous avez visité youtube.comune fois, votre navigateur met en cache cette réponse et vous redirige vers www.youtube.com. Cette adresse ne se trouve pas dans votre fichier hosts, donc Chrome la résout logiquement correctement.

— user2313067
source

1

Faites cela pour effacer vos redirections superuser.com/questions/304589/… ou utilisez simplement le mode

— navigation privée

1

L'ajout wwwne fonctionne pas pour moi. Même après avoir effacé toutes les données de mon navigateur et vidé mon DNS. Peut-être s'agit-il d'une mesure anti-phishing intégrée à Chrome?

— f1lt3r

en ajoutant à la fois nu et www. les versions du fichier hosts fonctionnaient pour moi. J'ai également désactivé chrome: // flags / # enable-new-preconnect dans Chrome

— LyK

10

Google Chrome ignore votre fichier d'hôtes et effectue des recherches DNS réelles (malgré ce que les autres pensent, /etc/hostsne fait pas partie du DNS, c'est ce qui était utilisé avant DNS). Bien que Google Chrome devrait honorer ces entrées de fichier d'hôtes, ce n'est pas le cas. Le fichier hosts, étant une alternative au DNS, sera lu quand aucun serveur DNS n'est disponible (comme si vous avez désactivé votre connexion réseau).

Vous pouvez le tester en ajoutant "127.0.0.1 foobar.dev" à votre fichier d'hôtes, puis en activant Wireshark et en regardant sur votre interface réseau. Ouvrez Chrome et mettez http://foobar.dev/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 ancienne extension Chrome qui fait que Chrome utilise les hôtes. Cependant, les versions plus récentes de Chrome (> 38, notablement) ne le prennent plus en charge.

— Karl Wilbur
source

Chrome /etc/hostsn'ignore en fait aucun fichier sous OS X. Du moins, pas Chrome v43 sous OS X 10.10.3.

— Petr Peller

Wireshark raconte une histoire différente.

— Karl Wilbur

1

Le fait que Chrome interroge également le DNS de Google ne signifie pas nécessairement que / etc / hosts est ignoré. Cela peut être simplement à des fins d'optimisation / de journalisation / d'espionnage. J'utilise le fichier / etc / hosts très souvent sur OS X et je n'ai aucun problème avec Chrome.

— Petr Peller

3

Lorsque mon fichier hôte contient '127.0.0.1 foo.dev' et que Chrome résout magiquement foo.dev en 127.0.53.53, il IGNORE mon fichier d'hôtes.

— Karl Wilbur

1

Oui, mais avec wifi sur, Chrome devrait utiliser le fichier hosts d' abord avant de faire une recherche DNS. Ce ne est pas. C'est le problème.

— Karl Wilbur

6

J'ai résolu ce problème en: désactivant "Protégez-vous et votre appareil contre les sites dangereux" dans les préférences avancées de Chrome.

La "protection" intégrée de Chrome comprend 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 pour des sites existants qui sont remplacés, ce qui signifie que la plupart des entrées d'hôte personnalisées sont ignorées. En particulier 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 faisais du développement local et je n'ai trouvé la réponse nulle part, tout le monde n'arrêtait pas de dire que cela ne pouvait pas arriver. Il s'avère que c'était une simple bascule dans les paramètres avancés. J'espère que cela vous aidera aussi, bravo.

— Joshua Jarman
source

Merci, je savais que cela fonctionnait la semaine dernière, j'ai changé les options de chrome par défaut il y a quelques jours et cela ne fonctionnait plus. Ça a marché!

— 98percentmonkey

Merci, je savais que cela fonctionnait la semaine dernière, j'ai changé les options de chrome par défaut il y a quelques jours et cela ne fonctionnait plus. Ça a marché! Cela s'appelle "Navigation sécurisée" dans les versions les plus récentes

— 98percentmonkey

0

Localhost est une convention pour l'adresse 127.0.0.1 qui est une adresse interne pour TCP / IP, cependant, Chrome n'utilise pas / etc / hosts pour résoudre l'adresse, il utilise un serveur DNS, donc aucune adresse ne vient de votre / etc / hosts, mais à partir d'un serveur DNS, s'il utilisait / etc / hosts, il devra contenir l'intégralité des noms d'hôte www pour résoudre n'importe quelle adresse.

J'espère que cela t'aides.

— Moises Najar
source

1

-1. /etc/hostsremplace tous les serveurs DNS. Oui, si vous utilisez uniquement /etc/hosts , il devrait contenir tous les noms de domaine, mais la plupart des configurations incluent également des serveurs DNS. Si Chrome demande simplement au système d'exploitation de résoudre le nom de domaine, comme il se doit , /etc/hostssera vérifié en premier, et s'il ne contient pas d'entrée, une requête DNS sera envoyée.

— Blacklight Shining

/etc/hosts devrait remplacer et demande DNS, mais ce n'est pas le cas avec Google Chrome. Il préforme ses propres recherches DNS malgré ce qui peut se trouver dans le fichier hosts. Ceci est facilement démontrable. Il s'agit spécifiquement d'un problème de développement local à l'aide du .devTLD.

— Karl Wilbur

0

Je suis tombé sur cette question en pensant que le hostsfichier ne fonctionnait pas sur Chrome pour macOS pour les .devfaux domaines que j'utilise pour le développement.

En fait , il fait le travail, au moins sur Chrome 77.

Le problème n'est pas que le domaine est introuvable, mais que tous les .dev sont désormais automatiquement redirigés vers https :

Si vous double-cliquez sur le nom de domaine, vous pouvez voir le coupable:

Maintenant que Google a rompu notre .devsolution, le lien ci-dessus suggère de passer à un autre TLD pour le développement, comme .testou .localhost.

— Benjamin
source