Перевірка хостингу вебсайту

Перевірка хостингу вебсайту, це безплатний інструмент, який визначає хост сайту та показує пов'язані з ним дані про інтернет-провайдера, організацію й приблизне розташування мережі.

Що саме перевіряє інструмент?

Перевірка охоплює мережеві дані, пов'язані з IP-адресою, яку повертає доменне ім'я хоста. Коли ти вводиш хост, інструмент виконує DNS-пошук на сервері, визначає його IPv4-адресу й повертає пов'язану з нею інформацію.

DNS, або система доменних імен, перетворює такі назви, як www.example.co.uk, на числові IP-адреси, за допомогою яких комп'ютери встановлюють з'єднання. Для цього пошуку інструмент використовує функцію PHP gethostbyname. Оскільки вона визначає лише IPv4-адреси, перевірка хоста, доступного виключно через IPv6, може не дати корисного результату.

У результаті може відображатися хостингова компанія, інтернет-провайдер, хмарна платформа або мережа доставки контенту. Це не обов'язково компанія, яка володіє сайтом чи керує ним. Сайти, що працюють через такі сервіси, як Cloudflare, можуть показувати мережу проксі-сервісу, приховуючи адресу вихідного сервера.

Як перевірити хостинг вебсайту?

Введи хост сайту в поле Хост і запусти перевірку. Найменше неоднозначностей виникає зі звичайним іменем хоста, наприклад example.co.uk або www.example.co.uk.

1. Якщо потрібно визначити лише хост, видали шлях, рядок запиту та фрагмент сторінки.
2. Залиши точний субдомен, з яким виникла проблема. www.example.co.uk і shop.example.co.uk можуть вести до різних провайдерів.
3. Запусти перевірку та порівняй отримані дані про організацію й розташування з очікуваним сервісом.

Наприклад, якщо перевіряєш роботу магазину, введи shop.example.co.uk, а не лише example.co.uk. Якщо цей субдомен веде на окрему платформу електронної комерції, зазначена для нього організація може відрізнятися від результату основного сайту. Не варто вважати, що всі адреси в межах одного домену використовують спільну інфраструктуру.

Звичайне ім'я хоста не може містити пробілів. Шляхи, розділові знаки зі скопійованого тексту та крапка в кінці також можуть зробити введені дані неоднозначними, тому спочатку видали їх. Інтернаціоналізовані доменні імена з діакритичними або нелатинськими символами мають ASCII-сумісну форму, що складається з A-міток і використовує кодування Punycode. Якщо написання в Unicode не визначається, скористайся ASCII-сумісною формою домену. Цифри допустимі в багатьох мітках хоста, а символи підкреслення не можна використовувати у звичайних публічних іменах хостів вебсайтів.

Перевірка виконується на сервері. Введені дані передаються на нього через HTTPS і не зберігаються.

Як зрозуміти результат

Сприймай результат як інформацію про мережу, яка зараз відповідає для визначеного хоста, а не як підтвердження власника сайту чи фізичного розташування серверної. Кожне поле показує окрему частину цієї картини.

Широта й довгота визначаються за даними геолокації IP-адреси, а не за показниками GPS. Вони можуть указувати на зареєстрований офіс провайдера, регіональний мережевий вузол або загальну місцевість. Не використовуй ці дані, щоб визначати конкретну будівлю чи підтверджувати, де юридично зберігаються дані сайту.

Незнайома назва інтернет-провайдера або організації сама по собі не свідчить про несправність. Постачальники керованого хостингу часто орендують потужності у великих інфраструктурних провайдерів, а реселери можуть відображатися під назвою власника мережі вищого рівня.

Типові сценарії перевірки

Перевірка хостингу найкорисніша, коли ти вже знаєш очікуваного провайдера або ціль міграції та хочеш незалежно перевірити, куди зараз веде DNS-запис хоста.

