Как проверить сайт на новом сервере до изменения DNS через файл hosts

Зачем проверять сайт через hosts до изменения DNS

Файл hosts нужен, когда новый сервер уже подготовлен, а отправлять на него реальных посетителей ещё рано. Компьютер администратора начинает открывать домен с нового IP, тогда как публичная A-запись остаётся прежней.

Типичный сценарий — перенос WordPress на другой VPS. Файлы скопированы, база импортирована, домен добавлен в Nginx, но ещё неизвестно, работает ли авторизация, правильно ли подключилась база, нет ли ошибок PHP и какой сертификат отдаётся на 443-м порту. Если сначала переключить DNS, диагностировать всё это придётся уже на рабочем трафике.

Домен в адресной строке остаётся настоящим. Это принципиальное отличие от проверки сайта по временному IP или техническому URL. WordPress видит привычный hostname, браузер отправляет правильный Host, HTTPS использует нужное имя для SNI, а редиректы можно проверить в тех же условиях, в которых сайт будет работать после миграции.

Когда hosts удобнее временного домена

Для проверки одной миграции hosts часто проще staging-домена. Не нужно менять URL WordPress, править ссылки в базе или временно отключать принудительные редиректы на основной hostname. Если задача — открыть новую копию сайта только на своём компьютере, локальная подмена адреса решает её точнее.

Но hosts не должен превращаться в замену всей предпродакшен-проверки. Если новый сайт должны одновременно смотреть пять сотрудников, проще поднять staging. Если сторонняя система сама обращается к вашему домену, локальная запись на ноутбуке на неё вообще не повлияет. Эту границу стоит определить до начала теста.

Что именно делает файл hosts и чего он не меняет

Файл hosts задаёт локальное соответствие между конкретным hostname и IP-адресом. Если добавить строку:

203.0.113.25 example.com

то приложения, использующие системный механизм разрешения имён, смогут обращаться к example.com по адресу 203.0.113.25, хотя публичный DNS всё ещё возвращает другой сервер.

Например, в DNS:

example.com → 198.51.100.20

а в локальном hosts:

203.0.113.25 example.com

Тогда тестовый компьютер работает с 203.0.113.25, а остальные посетители продолжают открывать 198.51.100.20.

www, основной домен и поддомены — разные hostname

example.com и www.example.com нужно рассматривать отдельно. Запись для основного домена не покрывает автоматически www.

203.0.113.25 example.com
203.0.113.25 www.example.com

На миграциях это даёт очень характерный симптом. example.com уже прописан на новый VPS, браузер открывает новую копию, затем сервер отвечает редиректом на https://www.example.com/. Если www забыли добавить, следующий запрос уходит по публичному DNS на старую площадку. Со стороны выглядит так, будто hosts «иногда работает, а иногда нет».

Что hosts не меняет

Локальная запись не редактирует DNS-зону у регистратора или DNS-провайдера. Она не меняет NS, MX, TXT, CAA и другие публичные записи. Она также не заставляет внешние серверы использовать новый IP.

Если вы проверили сайт через hosts, это ничего не говорит о том, куда доставляется почта по MX, видит ли новый IP сторонний webhook и обновились ли DNS-записи у пользователей в других странах. Проверен только маршрут с конкретного устройства.

Когда hosts не подходит для полноценной проверки сайта

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

Webhooks и callbacks

Предположим, новый сайт принимает callback от платёжной системы или webhook от CRM. Вы открываете сайт через hosts и видите новую версию, но платёжный сервис по-прежнему разрешает example.com через публичный DNS и отправляет callback на старый сервер.

Локальная запись на вашем компьютере здесь не участвует.

То же касается:

• платёжных callbacks;
• webhooks из GitHub, CRM, Telegram или других сервисов;
• OAuth redirect/callback-сценариев, если проверка включает внешний сервер;
• роботов поисковых систем;
• удалённых API-клиентов;
• систем мониторинга, которые работают не с вашего компьютера.

Проверка с нескольких устройств

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

Почта тоже живёт отдельно

Проверка сайта через hosts не подтверждает работу почтового домена. Если после миграции меняется ещё и почтовая инфраструктура, MX, SPF, DKIM и приём SMTP нужно тестировать отдельно.

Если задача зависит от внешнего сервера, нужно отдельно определить, какой DNS использует именно этот сервер. Иначе можно идеально протестировать сайт локально, а после переключения обнаружить, что интеграции всё это время ходили на старую площадку.

Как проверить готовность нового сервера до изменения hosts

