Почему 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 настроен на использование настроек прокси моей системы. В OS 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 Вы можете оставить свой комментарий в качестве ответа.

— Сияющий

2

Возможный дубликат Почему Chromium обходит / etc / hosts и dnsmasq?

— Скотт

вы, вероятно, используете VPN или расширение Chrome, которое каким-то образом изменяет ваше соединение

— user1735921

8

Попробуйте добавить www.youtube.comв ваш файл hosts. youtube.comперенаправлен на постоянный адрес www.youtube.com, поэтому, пока вы посещали его youtube.comодин раз, ваш браузер кэширует этот ответ и перенаправляет вас на www.youtube.com. Этот адрес отсутствует в вашем файле hosts, поэтому chrome логически разрешает его правильно.

— user2313067
источник

1

Сделайте это, чтобы очистить ваши перенаправления superuser.com/questions/304589/… или просто используйте режим инкогнито для разработки

— james.c.funk

1

Добавление wwwне работает для меня. Даже после очистки всех данных моего браузера и очистки моего DNS. Возможно, это антифишинговая мера, запеченная в Chrome?

— f1lt3r

добавив как голые так и www. у меня работали версии в файле hosts. Я также отключил chrome: // flags / # enable-new-preconnect в Chrome

— LyK

10

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

Вы можете проверить это, добавив «127.0.0.1 foobar.dev» в ваш файл hosts, затем включив wireshark и наблюдая за вашим сетевым интерфейсом. Откройте 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, он игнорирует мой файл хостов.

— Карл Уилбур

1

Да, но с включенным Wi-Fi Chrome должен сначала использовать файл hosts, прежде чем выполнять поиск DNS. Это не. Это проблема.

— Карл Уилбур

6

Я исправил эту проблему следующим образом: Отключите «Защитить себя и свое устройство от опасных сайтов» в расширенных настройках Chrome.

Встроенная в Chrome «защита» включает в себя проверку домена на соответствие его собственному DNS и обход в обход определенных типов записей хоста, которые он считает «подозрительными», или записей для существующих сайтов, которые переопределяются, что означает, что большинство пользовательских записей хоста игнорируются. Особенно записи * .dev и * .local, используемые для разработки.

Отключение этого вопроса решило проблему в 100% случаев для меня. Это месяцами сводило меня с ума, когда я занимался местным развитием, и я нигде не мог найти ответ, перечисленный выше, все просто говорили, что этого не может быть. Оказывается, это был простой переключатель в расширенных настройках. Надеюсь, это поможет вам, ура.

— Джошуа Джарман
источник

Спасибо, я знал, что это сработало на прошлой неделе, я изменил параметры chrome на несколько дней назад и теперь он не работает. Это сработало!

— 98percentmonkey

Спасибо, я знал, что это сработало на прошлой неделе, я изменил параметры chrome на несколько дней назад и теперь он не работает. Это сработало! В новых версиях он называется «Безопасный просмотр»

— 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 запрос будет разослан.

— Сияющий

/etc/hosts следует переопределить и запрос DNS, но это не так с Google Chrome. Он преформирует свои собственные DNS-запросы, несмотря на то, что может быть в файле hosts. Это легко продемонстрировать. Это конкретно проблема для местного развития с использованием .devДВУ.

— Карл Уилбур

0

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

На самом деле это делает работу, по крайней мере , на Chrome 77.

Проблема не в том, что домен не найден, а в том, что все .dev теперь автоматически перенаправляются на https :

Если дважды щелкнуть имя домена, вы увидите виновника:

Теперь, когда Google сломал наш .dev, в качестве решения, ссылка выше предлагает перейти к другому TLD для разработки, например .testили .localhost.

— Вениамин
источник