Как посмотреть сайт на новом сервере до смены DNS: сравнение всех способов

Один сервер обычно обслуживает много сайтов и выбирает нужный по доменному имени, которое отправляет браузер, поэтому http://203.0.113.10/ показывает страницу по умолчанию или предупреждение о сертификате. Каждый способ ниже отправляет запрос на новый IP, говоря при этом: «Мне нужен example.com». Отличаются они тем, кто видит результат, на каких устройствах и насколько он точен.

Операционная система читает файл hosts раньше, чем обращается к DNS. Одна строка на каждое имя хоста направляет ваш домен на новый сервер, только на этом компьютере:

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
# macOS / Linux: /etc/hosts  (edit with sudo)
203.0.113.10   example.com
203.0.113.10   www.example.com

# Then flush the DNS cache
ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved

• Плюсы: точно, бесплатно и подходит для чего угодно: частные IP, любой порт, собственный сертификат и заголовки нового сервера. Генератор файла hosts составит строки за вас.
• Минусы: один компьютер за раз, нужны права администратора, непрактично на iOS и Android, легко забыть. Строка, оставленная после переноса, держит вас на неправильном сервере.
• Кому подходит: разработчику, который проверяет свою работу, и для финальной проверки HTTPS, заголовков безопасности и входа через сторонние сервисы перед переключением.

--resolve говорит curl, какой IP использовать для имени хоста, поэтому запрос несёт ваш настоящий домен, в том числе при установке TLS-соединения, а сертификат проверяется:

# Status line and headers from the new server, over HTTPS
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# The page title, to make sure it is your site and not a default page
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i "<title>"

# No certificate yet? -k skips verification; plain HTTP works with a Host header
curl -skI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI -H "Host: example.com" http://203.0.113.10/

Используйте -H "Host: …" только для обычного HTTP: по HTTPS curl всё равно отправит IP при установке TLS-соединения и будет сверять сертификат с ним. В Windows набирайте curl.exe, потому что в Windows PowerShell 5.1 curl — это псевдоним Invoke-WebRequest.

• Плюсы: секунды, ничего не нужно откатывать, легко автоматизировать, а коды ответа, редиректы и сертификат видны ровно такими, какими их отдаёт сервер.
• Минусы: нет отрисовки: только HTML и заголовки, и только для вас.
• Кому подходит: чтобы убедиться, что сайт настроен на новом сервере, прежде чем тратить время на что-то ещё, и для проверок в скриптах и CI.

Многие хостинги дают каждому аккаунту временный адрес на своём домене, а серверы с cPanel могут отдавать аккаунт по адресу http://203.0.113.10/~username/, если у хостинга включён mod_userdir. Ещё можно добавить запись для нового имени, например staging.example.com, указывающую на новый сервер: она добавляет имя хоста, не трогая рабочие записи.

• Плюсы: обычный URL, который открывается на любом устройстве и который можно отправить кому угодно, без дополнительных сервисов.
• Минусы: сайт отвечает под другим именем хоста. WordPress и большинство CMS перенаправляют на домен из своих настроек, который всё ещё указывает на старый сервер, а абсолютные ссылки и cookie тоже привязаны к настоящему домену. Исправление — это поиск и замена, которые перед запуском придётся откатить. Многие хостинги отключают адреса ~user, а HTTPS работает на временном имени, а не на вашем домене.
• Кому подходит: статическим сайтам и приложениям с относительными URL или когда хостинг передаёт сайт именно так и других вариантов нет.

Chrome и другие браузеры на Chromium принимают параметр запуска, который сопоставляет имена хостов с IP только для этого сеанса браузера. Отдельная папка профиля гарантирует, что запустится новый экземпляр с этим правилом:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=%TEMP%\chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# macOS
open -na "Google Chrome" --args --user-data-dir=/tmp/chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# A resolver for your whole network (dnsmasq; also covers subdomains)
address=/example.com/203.0.113.10

Последняя строка — та же идея уровнем выше: локальный резолвер, например dnsmasq, или локальная DNS-запись в Pi-hole отвечает новым IP каждому устройству, которое им пользуется, включая телефоны в этой сети Wi-Fi, если они используют DNS сети, а не собственный частный DNS. Расширения браузера не могут править файл hosts; некоторые сервисы превью предлагают расширение как быстрый доступ к своим ссылкам (у hosts.click заявлено расширение для Chrome; у DNSPeek его пока нет).

