Проверка статуса сервера 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-запрос — тот же, что и браузер посетителя. Поэтому вердикт совпадает с реальным пользовательским опытом, а не с состоянием сетевого интерфейса.

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

Что показывает проверка статуса сервера?

Она показывает HTTP-код ответа, время отклика, цепочку редиректов, данные SSL-сертификата, тип веб-сервера, CDN и набор заголовков безопасности. Всё это собирается за один запрос, без установки программ.

Какой код ответа считается нормальным?

Нормой для рабочей страницы считается код 200. Коды 301 и 308 допустимы, если редирект задуман, а вот 4xx и 5xx требуют разбирательства.

Почему сайт помечен как «отвечает с ошибкой», а не как недоступный?

Потому что это разные состояния. Код 503 означает, что сервер принял соединение и ответил, просто приложение временно не отдаёт контент; полная недоступность — это когда соединение не устанавливается вообще.

Проверка показала 403, но у меня сайт открывается. Почему?

Скорее всего, запрос заблокировала система защиты от ботов. Такие сервисы отдают 403 или 429 автоматическим клиентам, поэтому результат стоит перепроверить в браузере.

Зачем нужен повторный запрос методом GET?

Часть серверов не поддерживает HEAD и отвечает кодом 405 либо не отвечает вовсе. В этом случае инструмент автоматически повторяет проверку методом GET, чтобы результат не оказался ложноотрицательным.

Можно ли проверить доступность сайта из разных стран?

Нет, проверка выполняется с одной точки. Для географически распределённого контроля нужны мониторинговые узлы в разных регионах, и такую задачу решают специализированные сервисы.

Сколько адресов можно проверить за один раз?

В массовом режиме принимается до 20 ссылок, по одной в строке. Результаты выводятся отдельными карточками и выгружаются в CSV целиком.

Нужна ли регистрация или API-ключ?

Нет, ни аккаунт, ни ключ не требуются. Инструмент работает бесплатно и без ограничений по числу проверок.

Какое время отклика можно считать хорошим?

Для российской аудитории комфортным считается TTFB до 200 мс. Значения выше секунды заметно ухудшают поведенческие факторы, которые Яндекс учитывает при ранжировании.

Что делать, если цепочка редиректов длиннее двух переходов?

Её стоит сократить до одного перехода. Каждый лишний хоп добавляет задержку и размывает вес ссылки при обходе роботами.

Показывает ли инструмент срок действия SSL-сертификата?

Да, выводится издатель, дата окончания и остаток дней, а просроченный сертификат помечается отдельно. Разбор полей и цепочки доверия даёт расшифровка SSL-сертификата.

Почему сервис отказывается проверять локальные адреса?

Это защита от SSRF: инструмент, который ходит по произвольным ссылкам, нельзя использовать для запросов во внутреннюю сеть. Адреса из приватных и служебных диапазонов отклоняются, а узнать свой IP-адрес можно отдельным инструментом.

Насколько точно определяются веб-сервер и CDN?

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

Заменяет ли эта проверка постоянный мониторинг?

Нет, она даёт срез на текущий момент. Для отслеживания ночных сбоев и расчёта аптайма нужен мониторинг с расписанием и уведомлениями.

Related Tools You Might Like

Конвертер XML в JSON Генератор исходного кода сайта Двоичный код в текст Проверка хостинга CSV в JSON Генератор обратного текста