Проверка статуса сервера v2.0

О программе Проверка статуса сервера

Проверка статуса сервера показывает, отвечает ли сайт прямо сейчас, каким HTTP-кодом и за какое время. Инструмент ToolsPivot отправляет реальный запрос со своего сервера и возвращает код ответа с расшифровкой, время до первого байта, полную цепочку редиректов, данные SSL-сертификата и сведения о веб-сервере и CDN. Одной проверки хватает, чтобы отличить упавший хостинг от ошибки приложения и понять, доступен ли сайт прямо сейчас или проблема только у вас.

Обзор проверки статуса сервера от ToolsPivot

Основная функциональность

Сервис делает HTTP-запрос к каждому указанному адресу и разбирает ответ по частям. Сначала уходит HEAD-запрос: он забирает только заголовки, без тела страницы, поэтому отрабатывает быстро и не нагружает чужой сервер. Если сервер отвечает кодом 405 или молчит, ToolsPivot автоматически повторяет попытку методом GET. Все заголовки ответа выводятся отдельным блоком, а для их детального разбора пригодится просмотр HTTP-заголовков.

Целевые пользователи и сценарии использования

Инструментом чаще всего пользуются вебмастеры, SEO-специалисты и системные администраторы. Типичные поводы: жалобы клиентов «сайт не открывается», провал трафика в Яндекс Метрике, переезд на новый хостинг, ночной деплой магазина на Битрикс, быстрая проверка посадочных страниц перед запуском кампании в Яндекс Директе.

Проблема и решение

Браузер не покажет настоящий код ответа чужого сайта. Кросс-доменный запрос возвращается «непрозрачным»: статус 0, заголовков нет, и так задумано ради безопасности. Владелец видит белый экран и не понимает, что сломалось. Серверная проверка снимает это ограничение и сразу называет виновника: DNS, TLS-рукопожатие, редирект или само приложение. Первый шаг диагностики удобно дополнить проверкой DNS-записей.

Основные преимущества проверки статуса сервера

• Настоящий код ответа: вы видите ровно то, что вернул сервер, вместе с расшифровкой по стандарту HTTP, а не догадку браузера.
• Разбивка времени по фазам: DNS, TCP, TLS, ожидание и загрузка выводятся пропорциональной полосой. Сразу видно, тормозит сеть или приложение.
• Честный вердикт вместо «да/нет»: код 503 означает, что сервер жив, но отдаёт ошибку. Это совсем другая задача, чем полностью упавший хост.
• Цепочка редиректов целиком: каждый переход выводится отдельной строкой с кодом и адресом, поэтому лишние хопы и петли заметны без ручной трассировки.
• Контроль срока сертификата: инструмент называет издателя и остаток дней до истечения. Углублённый разбор даёт отдельная проверка SSL-сертификата.
• Цифры вместо ощущений: время до первого байта фиксируется в миллисекундах, а полную картину скорости дополнит проверка скорости загрузки страницы.
• Пакетный режим на 20 адресов: агентство прогоняет клиентские сайты одним списком и выгружает результат в CSV.
• Без регистрации и ключей: ни аккаунта, ни API-ключа, ни лимита по числу проверок в сутки.

Ключевые функции проверки статуса сервера

• Расшифровка кодов: рядом с каждым статусом стоит объяснение простым языком, от 200 и 301 до 429 и 504.
• HEAD с переходом на GET: если сервер не переваривает HEAD, запрос автоматически повторяется обычным GET. Результат не теряется.
• Браузерный User-Agent: запрос уходит с реальным заголовком браузера, что снижает шанс получить ложный отказ от антибот-фильтра.
• Время до первого байта: отдельно показывается TTFB и общее время ответа, а не одно усреднённое число.
• Диаграмма фаз запроса: пять этапов соединения отрисованы в масштабе, поэтому узкое место находится за секунду.
• Пошаговый обход редиректов: сервис идёт по одному хопу, корректно разбирает относительные адреса, ограничивает цепочку десятью переходами и ловит петли. Настройки склейки адресов проверяет проверка редиректа www.
• Данные сертификата: издатель, дата окончания и остаток дней, с отдельной пометкой для просроченного сертификата.
• Определение веб-сервера: из заголовков вытягиваются значения Server и X-Powered-By, если они не скрыты прокси.
• Распознавание CDN: Cloudflare определяется по CF-Ray, CloudFront по X-Amz-Cf-Id, дальше Vercel, Fastly, Varnish и Akamai.
• Заголовки безопасности: HSTS, CSP, X-Frame-Options, X-Content-Type-Options и Referrer-Policy помечаются как найденные или отсутствующие. Более широкий аудит выполняет проверка безопасности сайта.
• Фильтры и экспорт: карточки результатов фильтруются по классу статуса (2xx, 3xx, 4xx, 5xx, недоступен), вся выборка выгружается в CSV.
• Защита от SSRF: адреса, ведущие во внутренние сети, отклоняются до отправки запроса.

Как работает проверка статуса сервера в ToolsPivot

1. Вставьте адрес сайта в поле проверки или переключитесь на вкладку массового режима и загрузите до 20 ссылок, по одной в строке.
2. Сервис резолвит хост в IP и сверяет его с чёрным списком диапазонов: приватные, loopback, link-local и служебные адреса отсекаются. Отдельно узнать адрес домена поможет определение IP-адреса домена.
3. К проверенному IP уходит HEAD-запрос с браузерным User-Agent. При отказе сервер опрашивается повторно методом GET.
4. Редиректы обходятся по одному переходу, и каждый новый адрес заново проходит проверку на безопасность.
5. Результат собирается в карточку: статус, время по фазам, цепочка переходов, сертификат, сервер, CDN и заголовки безопасности.