• Плюсы: никаких изменённых системных файлов, ничего не остаётся после закрытия браузера, а ответ точный, с настоящим доменом и сертификатом.
• Минусы: параметр Chrome работает только на компьютере, и в нём легко ошибиться, если Chrome с тем же профилем уже запущен. Резолвер кто-то должен поддерживать, и помогает он только тем, кто в вашей сети.
• Кому подходит: разработчикам, которым нужна точная картина без правки файла hosts, и командам, которые тестируют на реальных устройствах в одном офисе.

Сервис превью даёт вам HTTPS-ссылку на своём домене. Он подключается к указанному вами IP, запрашивает ваш настоящий домен и переписывает ссылки, редиректы и cookie, чтобы посетители оставались внутри превью. Это единственный способ из списка, которым клиент воспользуется без посторонней помощи.

Что заявляют сами сервисы, по состоянию на октябрь 2026 года (подробности: DNSPeek и SkipDNS, DNSPeek и Peek-DNS и DNSPeek и hosts.click):

• Плюсы: телефоны, планшеты и клиенты открывают её как любую ссылку, ничего не нужно устанавливать или откатывать, а пароль или срок действия держат всё под контролем.
• Минусы: посередине стоит прокси. DNSPeek, например, удаляет Strict-Transport-Security, Content-Security-Policy и X-Frame-Options и корректирует флаги cookie, чтобы превью работало на собственном адресе; вход через Google и страницы оплаты платёжных сервисов возвращают на ваш настоящий домен; файрволы на новом сервере могут проверять трафик прокси; доступны только публичные IP. См. чего не умеют превью.
• Кому подходит: для просмотра клиентом и заинтересованными людьми, проверок на телефонах и для всех, кого не стоит просить править системные файлы.

• Разработчик-одиночка, свой ноутбук: curl --resolve, затем файл hosts или параметр Chrome. Здесь они просто лучший выбор: точно, бесплатно, никого посередине. Ссылка-превью нужна разве что для проверки на телефоне.
• Агентство, которому нужно согласование клиента: ссылка-превью с паролем. Клиент не трогает системные файлы, а вы оставляете себе файл hosts для проверки HTTPS, заголовков и входа, которые меняет прокси. См. согласование с клиентом перед запуском и DNSPeek для агентств.
• Хостинг-провайдер, который переносит клиентов: временные адреса ломают большинство CMS, поэтому отправляйте ссылки-превью, созданные через API или предзаполненной ссылкой /new?domain=…&ip=…. Если кнопка внутри cPanel нужна уже сегодня, у SkipDNS и hosts.click заявлены плагины для панелей; у DNSPeek их пока нет. См. DNSPeek для хостинг-провайдеров.

Большинство переносов сочетает точную проверку для себя со ссылкой для всех остальных. Подробнее об этой паре: файл hosts или ссылка-превью; остальной переезд: чек-лист переноса сайта.

1. 1

   Шаг 1: Узнайте IP нового сервера

   Возьмите его из приветственного письма нового хостинга или из панели управления, а не из DNS-запроса к вашему домену. См. Как найти IP-адрес сервера.

2. 2

   Шаг 2: Проверьте, что сервер отвечает для вашего домена

   Выполните curl -sI --resolve example.com:443:203.0.113.10 https://example.com/. Код 200 или редирект на ваш же домен значит, что сайт настроен; страница по умолчанию — что ещё нет.

3. 3

   Шаг 3: Посмотрите сами в браузере

   Добавьте записи hosts с помощью генератора файла hosts или запустите Chrome с --host-resolver-rules, затем пройдитесь по ключевым страницам, формам и админке.

4. 4

   Шаг 4: Отправьте ссылку-превью тому, кто согласует

   Введите домен и IP в форме нового превью, задайте пароль, если сайт конфиденциальный, и отправьте ссылку клиенту или команде.

5. 5

   Шаг 5: Отмените подмены после переключения

   Удалите строки из hosts или закройте профиль Chrome, затем убедитесь, что публичный DNS сменился, с помощью проверки распространения DNS.