• Після перенесення сайт досі показує стару версію. Спочатку перевір, чи не залишився застарілий вміст у кеші браузера, зворотного проксі або CDN. Перевір точне ім'я хоста, яке відкривається в браузері. Якщо його організація досі відповідає попередньому провайдеру, зміна DNS могла ще не дійти до резолвера, який використовує інструмент, або запис усе ще може вести на старий сервіс.
• Один субдомен не працює, а основний сайт відкривається. Окремо перевір example.co.uk, www.example.co.uk і проблемний субдомен. Різні результати можуть означати, що ці імена використовують окремі DNS-записи або хостингові сервіси.
• Після зміни хостингу з'явилося попередження про сертифікат. Поширеною причиною є відсутній, невідповідний або ще не налаштований сертифікат на новому хості, тому спочатку перевір конфігурацію сертифіката. Якщо з нею все гаразд, з'ясуй, чи веде хост до потрібного провайдера. Так можна виявити застаріле або неправильне призначення DNS, хоча інструмент не перевіряє сам сертифікат, строк його дії чи охоплені ним імена хостів.

Якщо призначення правильне, але сайт однаково не працює, проблема може бути на рівні HTTP, TLS або застосунку. Перевірка HTTP/2 дає змогу перевірити підтримку протоколу, а Перевірка Brotli підтверджує, чи використовує сервер стиснення Brotli. Жоден із цих інструментів не замінює спеціальної діагностики DNS або сертифіката.

Чому через кешування правильна зміна DNS може здаватися помилковою?

Через кешування DNS різні резолвери можуть повертати різні відповіді, доки кешовані записи не втратять чинність. DNS-записи мають час життя, який зазвичай називають TTL. Він указує рекурсивним резолверам, як довго можна зберігати відповідь.

Після зміни попередня адреса може все ще зберігатися в інтернет-провайдера, офісній мережі, на твоєму пристрої або в серверному резолвері інструмента. Це часто називають затримкою поширення, хоча DNS не оновлюється всюди одночасно й узгоджено. Строк дії кожного кешованого запису спливає незалежно, після чого його зазвичай запитують знову, коли виникає наступний запит.

Окремо виконай DNS-пошук, щоб порівняти визначену адресу з поточним A-записом у свого DNS-провайдера. Якщо розбіжність важлива, перевір також із кількох мереж. Переконайся, що зміни внесено до авторитетної DNS-зони й для правильної мітки хоста. Редагування www не змінює автоматично кореневий домен, і навпаки.

Жоден інструмент перевірки хостингу не може гарантувати, що його відповідь збігатиметься з поточною DNS-відповіддю для кожного відвідувача. Циклічний DNS, географічно розподілені сервіси та CDN можуть навмисно повертати різні адреси залежно від резолвера або місця розташування.

Поширені запитання

Чи можна так дізнатися, яка компанія володіє сайтом?

Ні. Інструмент визначає мережеві дані, пов'язані з хостом, а не юридичного власника домену чи сайту. Реєстраційні дані домену, відомості з реєстрів компаній і юридична інформація на самому сайті є окремими джерелами.

Чому назва організації не збігається з назвою в рахунку за хостинг?

Твій постачальник може бути реселером або керованим сервісом, що використовує мережу іншої компанії. Тому в результаті може відображатися хмарний провайдер або оператор дата-центру вищого рівня, а не компанія, якій ти платиш. Перш ніж вважати розбіжність помилкою, порівняй мережеві дані з документацією свого провайдера.

Чи можна перевірити сайт, який працює лише через IPv6?

Для пошуку імені хоста використовується gethostbyname, яка визначає IPv4-адреси. Тому хост, доступний лише через IPv6, може не повернути змістовної інформації про хостинг, навіть якщо він працює для відвідувачів із підключенням IPv6. У такому разі окремо перевір AAAA-запис.

Чи спрацює перевірка для дуже довгого імені хоста?

DNS обмежує повне доменне ім'я до 253 октетів у його звичайній текстовій формі, якщо необов'язкову кінцеву крапку кореня пропущено. Кожна мітка зазвичай обмежена 63 октетами. Дані, довші за встановлені DNS обмеження для імен, не можуть представляти дійсний публічний хост. Для практичної перевірки скопіюй лише хост, а довгі шляхи та параметри відстеження видали перед надсиланням.

Що вводити: кореневий домен чи адресу з www?

Спочатку перевір ім'я, яким насправді користуються відвідувачі. Якщо є сумніви щодо переспрямувань або DNS-записів, окремо перевір інший варіант. Кореневий домен і адреса з www можуть вести до різних систем, навіть якщо одна з них зрештою переспрямовує на іншу. Перед зміною DNS запиши обидва результати, щоб побачити, який саме хост усе ще потребує уваги.