Когда использовать проверку статуса сервера

Проверка нужна в момент, когда поведение сайта расходится с ожиданиями, а причина неочевидна. Это первый инструмент диагностики: он занимает несколько секунд и сужает круг подозреваемых до одного слоя — сеть, TLS, редиректы или бэкенд.

• Сайт не открывается у клиента: проверка отвечает, лежит ли ресурс вообще или проблема на стороне конкретного пользователя.
• После переезда хостинга: убедиться, что домен уже отвечает с нового сервера, а не с закешированного старого IP.
• Провал позиций в поиске: длинные цепочки редиректов и коды 5xx мешают роботам Яндекса и Google обходить сайт.
• Перед запуском рекламы: объявление, ведущее на 404, сжигает бюджет молча.
• После релиза: код 502 или 504 сразу после деплоя указывает на приложение, а не на канал связи.
• Аудит чужого проекта: массовый прогон списка страниц показывает, где остались битые адреса. Дальше подключается поиск битых ссылок.
• Контроль сертификата: отследить остаток дней до истечения HTTPS раньше, чем это заметят посетители.

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

Примеры использования

Магазин после переезда на российский хостинг

Контекст: интернет-магазин перевезли с зарубежного VPS на Timeweb, часть покупателей жалуется на ошибки.

Процесс:

• Проверить главную и три категории на код ответа.
• Сверить IP в результате с адресом нового сервера.
• Посмотреть, откуда отвечает сайт, через определение хостинга сайта.

Результат: выясняется, что часть запросов ещё уходит на старый IP, и правится TTL DNS-записи.

Падение трафика без видимых причин

Контекст: посещаемость информационного проекта упала за неделю на треть, сайт при этом открывается нормально.

Процесс:

• Прогнать двадцать ключевых URL пакетным режимом.
• Отфильтровать карточки по классу 4xx и 5xx.
• Сверить проблемные адреса с отчётом Яндекс Вебмастера.

Результат: шесть страниц отдают 410 после чистки каталога, их возвращают или перенаправляют. Индексацию затем контролирует проверка индексации страниц.

Ночной деплой и ошибка 502

Контекст: разработчик выкатил обновление в 02:00 и получил жалобу от дежурного менеджера.

Процесс:

• Запустить проверку и увидеть 502 Bad Gateway.
• Посмотреть фазу ожидания в разбивке времени.
• Убедиться, что TLS-рукопожатие прошло штатно.

Результат: сеть и сертификат исправны, проблема локализована на уровне приложения за минуту вместо часа.

Агентство сдаёт отчёт по клиентам

Контекст: SEO-агентство ведёт пятнадцать проектов и еженедельно отчитывается о технической исправности.

Процесс:

• Загрузить список доменов клиентов в массовый режим.
• Выгрузить результат в CSV.
• Приложить таблицу к отчёту вместе со сроками сертификатов.

Результат: регулярная проверка занимает пять минут и ловит истекающие сертификаты заранее.

Как читать разбивку времени ответа

Разбивка времени говорит о причине задержки больше, чем итоговая цифра. Длинная фаза DNS указывает на медленные или неудачно выбранные NS-серверы. Растянутый TCP-этап характерен для географически далёкого хостинга. Тяжёлое TLS-рукопожатие встречается при неоптимальной цепочке сертификатов. Долгое ожидание при быстром соединении — это почти всегда бэкенд: тяжёлый SQL-запрос, отсутствие кеша, перегруженный PHP-FPM. Для российской аудитории ориентир по TTFB такой: до 200 мс комфортно, 200–600 мс терпимо, свыше секунды пользователи начинают уходить.

Почему сайт отвечает нам, но не открывается в России

Проверка идёт с одной точки, и это принципиальное ограничение, о котором честнее сказать прямо. Сайт на зарубежном хостинге может отвечать нашему серверу кодом 200 и при этом не открываться у пользователей из Рунета. Причины бывают разные: ограничение доступа по решению Роскомнадзора, фильтрация на стороне оператора связи, требования 406-ФЗ к хостинг-провайдерам или блокировка подсети, в которой живут соседние ресурсы. Если наша проверка показывает «онлайн», а посетители из России видят ошибку, стоит проверить домен и его IP в реестрах ограничений и посмотреть репутацию адреса через проверку домена в чёрных списках.

Чем проверка кода ответа отличается от пинга

Пинг и HTTP-проверка отвечают на разные вопросы. Пинг работает по протоколу ICMP и говорит только о том, что машина в сети. Сервер может исправно отвечать на пинг, пока веб-приложение отдаёт 500 всем подряд, и наоборот: многие хостинги режут ICMP на файрволе, хотя сайт работает безупречно. Наш инструмент делает настоящий HTTP-запрос — тот же, что и браузер посетителя. Поэтому вердикт совпадает с реальным пользовательским опытом, а не с состоянием сетевого интерфейса.

Часто задаваемые вопросы

Related Tools You Might Like

HTML-кодировщик Генератор доменных имён Сравнение текста Генератор карты сайта CSV в JSON Массовый GEO IP-локатор