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?
macos
networking
google-chrome
dns
Jonathan
fuente
fuente
Respuestas:
Intente agregar
www.youtube.coma su archivo de hosts.youtube.comse redirige permanentemente awww.youtube.com, por lo tanto, siempre que haya visitadoyoutube.comuna vez, su navegador almacena en caché esta respuesta y lo redirige awww.youtube.com. Esta dirección no está en su archivo de hosts, por lo que Chrome la resuelve lógicamente correctamente.fuente
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?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:FWIW, Google DNS devuelve 127.0.53.53 para foobar.dev.
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.
fuente
/etc/hostsarchivo en OS X. Al menos no Chrome v43 en OS X 10.10.3.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.
fuente
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.
fuente
/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./etc/hostsdeberí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.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.fuente