Почему Chrome игнорирует /etc/hosts в OS X?
Я использую 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 ответа
Попробуйте добавить www.youtube.com в ваш файл hosts. youtube.com перенаправлен навсегда на www.youtube.com , так что пока вы посетили youtube.com один раз ваш браузер кэширует этот ответ и перенаправляет вас на www.youtube.com , Этот адрес отсутствует в вашем файле hosts, поэтому chrome логически разрешает его правильно.
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.
Встроенная в Chrome "защита" включает в себя проверку домена на соответствие его собственному DNS и обход в обход определенных типов записей хоста, которые он считает "подозрительными", или записей для существующих сайтов, которые переопределяются, что означает, что большинство пользовательских записей хоста игнорируются. Особенно записи *.dev и *.local, используемые для разработки.
Отключение этого вопроса решило проблему в 100% случаев для меня. Это месяцами сводило меня с ума, когда я занимался местным развитием, и я нигде не мог найти ответ, перечисленный выше, все просто говорили, что этого не может быть. Оказывается, это был простой переключатель в расширенных настройках. Надеюсь, это поможет вам, ура.
Я наткнулся на этот вопрос, думая, что hosts файл не работал на Chrome для MacOS для .dev поддельные домены, которые я использую для разработки.
На самом деле это работает, по крайней мере, на Chrome 77.
Проблема не в том, что домен не найден, а в том, что все.dev теперь автоматически перенаправляются на https:
Если дважды щелкнуть имя домена, вы увидите виновника:
Теперь, когда Google сломал наш .dev В качестве решения ссылка выше предлагает перейти к другому TLD для развития, например .test или .localhost,
Localhost - это соглашение для адреса 127.0.0.1, который является внутренним адресом для tcp/ip, однако Chrome не использует / etc / hosts для определения адреса, он использует DNS-сервер, поэтому любой адрес не исходит от вашего / etc / hosts, но с DNS-сервера, если он использует / etc / hosts, он должен будет содержать полные имена хостов www для решения любого адреса.
Надеюсь это поможет.