Як переглянути сайт на новому сервері до зміни 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 теж тягнуться до справжнього домену. Щоб це виправити, доведеться робити пошук і заміну, яку перед запуском треба відкотити. Багато хостингів вимикають URL з ~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 для агенцій.
• Хостинг-провайдер переносить клієнтів: тимчасові URL ламають більшість 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.