Запись в hosts бессмысленно править, если новый сервер ещё не готов обслуживать нужный hostname. Сначала стоит проверить Nginx или Apache, порты 80/443, DocumentRoot и ответ virtual host напрямую на новом IP.

Проверьте, слушает ли сервер HTTP и HTTPS

На Linux-сервере можно посмотреть, какие процессы слушают 80-й и 443-й порты:

ss -lntp | grep -E ':80|:443'

Если Nginx или Apache вообще не слушает нужный порт, редактирование hosts ничего не исправит. Браузер в такой ситуации может получить Connection refused либо зависнуть до timeout — в зависимости от того, как ведут себя сервис и firewall.

Connection refused обычно означает, что соединение дошло до адреса, но на этом порту никто не принимает запрос или порт отклоняется. Timeout чаще заставляет искать проблему в firewall, маршрутизации, security group или недоступности самого сервера.

Проверьте конфигурацию Nginx или Apache

Для Nginx перед тестированием полезно убедиться, что конфигурация синтаксически корректна:

nginx -t

В virtual host должен присутствовать нужный hostname, например:

server_name example.com www.example.com;

Если сервер отдаёт default page вместо нужного сайта, хотя IP правильный, проблема часто именно здесь: запрос до VPS дошёл, но веб-сервер выбрал не тот server-блок.

Для Apache ту же роль выполняют ServerName и ServerAlias. Команда проверки конфигурации зависит от системы и способа установки Apache, поэтому важнее сам принцип: до локальной подмены DNS убедиться, что веб-сервер знает этот домен.

Проверьте virtual host напрямую

Быструю HTTP-проверку можно выполнить вообще без hosts:

curl -I -H "Host: example.com" http://203.0.113.25

Команда соединяется с новым IP, но отправляет:

Host: example.com

Если вместо сайта приходит серверная заглушка, другой проект или неожиданный редирект, сначала исправляется virtual host. Смена DNS здесь ни при чём.

Есть и более точный вариант:

curl --resolve example.com:80:203.0.113.25 http://example.com/

Он полезен тем, что curl работает с настоящим URL example.com, но соединение принудительно направляется на нужный IP.

Если приходит 200, но сайт всё равно не тот

Код 200 сам по себе не доказывает правильную конфигурацию. Если на VPS размещено несколько сайтов, default virtual host тоже может вернуть 200. В такой ситуации проверяют:

• server_name или ServerName;
• DocumentRoot;
• конфигурацию PHP-FPM для конкретного сайта;
• какой конфиг реально загружен веб-сервером;
• нет ли старой копии сайта в другом каталоге.

Если этот этап не пройден, hosts только перенесёт проблему из терминала в браузер.

Как изменить файл hosts в Windows, macOS и Linux

Файл hosts системный, поэтому для сохранения изменений нужны повышенные права. Формат простой: сначала IP, затем один или несколько hostname, разделённых пробелами или табуляцией.

203.0.113.25 example.com www.example.com

Windows

Откройте Блокнот или другой текстовый редактор от имени администратора, затем откройте:

C:\Windows\System32\drivers\etc\hosts

Если файл не виден в окне открытия, выберите отображение всех файлов. У hosts нет расширения.

Одна из самых неприятных мелочей в Windows — случайно сохранить новую версию как hosts.txt. Если расширения скрыты, пользователь видит имя hosts, но Windows продолжает работать со старым системным файлом.

Перед проверкой имеет смысл включить отображение расширений файлов и убедиться, что в каталоге etc не появился отдельный hosts.txt.

Строки, начинающиеся с #, считаются комментариями. Поэтому такой вариант не работает:

# 203.0.113.25 example.com

А такой работает:

203.0.113.25 example.com

macOS

В macOS файл расположен по адресу:

/etc/hosts

Открыть его можно, например, через Terminal:

sudo nano /etc/hosts

После сохранения не ограничивайтесь просмотром самого файла. Следующий шаг — проверить фактическое соединение через curl.

Linux

В Linux используется тот же путь:

/etc/hosts

Один из простых вариантов редактирования:

sudo nano /etc/hosts

Если нужно протестировать основной домен и www, допустимо записать оба имени в одной строке:

203.0.113.25 example.com www.example.com

Лучший вариант — заранее сохранить копию исходного файла или хотя бы пометить собственную строку комментарием рядом. Через несколько недель забытая запись в hosts превращается в очень странный баг: у всех сайт уже работает с нового IP, а один компьютер продолжает ходить на старый.

