Perché Chrome ignora / etc / hosts su OS X?

27

Sto usando OS X 10.8.5 e Chrome 30.

Ho aggiunto 127.0.0.1 youtube.comal mio /etc/hostsfile in modo tale che ora contenga questo:

# 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

Quando eseguo il comando, traceroute youtube.comricevo i risultati previsti (youtube.com viene risolto in 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

Tuttavia, quando scrivo youtube.com in Chrome, il mio browser non stabilisce una connessione con 127.0.0.1 ma invece con l'indirizzo IP "normale" per YouTube. Mi sarei aspettato che Chrome risolvesse youtube.com a 127.0.0.1.

Chrome è configurato per utilizzare le impostazioni proxy del mio sistema. In OS X, quando vado in Preferenze di Sistema> Rete> "Avanzate ..."> Proxy, ho selezionato "Rilevamento automatico proxy".

Perché Chrome sembra ignorare il mio /etc/hostsfile?

— Jonathan
fonte

4

Sei sicuro che stia cercando di risolvere youtube.com e non www.youtube.com? Potrebbe anche essere che youtube.com abbia un reindirizzamento 301 che viene memorizzato nella cache dal browser in modo che non tenti nemmeno di contattare youtube.com (non sul mio computer per controllare).

— user2313067

@ user2313067 Grazie! Ho rivisto / etc / hosts per avere anche una riga per www.youtube.com che si risolve in 127.0.0.1 e che ha funzionato.

— Jonathan,

@ user2313067 Potresti voler pubblicare il tuo commento come risposta.

— Blacklight Shining,

2

Possibile duplicato di Perché il Chromium ignora / etc / hosts e dnsmasq?

— Scott,

probabilmente stai utilizzando una VPN o un'estensione Chrome che

— altera

8

Prova ad aggiungere www.youtube.comal tuo file hosts. youtube.comviene reindirizzato in modo permanente a www.youtube.com, quindi fintanto che hai visitato youtube.comuna volta, il browser memorizza nella cache questa risposta e ti reindirizza a www.youtube.com. Questo indirizzo non è nel tuo file hosts, quindi Chrome lo risolve logicamente in modo corretto.

— user2313067
fonte

1

Fai questo per cancellare i tuoi reindirizzamenti superuser.com/questions/304589/… o semplicemente usa la modalità di

— navigazione in

1

L'aggiunta wwwnon funziona per me. Anche dopo aver cancellato tutti i dati del mio browser e scaricato il mio DNS. Forse questa è una misura anti-phishing integrata in Chrome?

— f1lt3r,

aggiungendo sia nudo che www. le versioni nel file hosts hanno funzionato per me. Ho anche disabilitato chrome: // flags / # enable-new-preconnect in Chrome

— LyK

10

Google Chrome ignora il file hosts e esegue ricerche DNS effettive (nonostante ciò che gli altri potrebbero pensare, /etc/hostsnon fa parte del DNS, è ciò che è stato utilizzato prima del DNS). Mentre Google Chrome dovrebbe onorare le voci del file host, non è così. Il file hosts, in alternativa al DNS, verrà letto quando nessun server DNS è disponibile (come se hai disabilitato la connessione di rete).

È possibile verificarlo aggiungendo "127.0.0.1 foobar.dev" al file hosts, quindi abilitando WireShark e guardando sull'interfaccia di rete. Apri Chrome, inserisci http://foobar.dev/la barra degli indirizzi e vai. Vedrai una query DNS in Wireshark, qualcosa del tipo:

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

FWIW, Google DNS restituisce 127.0.53.53 per 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 soluzione alternativa consisterebbe nell'utilizzare HostAdmin che è un'estensione di Chrome precedente che fa sì che Chrome utilizzi gli host. Tuttavia, le versioni più recenti di Chrome (> 38, approssimativamente) non lo supportano più.

— Karl Wilbur
fonte

Chrome in realtà non ignora il /etc/hostsfile su OS X. Almeno non Chrome v43 su OS X 10.10.3.

— Petr Peller,

Wireshark racconta una storia diversa.

— Karl Wilbur,

1

Il fatto che Chrome interroghi anche il DNS di Google potrebbe non significare / etc / hosts viene ignorato. Questo può essere semplicemente per scopi di ottimizzazione / registrazione / spionaggio. Uso il file / etc / hosts molto spesso su OS X e non ho problemi con Chrome.

— Petr Peller,

3

Quando il mio file host ha "127.0.0.1 foo.dev" e Chrome risolve magicamente foo.dev a 127.0.53.53, ignora il mio file host.

— Karl Wilbur,

1

Sì, ma con wifi, Chrome dovrebbe utilizzare il file hosts prima prima di fare una ricerca DNS. Non è così. Quello è il problema.

— Karl Wilbur,

6

Ho risolto questo problema: Disattiva "Proteggi te e il tuo dispositivo da siti pericolosi" nelle Preferenze avanzate di Chrome.

La "protezione" integrata di Chrome include la verifica diretta di un dominio rispetto al proprio DNS e il bypass di determinati tipi di voci host che ritiene "sospette" o voci per siti esistenti che vengono sovrascritti, il che significa che la maggior parte delle voci host personalizzate vengono ignorate. Soprattutto le voci * .dev e * .local utilizzate per lo sviluppo.

La disattivazione ha risolto il problema il 100% delle volte per me. Questo mi faceva impazzire da mesi quando facevo lo sviluppo locale e non riuscivo a trovare la risposta elencata da nessuna parte, tutti continuavano a dire che non poteva accadere. Si scopre che è stato un semplice interruttore nelle impostazioni avanzate. Spero che questo ti aiuti anche, evviva.

— Joshua Jarman
fonte

Grazie, sapevo che ha funzionato la settimana scorsa, alcuni giorni fa ho cambiato le opzioni di Chrome e non ha più funzionato. Ha funzionato!

— 98percentmonkey

Grazie, sapevo che ha funzionato la settimana scorsa, alcuni giorni fa ho cambiato le opzioni di Chrome e non ha più funzionato. Ha funzionato! Si chiama "Navigazione sicura" nelle versioni più recenti

— 98percentmonkey

0

Localhost è una convenzione per l'indirizzo 127.0.0.1 che è un indirizzo interno per tcp / ip, tuttavia Chrome non utilizza / etc / hosts per risolvere l'indirizzo, utilizza un server DNS, pertanto qualsiasi indirizzo non proviene dal tuo / etc / hosts, ma da un server DNS, se utilizzava / etc / hosts, dovrà contenere tutti i nomi host www per risolvere qualsiasi indirizzo.

Spero che sia di aiuto.

— Moises Najar
fonte

1

-1. /etc/hostsignora qualsiasi server DNS. Sì, se si utilizza solo /etc/hosts , dovrebbe contenere tutti i nomi di dominio, ma la maggior parte delle configurazioni include anche i server DNS. Se Chrome chiede semplicemente al sistema operativo di risolvere il nome di dominio, come dovrebbe , /etc/hostsverrà prima verificato e, se non contiene una voce, verrà inviata una query DNS.

— Blacklight Shining,

/etc/hosts dovrebbe sostituire e richiedere DNS, ma non è così per Google Chrome. Preforma le proprie ricerche DNS, nonostante ciò che può essere nel file hosts. Questo è facilmente dimostrabile. Questo è specificamente un problema per lo sviluppo locale usando il .devTLD.

— Karl Wilbur,

0

Mi sono imbattuto in questa domanda pensando che il hostsfile non funzionava su Chrome per macOS per i .devdomini falsi che utilizzo per lo sviluppo.

In realtà si fa il lavoro, per lo meno su Chrome 77.

Il problema non è che il dominio non è stato trovato, ma che tutti i .dev vengono ora reindirizzati automaticamente a https :

Se fai doppio clic sul nome del dominio, puoi vedere il colpevole:

Ora che Google ha rotto il nostro .dev, come soluzione, il link sopra suggerisce di passare a un altro TLD per lo sviluppo, come .testo .localhost.

— Beniamino
fonte