Как проверить домен, хостинг и сервер: 7 шагов за 10 минут

Перед покупкой домена, при переезде на новый хостинг или когда сайт вдруг «не открывается» — все ответы лежат в нескольких технических проверках. Они занимают десять минут и не требуют ни доступов к серверу, ни платных сервисов.

Ниже — последовательность, по которой мы сами диагностируем чужой сайт, когда клиент приходит с проблемой. Каждый шаг можно пройти бесплатными инструментами, ссылки на которые есть в тексте.

Шаг 1. Выяснить возраст и владельца домена

Первое, что стоит знать о домене — когда его зарегистрировали. Это объясняет больше, чем кажется: если домену три месяца, отсутствие позиций в Google — не поломка, а нормальный этап. Google нужно 3–6 месяцев, чтобы начать доверять новому имени.

Откройте проверку WHOIS и посмотрите на три поля: дату создания, дату окончания и регистратора. Дата окончания важна отдельно — просроченный домен отключается без предупреждения, и сайт исчезает для всех одномоментно.

Если покупаете домен с рук, WHOIS покажет ещё и историю: домен возрастом десять лет стоит дороже не просто так, но убедитесь, что на нём не было санкций. Проверить это можно, вбив домен в поиск Google с оператором site: — если в индексе вдруг сотни чужих страниц сомнительной тематики, от покупки лучше воздержаться.

Шаг 2. Увидеть, куда указывают DNS-записи

DNS — это система, которая превращает имя домена в адрес сервера. Когда сайт не открывается, а хостинг клянётся, что всё работает, причина обычно именно здесь.

В проверке DNS-записей смотрите на такие типы:

Классическая ситуация при переезде: A-запись уже показывает на новый сервер, а MX остались от старого хостинга — сайт открывается, а почта продолжает падать в старый ящик, о котором все забыли.

Отдельно обратите внимание на TTL рядом с каждой записью. Это количество секунд, которые провайдеры кешируют ответ. Перед запланированным переездом TTL снижают до 300, делают переезд, а затем возвращают обычное значение — так изменения расходятся за минуты, а не за сутки.

Шаг 3. Узнать, на каком хостинге стоит сайт

Проверка хостинга показывает, кому принадлежат серверы и в какой стране они физически стоят. Это пригодится в трёх случаях.

Первый — когда проверяете подрядчика. Если вам продали «выделенный сервер», а на самом деле сайт стоит на дешёвом шаред-хостинге вместе с сотней других, это видно сразу.

Второй — когда анализируете конкурента. Быстрый сайт часто быстрый не благодаря магии, а потому что стоит на нормальном железе рядом с аудиторией.

Третий — география. Если ваши клиенты в Украине, а сервер в Сингапуре, каждый запрос едет через полмира. Для украинского бизнеса оптимально Украина или Европа: разница в задержке между Киевом и Франкфуртом невелика, а между Киевом и Азией — критична.

Шаг 4. Измерить реальное время ответа

Слово «медленно» ничего не означает, пока не увидите цифры. Проверка времени ответа раскладывает загрузку на этапы, и каждый указывает на свою причину:

• DNS — больше 100 мс означает медленные серверы имён, иногда помогает переход на Cloudflare;
• Соединение — зависит от расстояния до сервера, здесь можно повлиять лишь переездом ближе;
• TLS — рукопожатие шифрования, обычно не проблема;
• TTFB — главная цифра. До 200 мс отлично, до 400 нормально, больше 800 — повод искать причину в хостинге или в самом сайте.

Если TTFB большой, а остальные фазы в норме — дело не в сети, а в том, что сервер долго готовит страницу. Это либо слабый тариф, либо тяжёлые запросы к базе, либо отсутствие кеширования. Глубже посмотреть можно аудитом скорости: он дополнительно проверит сжатие, кеш и форматы изображений.

Шаг 5. Проверить цепочку редиректов

После переезда или изменения структуры URL сайт часто начинает перебрасывать посетителя по кругу: с http на https, с www на без-www, со старого адреса на новый, а потом ещё и на слеш в конце. Каждый переход — это дополнительная задержка, а для поисковика ещё и размывание веса ссылок.

Проверка редиректов показывает всю цепочку с кодами. Правило простое: с любого адреса должно быть не больше одного перехода до конечной страницы. Если видите три-четыре — правила надо переписать. Сделать это корректно поможет генератор 301-редиректов: он сразу проверяет, не создают ли ваши правила бесконечного цикла.

Этот же инструмент раскрывает короткие ссылки. Если вам прислали bit.ly и вы не уверены, куда он ведёт — вставьте его сюда и увидите конечный домен, не переходя по ссылке и не оставляя там свой IP.

Шаг 6. Посмотреть, какие порты открыты

Это уже администрирование, но владельцу сайта тоже полезно знать. Проверка портов показывает, что видно снаружи.

Самое опасное, что можно найти — открытые порты баз данных: 3306 у MySQL, 5432 у PostgreSQL, 6379 у Redis, 27017 у MongoDB. Они не должны смотреть в интернет вообще: доступ к базе делается с самого сервера или через SSH-туннель. Redis и MongoDB исторически запускались без пароля, так что открытый порт означает, что базу может прочитать кто угодно.

Обратите внимание на разницу между состояниями. «Закрытый» означает, что сервер ответил отказом — порт доступен, но на нём никто не слушает. «Фильтруется» означает тишину: пакет исчез, и так ведёт себя фаервол. Если вы только что настроили сервис и видите «фильтруется» — смотрите правила фаервола, а не саму программу.

Шаг 7. Проверить SSL-сертификат

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

Проверка SSL показывает эмитента и количество дней до окончания. Поставьте себе напоминание за две недели до даты — даже если стоит автоматическое обновление Let’s Encrypt, оно иногда ломается после изменения конфигурации сервера.

Чек-лист проверки за десять минут

1. WHOIS — возраст домена и дата окончания.
2. DNS — A указывает на нужный сервер, MX не остались от старого хостинга.
3. Хостинг — страна и провайдер соответствуют вашей аудитории.
4. Время ответа — TTFB до 400 мс.
5. Редиректы — не больше одного перехода до конечного адреса.
6. Порты — базы данных закрыты снаружи.
7. SSL — до окончания больше двух недель.

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

Если после проверки что-то выглядит подозрительно, а разобраться самостоятельно сложно — напишите нам, посмотрим вместе.