¿Por qué Chrome ignora / etc / hosts en OS X?

27

Estoy usando OS X 10.8.5 y Chrome 30.

Agregué 127.0.0.1 youtube.coma mi /etc/hostsarchivo de modo que ahora contiene esto:

# 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

Cuando ejecuto el comando traceroute youtube.com, recibo los resultados esperados (youtube.com se resuelve 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

Sin embargo, cuando escribo youtube.com en Chrome, mi navegador no establece una conexión con 127.0.0.1 sino con la dirección IP "normal" para YouTube. Hubiera esperado que Chrome resolviera youtube.com a 127.0.0.1.

Tengo Chrome configurado para usar la configuración de proxy de mi sistema. En OS X, cuando voy a Preferencias del sistema> Red> "Avanzado ..."> Proxies, he seleccionado "Auto Proxy Discovery".

¿Por qué Chrome aparentemente ignora mi /etc/hostsarchivo?

— Jonathan
fuente

44

¿Estás seguro de que está tratando de resolver youtube.com y no www.youtube.com? También podría ser que youtube.com tiene una redirección 301 que el navegador almacena en caché para que ni siquiera intente comunicarse con youtube.com (no en mi computadora para verificar).

— user2313067

@ user2313067 ¡Gracias! Revisé / etc / hosts para que también tuviera una línea para que www.youtube.com se resolviera a 127.0.0.1 y eso funcionó.

— Jonathan

@ user2313067 Es posible que desee publicar su comentario como respuesta.

— Blacklight Shining

2

Posible duplicado de ¿Por qué Chromium omite / etc / hosts y dnsmasq?

— Scott

probablemente esté utilizando una VPN o una extensión de Chrome que ALTERE su conexión de alguna manera

— user1735921

8

Intente agregar www.youtube.coma su archivo de hosts. youtube.comse redirige permanentemente a www.youtube.com, por lo tanto, siempre que haya visitado youtube.comuna vez, su navegador almacena en caché esta respuesta y lo redirige a www.youtube.com. Esta dirección no está en su archivo de hosts, por lo que Chrome la resuelve lógicamente correctamente.

— usuario2313067
fuente

1

Haga esto para borrar sus redirecciones superuser.com/questions/304589/… o simplemente use el modo de incógnito para el desarrollo

— james.c.funk

1

Agregar wwwno funciona para mí. Incluso después de borrar todos los datos de mi navegador y vaciar mi DNS. ¿Quizás esta es una medida antiphishing en Chrome?

— f1lt3r

agregando desnudos y www. Las versiones en el archivo hosts funcionaron para mí. También deshabilité chrome: // flags / # enable-new-preconnect en Chrome

— LyK

10

Google Chrome ignora su archivo de hosts y realiza búsquedas de DNS reales (a pesar de lo que otros puedan pensar, /etc/hostsno es parte de DNS, es lo que se utilizó antes de DNS). Si bien Google Chrome debería honrar esas entradas de archivos de hosts, no lo hace. El archivo de hosts, que es una alternativa al DNS, se leerá cuando no haya un servidor DNS disponible (como si deshabilitó su conexión de red).

Puede probar esto agregando "127.0.0.1 foobar.dev" a su archivo de hosts, luego habilitando wireshark y observando en su interfaz de red. Abre Chrome y pon http://foobar.dev/tu barra de direcciones y listo. Verá una consulta DNS en Wireshark, algo así como:

2   1.668727000 192.168.32.104  8.8.8.8 DNS 75  Standard query 0x663a  A foobar.dev

FWIW, Google DNS devuelve 127.0.53.53 para foobar.dev.

3   1.706484000 8.8.8.8 192.168.32.104  DNS 91  Standard query response 0x663a  A 127.0.53.53

Una solución alternativa sería usar HostAdmin, que es una extensión de Chrome más antigua que hace que Chrome use los hosts. Sin embargo, las versiones más nuevas de Chrome (> 38, aparentemente) ya no lo admiten.

— Karl Wilbur
fuente

Chrome en realidad no ignora el /etc/hostsarchivo en OS X. Al menos no Chrome v43 en OS X 10.10.3.

— Petr Peller

Wireshark cuenta una historia diferente.

— Karl Wilbur

1

El hecho de que Chrome también consulte el DNS de Google podría no significar / etc / hosts se ignora. Esto puede ser simplemente para fines de optimización / registro / espionaje. Utilizo el archivo / etc / hosts con mucha frecuencia en OS X y no tengo problemas con Chrome.

— Petr Peller

3

Cuando mi archivo de host tiene '127.0.0.1 foo.dev' y Chrome resuelve mágicamente foo.dev a 127.0.53.53, está IGNORANDO mi archivo de hosts.

— Karl Wilbur

1

Sí, pero con wifi, Chrome debe utilizar el archivo de hosts primero antes de hacer una búsqueda de DNS. No es asi. Ese es el problema.

— Karl Wilbur

6

Solucioné este problema: APAGUE "Protéjalo a usted y a su dispositivo de sitios peligrosos" en las Preferencias avanzadas de Chrome.

La "protección" incorporada de Chrome incluye verificar un dominio contra su propio DNS directamente y omitir ciertos tipos de entradas de host que considera "sospechosas" o entradas para sitios que existen que se anulan, lo que significa que se ignoran la mayoría de las entradas de host personalizadas. Especialmente las entradas * .dev y * .local utilizadas para el desarrollo.

Desactivar esto ha resuelto el problema el 100% del tiempo para mí. Esto me estaba volviendo loco durante meses cuando hacía desarrollo local y no pude encontrar la respuesta en ninguna parte, todos decían que no podía estar sucediendo. Resulta que fue un simple cambio en la configuración avanzada. Espero que esto también te ayude, saludos.

— Joshua Jarman
fuente

Gracias, sabía que funcionó la semana pasada, cambié las opciones de Chrome a las predeterminadas hace unos días y ya no funcionó. ¡Funcionó!

— 98percentmonkey

Gracias, sabía que funcionó la semana pasada, cambié las opciones de Chrome a las predeterminadas hace unos días y ya no funcionó. ¡Funcionó! Se llama "Navegación segura" en versiones más recientes

— 98percentmonkey

0

Localhost es una convención para la dirección 127.0.0.1 que es una dirección interna para tcp / ip, sin embargo, Chrome no está usando / etc / hosts para resolver la dirección, está usando un servidor DNS, por lo tanto, ninguna dirección proviene de su / etc / hosts, pero desde un servidor DNS, si usara / etc / hosts, tendrá que contener todos los nombres de host www para resolver cualquier dirección.

Espero que esto ayude.

— Moisés Najar
fuente

1

-1. /etc/hostsanula cualquier servidor DNS. Sí, si solo está usando /etc/hosts, debería contener todos los nombres de dominio, pero la mayoría de las configuraciones también incluyen servidores DNS. Si Chrome simplemente le pide al sistema operativo que resuelva el nombre de dominio, como debería , /etc/hostsse verificará primero, y si no contiene una entrada, se enviará una consulta DNS.

— Blacklight Shining

/etc/hosts debería anular la solicitud de DNS, pero este no es el caso con Google Chrome. Preforma sus propias búsquedas de DNS a pesar de lo que puede haber en el archivo de hosts. Esto es fácilmente demostrable. Este es específicamente un problema para el desarrollo local utilizando el .devTLD.

— Karl Wilbur

0

Me topé con esta pregunta al pensar que el hostsarchivo no funcionaba en Chrome para macOS para los .devdominios falsos que uso para el desarrollo.

En realidad se hace el trabajo, al menos en Chrome 77.

El problema no es que no se encuentre el dominio, sino que todos los .dev ahora se redirigen automáticamente a https :

Si hace doble clic en el nombre de dominio, puede ver al culpable:

Ahora que Google rompió nuestro .dev, como solución, el enlace anterior sugiere pasar a otro TLD para el desarrollo, como .testo .localhost.

— Benjamín
fuente