Чому Chrome ігнорує / etc / hosts в OS X?

27

Я використовую OS X 10.8.5 та Chrome 30.

Я додав 127.0.0.1 youtube.comу свій /etc/hostsфайл такий, що він тепер містить це:

# 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

Коли я запускаю команду, traceroute youtube.comя отримую очікувані результати (youtube.com дозволено 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

Однак, коли я набираю youtube.com в Chrome, мій браузер не встановлює з'єднання з 127.0.0.1, а натомість із "звичайною" IP-адресою для YouTube. Я б очікував, що Chrome дозволить вирішити youtube.com до 127.0.0.1.

У мене Chrome налаштований використовувати параметри проксі моєї системи. У ОС X, коли я переходжу до системних налаштувань> Мережа> "Додаткові ..."> Проксі, я вибрав "Автоматичне відкриття проксі".

Чому Chrome, здавалося б, ігнорує мій /etc/hostsфайл?

— Джонатан
джерело

4

Ви впевнені, що це намагається вирішити youtube.com, а не www.youtube.com? Можливо також, що youtube.com має переспрямування 301, яке кешується браузером, щоб він навіть не намагався зв’язатися з youtube.com (не на моєму комп’ютері, щоб перевірити).

— user2313067

@ user2313067 Дякую! Я переглянув / etc / hosts, щоб також розмістити рядок для www.youtube.com з роздільною здатністю 127.0.0.1, і це зробило трюк.

— Джонатан

@ user2313067 Ви можете залишити свій коментар як відповідь.

— Blacklight Shining

2

Можливий дублікат Чому Chromium обходить / etc / hosts та dnsmasq?

— Скотт

ви, ймовірно, використовуєте VPN або хромоване розширення, яке якось ВІДМИНАЄ ваше з'єднання

— user1735921

8

Спробуйте додати www.youtube.comдо файлу хостів. youtube.comбуде переадресовано назавжди на www.youtube.com, якщо ви youtube.comодин раз відвідували ваш веб-переглядач, кеш-відповідь кешує цю відповідь і перенаправляє вас на www.youtube.com. Ця адреса відсутня у вашому файлі хостів, тому хром логічно її вирішує правильно.

— user2313067
джерело

1

Зробіть це, щоб очистити ваші переадресації superuser.com/questions/304589/… або просто використовувати режим інкогніто для розвитку

— james.c.funk

1

Додавання wwwдля мене не працює. Навіть після очищення всіх даних мого браузера та очищення DNS. Можливо, це антифішинг, запечений у Chrome?

— f1lt3r

додаючи голі та www. Версії у файлі хостів працювали для мене. Я також відключив chrome: // flags / # enable-new-preconnect в Chrome

— LyK

10

Google Chrome ігнорує файл хостів і робить фактичні DNS - запити (незважаючи на те , що інші можуть думати, /etc/hostsне є частиною DNS, то , що було використано до для DNS). Хоча Google Chrome повинен шанувати ці записи файлів хостів, вони цього не роблять. Файл хостів, який є альтернативою DNS, буде прочитаний, коли немає сервера DNS (наприклад, якщо ви відключили мережеве з'єднання).

Ви можете перевірити це, додавши "127.0.0.1 foobar.dev" у файл хостів, а потім увімкнувши проводку та перегляд у вашому мережевому інтерфейсі. Відкрийте Chrome, помістіть http://foobar.dev/у свій адресний рядок і перейдіть. Ви побачите запит DNS у Wireshark, наприклад:

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

FWIW, Google DNS повертає 127.0.53.53 для foobar.dev.

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

Приблизним рішенням буде використання HostAdmin, який є старішим розширенням Chrome, завдяки якому Chrome використовує хости. Однак новіші версії Chrome (> 38, вже) не підтримують його.

— Карл Вільбур
джерело

Chrome насправді не ігнорує /etc/hostsфайл в OS X. Принаймні, не Chrome v43 в OS X 10.10.3.

— Петро Пеллер

Wireshark розповідає іншу історію.

— Карл Вільбур

1

Те, що Chrome також запитує Google DNS, може не означати / etc / hosts, ігнорується. Це може бути просто для оптимізації / реєстрації / шпигунської роботи. Я дуже часто використовую файл / etc / hosts в OS X і не маю проблем із Chrome.

— Петро Пеллер

3

Коли мій файл хоста має "127.0.0.1 foo.dev", а Chrome магічно вирішує foo.dev до 127.0.53.53, це IGNORING мій файл хостів.

— Карл Вільбур

1

Так, але з увімкненим Wi-Fi Chrome повинен спочатку використовувати файл хостів, перш ніж здійснити пошук DNS. Це не. У цьому проблема.

— Карл Вільбур

6

Я вирішив цю проблему, вимкнувши "Захист вас та вашого пристрою від небезпечних сайтів" у додатковій налаштуваннях Chrome.

Вбудований "захист" Chrome включає в себе перевірку домену проти власного DNS та обхід певних типів хост-записів, які він вважає "підозрілими", або записи для існуючих сайтів, які перекриваються, а це означає, що більшість користувацьких записів хоста ігноруються. Особливо * .dev та * .local записи, що використовуються для розробки.

Вимкнення цього питання вирішило проблему для мене 100% часу. Це зводило мене з розуму місяцями, коли я робив місцевий розвиток, і я не міг знайти відповіді, переліченої ніде, всі просто говорили, що це не може відбуватися. Виявляється, це був простий перемикач у розширених налаштуваннях. Сподіваюся, це допоможе і вам, ура.

— Джошуа Джарман
джерело

Дякую, я знав, що це працювало минулого тижня, я змінив параметри хрому на дефолт кілька днів тому, і він більше не працював. Це спрацювало!

— 98percentmonkey

Дякую, я знав, що це працювало минулого тижня, я змінив параметри хрому на дефолт кілька днів тому, і він більше не працював. Це спрацювало! Він називається "Безпечний перегляд" у новіших версіях

— 98percentmonkey

0

Localhost - це умовна умова для адреси 127.0.0.1, яка є внутрішньою адресою для tcp / ip, однак Chrome не використовує / etc / hosts для вирішення адреси, він використовує DNS-сервер, тому будь-яка адреса не надходить з вашого / etc / hosts, але з сервера DNS, якщо він використовував / etc / hosts, для вирішення будь-якої адреси доведеться містити всі імена хостів www.

Сподіваюсь, це допомагає.

— Мойсей Наджар
джерело

1

-1. /etc/hostsзамінює будь-які DNS-сервери. Так, якщо ви використовуєте лише /etc/hosts , він повинен містити всі доменні імена, але більшість налаштувань також включають DNS-сервери. Якщо Chrome просто попросить ОС розв’язати доменне ім’я, як слід , /etc/hostsспочатку буде перевірено, а якщо воно не містить записи, то буде відправлено запит DNS.

— Blacklight Shining

/etc/hosts має перекрити і запит DNS, але це не так у Google Chrome. Він готує власні пошукові записи DNS, незважаючи на те, що може бути у файлі хостів. Це легко продемонструвати Це конкретно питання для місцевого розвитку з використанням .devTLD.

— Карл Вільбур

0

Я наткнувся на це питання, думаючи, що hostsфайл не працює в Chrome для macOS для .devпідроблених доменів, які я використовую для розробки.

На насправді це робить роботу, по крайней мере , на Chrome 77.

Проблема полягає не в тому, що домен не знайдено, а в тому, що всі .dev тепер автоматично переспрямовуються на https :

Якщо двічі клацнути на доменне ім’я, ви можете побачити винуватця:

Тепер, коли Google зламав наш .dev , як рішення, посилання вище пропонує перейти на інший TLD для розробки, як-от .testабо .localhost.

— Бенджамін
джерело