Как доказать, что домен действительно открывается с нового сервера

Внешний вид страницы не доказывает, что запрос пришёл на новый сервер. Старая и новая копии WordPress могут быть идентичны, главная может отдаваться из кеша, а HTTP-заголовки Nginx на обоих VPS — совпадать.

Первое доказательство — фактический IP соединения.

curl -v https://example.com/

В выводе нужно найти строку, где показано соединение. В зависимости от версии curl она может выглядеть примерно так:

* Connected to example.com (203.0.113.25) port 443

Главное здесь — 203.0.113.25. Если это IP нового VPS, локальное разрешение имени сработало как ожидалось.

Проверьте запрос в access.log

Второе независимое подтверждение — журнал веб-сервера. Откройте страницу с тестового компьютера и сразу проверьте access.log нового сайта.

Запись может выглядеть примерно так:

192.0.2.50 - - [27/Aug/2026:01:10:22 +0300] "GET /server-check.txt HTTP/1.1" 200

Не нужно анализировать весь лог. Достаточно увидеть свежий запрос к конкретному URL с ожидаемым кодом ответа.

Если страница возвращает 500, одновременно смотрите error.log. На этом этапе часто выясняется, что сеть и hosts работают идеально, а проблема уже внутри PHP, WordPress или базы.

Создайте временный файл только на новом сервере

Для двух визуально одинаковых копий сайта удобно создать на новой площадке файл:

server-check.txt

Например, с короткой строкой:

new-server-test

Затем открыть:

https://example.com/server-check.txt

Если файл доступен, а соответствующий запрос появился в access log нового сервера, доказательств уже два. После теста файл удаляется.

Если эти признаки совпали, снова чистить DNS-кеш без причины уже нет смысла. Системный маршрут работает. Если браузер при этом показывает что-то другое, искать нужно выше: кеш страницы, Secure DNS, proxy, VPN или редиректы.

Как проверить новый сервер через curl --resolve без изменения hosts

curl --resolve позволяет проверить конкретный hostname на конкретном IP без изменения системного hosts. Для быстрой диагностики virtual host, HTTP и HTTPS это часто самый чистый первый тест.

HTTP:

curl --resolve example.com:80:203.0.113.25 http://example.com/

HTTPS:

curl --resolve example.com:443:203.0.113.25 https://example.com/

В обоих случаях URL остаётся example.com, но соединение выполняется с 203.0.113.25. Поэтому веб-сервер получает правильный Host, а HTTPS-запрос сохраняет нужный hostname для SNI.

Когда curl --resolve удобнее hosts

Если нужно быстро ответить на вопрос «готов ли этот virtual host на новом сервере?», редактировать системный файл необязательно. Одна команда сразу исключает часть переменных: системный DNS-кеш, случайный hosts.txt, старую локальную запись и часть браузерного поведения.

Это особенно полезно при первичной диагностике:

• отдаёт ли новый сервер нужный сайт;
• правильно ли настроен Host;
• отвечает ли HTTPS;
• какой сертификат приходит;
• есть ли редирект;
• возвращается ли 200, 301, 403, 404 или 500.

Когда всё-таки нужен hosts

curl --resolve проверяет один HTTP-клиент. Он не заменяет полноценный просмотр сайта в браузере. Если нужно проверить WordPress-админку, JavaScript, загрузку изображений, cookies, формы, корзину WooCommerce и несколько переходов между страницами, удобнее добавить запись в hosts и работать с сайтом обычным способом.

Оба инструмента решают одну задачу на разных уровнях. curl --resolve хорошо отвечает на вопрос «правильно ли сервер принимает этот домен», а hosts — «как сайт ведёт себя на моём компьютере до смены DNS».

Почему после изменения hosts всё ещё открывается старый сервер

Если запись добавлена, а браузер продолжает показывать старую копию сайта, проверяйте цепочку по порядку. Хаотичный flushdns, очистка cookies и перезапуск роутера часто только прячут настоящий симптом.

Шаг 1. Проверьте реальный hosts

Убедитесь, что редактировался системный файл и в нём сохранён новый IP:

203.0.113.25 example.com www.example.com

В Windows отдельно исключите hosts.txt.

Шаг 2. Посмотрите, куда ведут редиректы

Очень характерная ситуация: example.com уже открывается с нового сервера, но тот отвечает:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

Если www.example.com не добавлен в hosts, второй запрос снова уйдёт на публичный IP.

Первый ответ можно посмотреть так:

