Каждый раз, когда пользователь вводит в браузере адрес сайта, компьютеру нужно превратить понятное человеку имя в числовой IP-адрес, по которому реально можно достучаться до сервера. Обычно эту работу выполняет служба DNS, но прежде чем отправить запрос куда-либо в интернет, операционная система заглядывает в собственный локальный список соответствий, который называется файлом hosts. Этот скромный текстовый файл без расширения существует дольше самого интернета в его нынешнем виде и до сих пор остаётся одним из самых простых и самых недооценённых инструментов управления сетевым трафиком.
Как файл появился во времена ARPANET и почему его заменила служба DNS
История файла hosts начинается в семидесятых годах прошлого века вместе с сетью ARPANET, созданной по заказу американского оборонного агентства DARPA. Тогда сеть объединяла всего несколько сотен узлов, и все соответствия между именами компьютеров и их адресами хранились в едином файле hosts.txt, за актуальность которого отвечал сетевой информационный центр Стэнфордского исследовательского института. Администраторы новых узлов присылали изменения по электронной почте, а остальные участники сети синхронизировали свою копию файла по протоколу FTP примерно раз в неделю. Схема прекрасно работала, пока сеть оставалась маленькой, но с ростом числа узлов рассылка обновлений и постоянно раздувающийся файл стали превращаться в серьёзную проблему: каждое обновление нужно было скачивать целиком, даже если менялась всего одна строка, а синхронизация десятков копий по всей сети занимала всё больше времени по мере роста ARPANET. К началу восьмидесятых годов количество узлов исчислялось уже сотнями, и стало очевидно, что централизованная модель с единственным файлом попросту не выдержит дальнейшего масштабирования сети до размеров, сопоставимых с современным интернетом. Решением стала распределённая система доменных имён, спецификация которой появилась в тысяча девятьсот восемьдесят третьем и восемьдесят четвёртом годах и полностью сняла с единого файла бремя описания всего интернета. Сам файл hosts при этом никуда не исчез и остался жить внутри каждой отдельной операционной системы уже в куда более скромной, локальной роли, превратившись из единого справочника всей сети в персональный список исключений и переопределений для конкретного компьютера.
Где на самом деле лежит файл hosts в современных версиях Windows
В современных версиях Windows, включая десятую и одиннадцатую, файл hosts находится по пути C:\Windows\System32\drivers\etc\hosts и не имеет расширения, что часто сбивает с толку пользователей, впервые пытающихся его найти через обычный поиск по расширению файла. Расположение внутри папки drivers объясняется историческим наследием: изначально сетевой стек в Windows проектировался как часть подсистемы драйверов, и с тех пор путь так и не поменяли, хотя прямой связи с современными сетевыми драйверами файл давно не имеет. В более старых версиях Windows, например в девяносто пятой и девяносто восьмой, файл лежал в куда более простом пути прямо внутри системного каталога Windows, и лишь с переходом на архитектуру NT и появлением строгого разделения системных компонентов на подсистемы разработчики закрепили за ним нынешнее вложенное расположение, которое с тех пор так и не менялось на протяжении уже двух десятилетий. На системах на базе Linux и macOS аналогичный файл лежит по пути /etc/hosts и выполняет ровно ту же функцию, что удобно для разработчиков, которым приходится работать сразу с несколькими операционными системами и повторять одни и те же настройки на каждой из них. Формат строк в обеих системах полностью совместим, поэтому одну и ту же строку с адресом внутреннего сервера или тестового домена можно смело копировать между Windows и Linux без каких либо переделок или адаптации синтаксиса, что заметно экономит время при настройке однотипных сред на разных машинах команды разработчиков.
Какой синтаксис использует файл hosts и как его читает система
Формат файла остался почти таким же простым, каким был полвека назад. Каждая содержательная строка состоит из IP-адреса, за которым через пробел или знак табуляции следует одно или несколько доменных имён, а строки, начинающиеся с символа решётки, считаются комментариями и полностью игнорируются при обработке. Типичная запись выглядит следующим образом:
127.0.0.1 localhost
::1 localhost
192.168.1.50 internal-test-server.local
0.0.0.0 ads.example-tracker.com
Первые две строки в этом примере как раз и превращают имя localhost в адрес самого компьютера, причём отдельно для протоколов IPv4 и IPv6, а последняя строка иллюстрирует распространённый приём блокировки нежелательного домена через перенаправление на несуществующий адрес 0.0.0.0. Операционная система читает файл построчно сверху вниз при каждом запросе разрешения имени и использует первое подходящее совпадение, поэтому порядок записей и отсутствие опечаток в написании домена имеют значение для корректной работы всей конструкции. Если один и тот же домен упомянут в файле несколько раз с разными адресами, система, как правило, использует именно первое найденное совпадение, поэтому опытные администраторы стараются держать файл компактным и хорошо структурированным, группируя связанные записи и оставляя поясняющие комментарии для будущего себя или коллег, которые будут разбираться с настройками спустя месяцы.
Почему запись в hosts почти всегда побеждает результат DNS сервера
Ключевая особенность файла hosts заключается в приоритете, который стандартный сетевой стек операционной системы отдаёт ему перед любым обращением к внешним DNS серверам. Когда программа запрашивает у системы IP-адрес по имени домена, диспетчер имён сначала проверяет локальный файл hosts, и только если подходящей записи там не нашлось, отправляет запрос дальше, к DNS серверу, указанному в настройках сетевого подключения. Такая архитектура объясняется исторической логикой доверия: локальные настройки конкретной машины считаются более авторитетными, чем любой внешний источник информации, ведь именно администратор компьютера или системы должен иметь последнее слово в том, куда именно отправится трафик с его устройства. Из этого правила следует важное практическое наблюдение для тех, кто настраивает hosts впервые: результат почти никогда не кэшируется где-то отдельно от системы, и любое изменение файла применяется к новым запросам сразу же, без необходимости перезагружать компьютер или сетевой адаптер. Впрочем, отдельные браузеры и приложения ведут собственный внутренний кэш DNS поверх системного, поэтому иногда для гарантированного применения новой записи из hosts стоит дополнительно очистить кэш конкретной программы или перезапустить её, даже если сама операционная система уже готова отдавать новый адрес.
Зачем администраторы и разработчики до сих пор редактируют hosts вручную
Несмотря на почтенный возраст, файл hosts остаётся рабочим инструментом в самых разных сценариях. Разработчики веб-приложений прописывают в нём временные записи, чтобы протестировать сайт под будущим доменным именем ещё до того, как настоящая запись появится на публичных DNS серверах, и такой подход избавляет от необходимости ждать распространения изменений по всему миру. Похожий приём применяют и веб-агентства при сдаче готового проекта заказчику: пока домен продолжает указывать на старый хостинг для всех остальных посетителей, разработчик через свой личный hosts уже видит новую версию сайта на новом сервере и может показать её клиенту без риска повлиять на реальных пользователей. Системные администраторы используют hosts для быстрой блокировки доступа к конкретным внешним ресурсам на корпоративных машинах, а также для перенаправления трафика внутренних сервисов на тестовые серверы во время отладки инфраструктуры. Отдельная категория пользователей редактирует hosts ради приватности, добавляя туда десятки и сотни строк с адресами рекламных и аналитических серверов, чтобы браузер даже не пытался к ним обращаться, экономя при этом и трафик, и время загрузки страниц. Похожим образом hosts используют и в закрытых лабораторных сетях, где нет собственного DNS сервера, но нужно, чтобы несколько десятков рабочих станций одинаково обращались к внутреннему серверу по человекочитаемому имени, а не по числовому адресу, который сложно запомнить и легко перепутать при ручном вводе.
Как вредоносные программы годами использовали hosts для подмены сайтов
Именно высокий приоритет файла над DNS сделал его удобной мишенью для вредоносного программного обеспечения. Классическая схема атаки строилась на том, что вирус тихо дописывал в hosts запись, перенаправляющую популярный банковский или почтовый сайт на поддельный сервер злоумышленников, полностью повторяющий внешний вид оригинала. Пользователь при этом видел в адресной строке браузера привычное и правильное имя домена, ведь подмена происходила глубже, на уровне разрешения имени в адрес, поэтому визуальных признаков взлома почти не оставалось, и жертва до последнего момента могла даже не подозревать, что вводит логин и пароль от банковского счёта на сервере злоумышленников, а не на настоящем сайте своего банка. Из-за подобных случаев современные версии Windows требуют прав администратора для сохранения изменений в файле hosts, а многие антивирусные программы отдельно отслеживают попытки записи в этот файл посторонним процессом и блокируют подозрительную активность ещё до того, как подмена вступит в силу. Известны и массовые случаи подобных атак: некоторые семейства вредоносного программного обеспечения десятилетиями специализировались именно на молчаливой правке hosts, добавляя туда сотни строк с подставными адресами сразу для множества банков и почтовых сервисов, чтобы охватить как можно больше потенциальных жертв одной и той же заражённой машиной.
Как правильно и безопасно редактировать hosts на практике
Чтобы внести изменения в hosts на современной Windows, недостаточно просто открыть его в текстовом редакторе двойным щелчком, поскольку файл защищён от записи обычным пользователем. Редактор нужно запустить от имени администратора, а уже затем открыть в нём файл по указанному выше пути, после чего внесённые строки сохранятся сразу и вступят в силу для всех новых сетевых запросов. Перед серьёзными экспериментами разумно сохранить резервную копию оригинального файла, поскольку случайная опечатка в адресе или лишний пробел способны привести к тому, что нужный сайт вовсе перестанет открываться, а разобраться в причине без явного понимания, где искать источник проблемы, довольно сложно даже опытному пользователю. Наиболее аккуратный подход к экспериментам с hosts заключается в том, чтобы вносить не более одной или двух новых строк за раз и сразу проверять результат в браузере, а не накапливать десяток изменений подряд, ведь в случае ошибки будет куда сложнее понять, какая именно строка сломала нужное соединение среди множества недавно добавленных. После завершения тестирования или отладки временные записи стоит удалять из файла, чтобы не забыть о них месяцы спустя и не удивляться, почему знакомый сайт вдруг ведёт себя не так, как положено. Полезной привычкой считается и периодическая проверка содержимого файла на предмет посторонних строк, особенно после установки сомнительного бесплатного программного обеспечения, поскольку некоторые рекламные модули до сих пор пытаются прописать в hosts собственные записи ради навязчивого показа баннеров или подмены стартовой страницы браузера без явного согласия пользователя, и обнаружить такое вмешательство постфактум бывает проще всего именно через прямой просмотр содержимого файла hosts.