Dlaczego Chrome ignoruje / etc / hosts w OS X?

27

Używam OS X 10.8.5 i Chrome 30.

Dodałem 127.0.0.1 youtube.comdo mojego /etc/hostspliku taki, że teraz zawiera on:

# 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

Po uruchomieniu polecenia traceroute youtube.comotrzymuję oczekiwane wyniki (youtube.com jest rozwiązywany do 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

Jednak gdy piszę youtube.com w Chrome, moja przeglądarka nie nawiązuje połączenia z 127.0.0.1, ale zamiast „normalnego” adresu IP YouTube. Spodziewałbym się, że Chrome rozwiąże youtube.com do 127.0.0.1.

Skonfigurowałem Chrome do korzystania z ustawień proxy mojego systemu. W OS X, kiedy idę do Preferencji systemowych> Sieć> „Zaawansowane ...”> Proxy, wybrałem „Automatyczne wykrywanie proxy”.

Dlaczego Chrome pozornie ignoruje mój /etc/hostsplik?

— Jonathan
źródło

4

Czy jesteś pewien, że próbuje rozwiązać youtube.com, a nie www.youtube.com? Może się również zdarzyć, że youtube.com ma przekierowanie 301, które jest buforowane przez przeglądarkę, więc nawet nie próbuje się skontaktować z youtube.com (nie na moim komputerze, aby to sprawdzić).

— user2313067

@ user2313067 Dziękujemy! Zmieniłem / etc / hosts, aby mieć linię dla www.youtube.com rozwiązującą się do 127.0.0.1 i to załatwiło sprawę.

— Jonathan

@ user2313067 Możesz opublikować swój komentarz jako odpowiedź.

— Blacklight Shining

2

Możliwy duplikat Dlaczego Chromium omija / etc / hosts i dnsmasq?

— Scott,

prawdopodobnie używasz VPN lub rozszerzenia chrome, które w jakiś sposób

— ZMIENIA

8

Spróbuj dodać www.youtube.comdo pliku hosts. youtube.comjest trwale przekierowywany na www.youtube.com, więc tak długo, jak youtube.comraz odwiedziłeś , Twoja przeglądarka buforuje tę odpowiedź i przekierowuje cię www.youtube.com. Tego adresu nie ma w pliku hosts, więc chrome logicznie rozwiązuje go poprawnie.

— użytkownik2313067
źródło

1

Zrób to, aby wyczyścić przekierowania superuser.com/questions/304589/... lub po prostu użyj trybu incognito do programowania

— james.c.funk

1

Dodawanie wwwnie działa dla mnie. Nawet po wyczyszczeniu wszystkich danych przeglądarki i wyczyszczeniu DNS. Być może jest to środek antyphishingowy wprowadzony do Chrome?

— f1lt3r

dodając zarówno nagi, jak i www. wersje w pliku hosts działały dla mnie.

— Wyłączyłem

10

Google Chrome ignoruje plik hosts i dokonuje rzeczywistych wyszukiwań DNS (pomimo tego, co inni mogą myśleć, /etc/hostsnie jest częścią DNS, to było to, co było używane przed DNS). Chociaż Google Chrome powinien honorować wpisy plików hostów, nie robi tego. Plik hosts, będący alternatywą dla systemu DNS, zostanie odczytany, gdy nie będzie dostępny żaden serwer DNS (na przykład po wyłączeniu połączenia sieciowego).

Możesz to przetestować, dodając „127.0.0.1 foobar.dev” do pliku hosts, a następnie włączając Wireshark i oglądając interfejs sieciowy. Otwórz Chrome, włóż http://foobar.dev/pasek adresu i idź. Zobaczysz zapytanie DNS w Wireshark, coś w stylu:

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

FWIW, Google DNS zwraca wartość 127.0.53.53 dla foobar.dev.

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

Obejściem może być użycie HostAdmin, który jest starszym rozszerzeniem Chrome, które sprawia, że Chrome korzysta z hostów. Jednak nowsze wersje Chrome (> 38, odpowiednio) już go nie obsługują.

— Karl Wilbur
źródło

Chrome właściwie nie ignoruje /etc/hostspliku w OS X. Przynajmniej nie Chrome v43 w OS X 10.10.3.

— Petr Peller

Wireshark opowiada inną historię.

— Karl Wilbur

1

Fakt, że Chrome również pyta Google DNS, może nie oznaczać, że / etc / hosts jest ignorowany. Może to być po prostu do celów optymalizacji / rejestrowania / szpiegowania. Używam pliku / etc / hosts bardzo często na OS X i nie mam problemów z Chrome.

— Petr Peller

3

Kiedy mój plik hosta ma „127.0.0.1 foo.dev”, a Chrome magicznie rozwiązuje foo.dev na 127.0.53.53, IGNORUJE plik mojego hosta.

— Karl Wilbur

1

Tak, ale przy włączonym Wi-Fi Chrome powinien najpierw użyć pliku hosts, zanim rozpocznie wyszukiwanie DNS. To nie. To jest problem.

— Karl Wilbur,

6

Rozwiązałem ten problem: WYŁĄCZ „Ochrona Ciebie i Twojego urządzenia przed niebezpiecznymi witrynami” w Zaawansowanych preferencjach Chrome.

Wbudowana „ochrona” Chrome obejmuje bezpośrednie sprawdzanie domeny pod własnym DNSem i pomijanie niektórych typów wpisów hosta, które uważa za „podejrzane” lub wpisów dla witryn, które są zastępowane, co oznacza, że większość niestandardowych wpisów hosta jest ignorowana. W szczególności * .dev i * .local wpisy używane do programowania.

Wyłączenie to rozwiązało problem w 100% dla mnie. Doprowadzało mnie to do szału przez wiele miesięcy, kiedy zajmowałem się rozwojem lokalnym i nie mogłem znaleźć nigdzie wymienionej odpowiedzi, wszyscy po prostu mówili, że to się nie dzieje. Okazuje się, że było to proste przełączanie w ustawieniach zaawansowanych. Mam nadzieję, że to wam również pomoże, na zdrowie.

— Joshua Jarman
źródło

Dzięki, wiedziałem, że to zadziałało w zeszłym tygodniu, kilka dni temu zmieniłem opcje chrome na domyślne i już nie działało. Zadziałało!

— 98percentmonkey

Dzięki, wiedziałem, że to zadziałało w zeszłym tygodniu, kilka dni temu zmieniłem opcje chrome na domyślne i już nie działało. Zadziałało! W nowszych wersjach nazywa się to „Bezpieczne przeglądanie”

— 98percentmonkey

0

Localhost to konwencja dla adresu 127.0.0.1, który jest wewnętrznym adresem dla tcp / ip, jednak Chrome nie używa / etc / hosts do rozwiązania adresu, używa serwera DNS, dlatego żaden adres nie pochodzi od twojego / etc / hosts, ale z serwera DNS, jeśli używałby / etc / hosts, będzie musiał przechowywać całą nazwę hosta www, aby rozwiązać dowolny adres.

Mam nadzieję że to pomoże.

— Moises Najar
źródło

1

-1. /etc/hostszastępuje wszelkie serwery DNS. Tak, jeśli używasz tylko /etc/hosts , musiałoby zawierać wszystkie nazwy domen, ale większość konfiguracji obejmuje również serwery DNS. Jeśli Chrome po prostu poprosi system operacyjny o rozpoznanie nazwy domeny, tak jak powinna , /etc/hostsnajpierw zostanie sprawdzona, a jeśli nie zawiera wpisu, zostanie wysłane zapytanie DNS.

— Blacklight Shining

/etc/hosts powinien zastąpić i żądanie DNS, ale nie jest tak w przypadku Google Chrome. Wykonuje własne wyszukiwania DNS, pomimo tego, co może znajdować się w pliku hosts. Jest to łatwe do wykazania. Jest to szczególnie problem dla rozwoju lokalnego za pomocą .devTLD.

— Karl Wilbur

0

Natknąłem się na to pytanie, myśląc, że hostsplik nie działa w Chrome na macOS dla .devfałszywych domen, których używam do programowania.

Właściwie to nie praca, przynajmniej w Chrome 77.

Problemem nie jest to, że domena nie została znaleziona, ale że wszystkie pliki .dev są teraz automatycznie przekierowywane na https :

Po dwukrotnym kliknięciu nazwy domeny możesz zobaczyć winowajcę:

Teraz, gdy Google złamał nasz .dev, jako rozwiązanie, powyższy link sugeruje przejście do innej TLD w celu rozwoju, takiego jak .testlub .localhost.

— Benzoes
źródło