curl -I http://example.com/

Всю цепочку редиректов:

curl -IL http://example.com/

Опция -L заставляет curl следовать за перенаправлениями. Если на одном из шагов меняется hostname, проверьте, есть ли он в локальном hosts.

Шаг 3. Сбросьте системный DNS-кеш, если он действительно мешает

В Windows:

ipconfig /flushdns

В macOS и Linux способ зависит от используемого resolver. Универсальной команды для всех систем нет. Если curl уже показывает новый IP, повторная очистка системного DNS-кеша обычно ничего не даст — разрешение имени уже работает.

Шаг 4. Если curl новый, а браузер старый — ищите в браузере

Сценарий простой: curl показывает 203.0.113.25, а браузер продолжает показывать старую страницу. В этот момент hosts уже нельзя считать главным подозреваемым.

Проверьте:

• кеш браузера;
• Service Worker;
• Secure DNS / DNS over HTTPS;
• расширения браузера;
• локальный proxy;
• VPN;
• DevTools → Network и фактические запросы.

Приватное окно помогает исключить часть кеша и расширений, но не считается техническим доказательством само по себе. Сравнивайте с curl и серверным логом.

Шаг 5. Не ориентируйтесь только на nslookup

nslookup может обращаться непосредственно к настроенному DNS-серверу и не использовать системный hosts так, как его используют обычные приложения. Поэтому вывод со старым публичным IP не всегда означает, что локальная запись игнорируется.

Если nslookup показывает старый адрес, но:

curl -v https://example.com/

соединяется с новым IP, для проверки сайта важнее фактическое HTTP-соединение.

Шаг 6. Проверьте IPv4 и IPv6 отдельно

Если у домена есть AAAA, нужно понимать, по какому протоколу реально идёт запрос. Для диагностики удобно принудительно сравнить:

curl -4 -v https://example.com/

и:

curl -6 -v https://example.com/

Если IPv4 ведёт на новый сервер, а IPv6 — на старый или вообще не отвечает, причина уже видна. Отключать IPv6 «на всякий случай» не нужно.

Как диагностировать HTTPS, SSL и virtual host на новом сервере

HTTPS нужно проверять через настоящий hostname. Открытие https://203.0.113.25 не воспроизводит обычный запрос к домену: сервер может выбрать другой virtual host, а сертификат будет проверяться относительно IP.

После настройки hosts базовая проверка выглядит так:

curl -v https://example.com/

Без изменения hosts:

curl --resolve example.com:443:203.0.113.25 https://example.com/

Для просмотра сертификата и SNI:

openssl s_client -connect 203.0.113.25:443 -servername example.com

HTTP работает, HTTPS показывает другой сайт

Если http://example.com приходит на нужный проект, а https://example.com открывает чужой домен или стандартную страницу, запрос, скорее всего, попадает не в тот HTTPS virtual host.

Это уже не проблема hosts. Клиент пришёл на правильный IP, но конфигурация 443-го порта выбрала другой сайт.

Сертификат выпущен не на тот hostname

Сертификат может быть корректным для example.com, но не содержать www.example.com. Или сервер вообще отдаёт сертификат другого virtual host. В обоих случаях браузер покажет ошибку имени.

Проверяйте SAN сертификата и конкретный hostname, который открыт в браузере.

Connection refused и timeout на 443

Если TLS-соединение даже не начинается, сначала бессмысленно разбирать сертификат. Нужно проверить:

• слушает ли сервер порт 443;
• открыт ли порт в firewall;
• есть ли HTTPS-конфигурация для домена;
• не ограничен ли доступ к origin по IP.

Если по HTTP всё хорошо, а на HTTPS внезапно появляется другой сайт, это очень полезный симптом. Сеть работает, IP правильный, но запрос упирается в конфигурацию 443-го порта. Круг поиска сразу сужается.

Как hosts работает с Cloudflare, CDN, IPv6 и балансировщиками

При Cloudflare, CDN или внешнем балансировщике нужно сначала решить, что именно тестируется: новый origin или вся публичная цепочка. Запись hosts на IP origin обычно отправляет запрос непосредственно на сервер и обходит edge-инфраструктуру.

Cloudflare через hosts обычно обходится

Если публичный DNS домена проксируется через Cloudflare, посетитель обычно соединяется с edge-узлом Cloudflare. Но если в локальном hosts указать IP origin:

203.0.113.25 example.com

