Навчальний сценарій: копію сайту вже підготували на іншому хостингу, але домен поки веде на старий сервер. Як перевірити новий майданчик, не перемикаючи відвідувачів? Перевірка сайту до зміни DNS через curl --resolve дозволяє звернутися до обраної IP-адреси зі звичним доменом у URL. Це не зміна DNS для всіх користувачів, а окремий контрольний запит із вашого комп’ютера.
Мета цієї вправи — отримати три окремі докази: з’єднання встановлене з потрібною адресою, HTTPS проходить перевірку, а відповідь належить потрібній копії. Не плутайте це з повним прийманням міграції. Команди нижче не перевірять оплату, чергу листів або роботу JavaScript у браузері. Натомість вони допоможуть зупинитися до перемикання, якщо новий сервер ще не готовий.
Підготуйте адресу й контрольну ознаку
Приклад розрахований на термінал macOS або Linux із curl та підтримкою HTTPS, без HTTP- чи SOCKS-проксі. Права адміністратора не потрібні, запускати можна з будь-якого каталогу: наведені запити нічого не записують локально. Спочатку перевірте доступність інструмента. Якщо команда не знайдена, встановіть curl штатним менеджером вашої системи за її документацією; випадковий інсталяційний скрипт не потрібний.
curl --versionУ прикладах example.com — умовний домен, а 192.0.2.10 — документаційна адреса, не сервер для реального тесту. Замініть їх вашим доменом і IP нового хостингу, отриманим у провайдера. Порт 443 відповідає HTTPS. Перевіряйте лише власний сайт або середовище, на тестування якого маєте дозвіл.
До запуску попросіть відповідального за копію підготувати безпечну публічну контрольну ознаку: наприклад, файл migration-check.txt з узгодженим несекретним рядком, якого немає на старому майданчику. Це окрема зміна тестового середовища: погодьте її, не перезаписуйте наявний файл і заплануйте видалення після приймання. Не використовуйте для цього дамп бази, пароль, конфігурацію або персональні дані.
Отримайте відповідь саме від нового сервера
curl --resolve example.com:443:192.0.2.10 \
--connect-timeout 5 --max-time 15 \
--silent --show-error --dump-header - \
--output /dev/null \
--write-out 'HTTP=%{http_code} IP=%{remote_ip}\n' \
https://example.com/Команда надсилає звичайний GET, показує заголовки й підсумкові HTTP та IP, але відкидає тіло відповіді через /dev/null. Ліміти очікування не дають перевірці зависнути надовго. Успішне виконання слід зіставити з вашим очікуваним статусом; значення 200 саме по собі не підтверджує правильний вміст. Не додавайте автоматичного повторення до запитів, які можуть створювати замовлення або інші дані.
Параметр --resolve задає відповідність для конкретної пари домену й порту лише всередині цього запуску curl. Він не редагує системний hosts і не потребує відкату DNS після завершення. Домен у HTTPS-адресі залишається доменом сайту, тому тест не підмінюється простим відкриттям IP у браузері. Синтаксис перевіряйте в офіційній документації curl.
Порівняйте поле IP з адресою нового майданчика. Якщо вони різні, не робіть висновку, що міграція перевірена: спочатку з’ясуйте маршрут запиту, наявність проксі або помилку в аргументах. У корпоративній мережі не обходьте обов’язковий проксі самовільно. Узгодьте спосіб прямої перевірки з адміністратором або виконайте її в дозволеному середовищі без посередника.
Не приховуйте помилки TLS і редиректів
Якщо curl повідомляє про проблему сертифіката, не додавайте -k задля красивого результату. Звірте домен, сертифікат нового сервера, його ланцюжок і сховище довіри клієнта. Перевірка сертифіката має залишатися увімкненою. Особливості довіри залежать від збірки curl та TLS-бібліотеки; їх пояснює документація перевірки TLS. Сам факт помилки ще не доводить, що зламаний саме сервер.
Перша команда навмисно не переходить за редиректами. Якщо бачите 301 або 302, прочитайте Location: сайт може вести на www, інший піддомен чи стару адресу. Для кожного дозволеного кінцевого домену зробіть окремий запит із його власною відповідністю --resolve. Автоматичний перехід без такої перевірки може непомітно повернути вас на старий хостинг і створити хибне відчуття успішного перенесення.
Так само не поширюйте висновок з одного домену на всі його варіанти. Перевірений HTTPS без www не означає, що окремий www-віртуальний хост налаштований правильно. Запишіть потрібні для проєкту адреси перед тестом і позначайте кожну окремо. Якщо сервер захищений додатковими обмеженнями доступу, погодьте тест, а не вимикайте захист усього сайту.
Підтвердьте копію, а потім приймайте рішення
curl --resolve example.com:443:192.0.2.10 \
--connect-timeout 5 --max-time 15 \
--silent --show-error \
https://example.com/migration-check.txtЦей запит уже виводить тіло контрольного файла в термінал. Очікуваний результат — саме узгоджений рядок, а не випадкова сторінка з успішним статусом. Якщо отримали HTML помилки, перенаправлення або інший текст, збережіть спостереження й перевірте розміщення файла та конфігурацію віртуального хоста. Не публікуйте сирі заголовки, якщо вони містять cookies чи інші чутливі значення.
Для протоколу достатньо домену, цільового IP, дати, HTTP-статусу, результату TLS та контрольної ознаки. Додайте окремі рядки для важливої внутрішньої сторінки й статичного ресурсу. Це не навантажувальний тест: кількох послідовних запитів достатньо. За потреби оформіть проблему за порадником AriZone зі складання багрепорту, щоб відповідальний міг повторити її без здогадок.
Висновок: спочатку доведіть адресу з’єднання, справність HTTPS і належність вмісту, а вже потім плануйте зміну DNS. Окремо залишаються перевірки браузера, інтеграцій, пошти й резервного відновлення. Якщо потрібна допомога з прийманням нового хостингу, зверніться до AriZone з коротким протоколом, без паролів і приватних ключів: так можна почати з конкретного невдалого кроку, а не повторювати міграцію навмання.
Залиште коментар