Файл hosts: где лежит и как влияет на разрешение имён

До появления DNS соответствие имён адресам хранилось в одном текстовом файле, который рассылали по сетям. Файл hosts сохранился до сих пор и работает по тому же принципу: строка содержит IP-адрес, пробел и имя. Система смотрит в него раньше, чем спросит DNS-резолвер, поэтому запись в hosts имеет приоритет над тем, что скажет внешний сервер. Настройка порядка зависит от системы, но по умолчанию локальная таблица обычно первая.

От этого свойства зависит и польза, и риск. Файл позволяет быстро направить имя на нужный адрес без вмешательства в DNS, и он же удобная мишень для вредоносных программ.

В Windows файл лежит по пути C:\Windows\System32\drivers\etc\hosts, без расширения. В Linux и macOS это /etc/hosts. Редактировать его требуется с правами администратора: в Windows блокнот нужно запускать от имени администратора, в Linux и macOS использовать sudo с текстовым редактором. Строки, начинающиеся с символа решётки, считаются комментариями. Стандартное содержимое обычно включает строку для localhost и адрес 127.0.0.1 или ::1, о которых на странице loopback-127-0-0-1.

Изменения обычно вступают в силу сразу, но программа могла запомнить прежний ответ: браузер тогда стоит перезапустить, а кэш системы сбросить.

На устройствах с несколькими пользователями право менять файл обычно есть только у администратора. Если в организации кто-то правит его вручную на десятках машин, лучше перейти к внутреннему DNS: единая зона исключает расхождения, которые трудно заметить и долго искать.

Разработчики направляют имя тестового сайта на локальный или тестовый сервер, чтобы проверить работу до запуска. Администраторы перед переездом сайта проверяют новый сервер по тому же имени, не дожидаясь изменения DNS: см. dns-ttl. Иногда в файл вписывают имя рекламных или отслеживающих доменов с адресом 0.0.0.0, блокируя обращения к ним на уровне устройства. Ещё один вариант: временная правка при сбое DNS, когда нужное имя надо разрешить вручную.

Это удобно, но не подходит для управления большим числом узлов: файл нужно править на каждом устройстве отдельно.

Тот, кто получил права на запись в hosts, может перенаправить популярное имя на поддельный сервер, а пользователь этого не заметит. Признак — незнакомые записи в файле с адресами известных сайтов, странные предупреждения сертификата, невозможность открыть сайты антивирусных компаний. Подробнее о последствиях см. podmena-dns. Проверка простая: откройте файл и просмотрите содержимое; в норме там мало строк, в основном комментарии и localhost.

Если вы не вносили правку, но она есть, поищите вредоносное ПО и проверьте, какие программы имеют право менять системные файлы.

Частые проблемы: опечатка в адресе или имени, лишние символы, правка не тем файлом или без прав администратора, правка с сохранением расширения .txt, из-за чего файл не распознаётся. Ещё один случай: браузер использует собственный шифрованный DNS, тогда запись в hosts может не учитываться. Если после правки имя не открывается, проверьте его через nslookup и ping, помня, что nslookup обращается к DNS напрямую и файл hosts не читает, а ping использует системное разрешение и запись увидит.

Общая последовательность зависит от системы. В Linux порядок источников задаётся файлом настройки службы имён, и обычно первыми стоят локальные файлы, затем DNS. В Windows клиент DNS сначала проверяет собственный кэш, в который на старте загружаются и записи из hosts. В macOS порядок определяется службой разрешения имён системы. Каждая программа обращается к системному вызову, а не к DNS напрямую, поэтому запись hosts действует на браузер, почтовую программу и утилиту ping одинаково.

Исключения бывают: браузеры с собственным шифрованным DNS и некоторые приложения, которые самостоятельно запрашивают DNS, пропускают файл. Тогда правка выглядит «не работающей». Сравните поведение разных программ и включите/отключите шифрованный DNS в браузере, чтобы определить, кто именно игнорирует файл.

После проверки не забудьте убрать временные записи: старая строка, забытая на месяцы, заставит вас искать причину неработающего сайта там, где её нет. Помечайте временные строки комментарием с датой.