браузер будет пытаться соединиться напрямую с 203.0.113.25. Это хорошая проверка самого origin: Nginx, PHP-FPM, WordPress, базы, SSL и virtual host.

Но это проверка origin, не Cloudflare.

Origin может не принимать прямые подключения

Некоторые серверы настроены так, чтобы принимать HTTP/HTTPS только от IP Cloudflare или другого reverse proxy. Тогда прямой запрос через hosts может получить 403, timeout или блокировку firewall, хотя production через Cloudflare работает нормально.

В таком сценарии ошибка прямого hosts-теста не доказывает, что сайт сломан. Она может означать, что защита origin работает именно так, как была настроена.

Cloudflare Origin Certificate может не пройти браузерную проверку

На origin иногда установлен сертификат, предназначенный для соединения между Cloudflare и origin. Такой сертификат может быть корректен для этой цепочки, но браузер при прямом подключении к серверу способен считать его недоверенным.

Здесь нужно различать два сценария:

• проверяется обычный публично доверенный сертификат на origin;
• проверяется origin, который в production должен принимать TLS только от Cloudflare.

Во втором случае прямой браузерный тест не воспроизводит production полностью.

IPv4 и IPv6 нужно проверять отдельно

Если у домена есть A и AAAA, после миграции можно получить неприятное расхождение: IPv4 уже смотрит на новый сервер, а IPv6 остаётся старым.

Проверка IPv4:

curl -4 -v https://example.com/

Проверка IPv6:

curl -6 -v https://example.com/

Если -4 работает, а -6 уходит не туда, проблема локализована. Не нужно отключать IPv6 целиком — нужно разобраться с AAAA и адресацией нового сервера.

Балансировщик и несколько backend-серверов

Если production-домен работает через Load Balancer, а в hosts вы прописали IP конкретного backend, тестируется только этот узел. Балансировка, health checks и распределение запросов между остальными backend остаются за рамками проверки.

На сложной инфраструктуре фраза «через hosts всё работает» означает только то, что проверенный маршрут работает. Она не означает автоматически, что после смены DNS будет исправна вся цепочка от пользователя до origin.

Когда проверку через hosts можно считать завершённой

Главная страница WordPress открылась с нового IP — этого недостаточно. Перед сменой DNS нужно проверить сервер, сам сайт и сетевой маршрут отдельно. Главная может сидеть в кеше и выглядеть идеально, пока /wp-admin/ уже отдаёт 500 или форма не записывает данные в базу.

Проверка сервера

• домен попадает в нужный Nginx/Apache virtual host;
• DocumentRoot указывает на новую копию;
• PHP выполняется без критических ошибок;
• WordPress подключается к правильной базе;
• тестовые запросы появляются в access.log;
• error.log не заполняется новыми критическими ошибками при обычной работе.

Если главная страница открывается, а /wp-admin/ отвечает 500, миграция не закончена. Внешне сайт может выглядеть рабочим, но динамическая часть уже сломана.

Проверка самого сайта

Для обычного WordPress откройте не только главную, но и несколько страниц разных типов:

• главную;
• несколько внутренних страниц;
• запись блога;
• wp-admin;
• авторизацию;
• форму обратной связи;
• страницу с загрузкой изображений и CSS/JS;
• 404;
• URL с редиректом;
• REST API, если сайт его использует.

Для WooCommerce тест шире:

• каталог;
• карточка товара;
• вариативный товар, если он есть;
• корзина;
• AJAX-обновление корзины;
• личный кабинет;
• checkout до безопасного этапа без реального списания;
• письма и callbacks — отдельной проверкой, если они участвуют в сценарии.

Проверка редиректов и HTTPS

Обязательно пройдите варианты:

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

Нужно понять, какой адрес считается каноническим и куда ведут остальные. Если один hostname забыли в hosts, ошибка проявится именно здесь.

Полную цепочку можно посмотреть через:

curl -IL http://example.com/

Проверка сети и инфраструктуры

• IPv4 идёт на ожидаемый сервер;
• AAAA проверена отдельно, если используется IPv6;
• понятно, что именно обходит hosts при наличии Cloudflare/CDN;
• если используется балансировщик, проверка конкретного backend не принимается за проверку всей группы;
• внешние webhooks и callbacks протестированы отдельно.

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

Только после этого меняются A/AAAA-записи и начинается уже другая диагностика — публичный DNS, реальный пользовательский трафик, Cloudflare/CDN и внешние интеграции. До этого момента задача hosts одна: доказать, что новый сервер готов принять домен до того, как на него придут посетители.