Проверка доступности сайта онлайн: где сервисы врут
Онлайн-проверка отвечает на узкий вопрос: открылась ли одна страница с одного сервера в один момент. Разбираем, что из этого следует и как не поверить ни ложной тревоге, ни ложному «всё хорошо».
Проверка доступности сайта онлайн — это один HTTP-запрос с чужого сервера к вашему адресу. Сервис смотрит, ответил ли сайт и каким кодом, и показывает время ответа. Так можно быстро понять, лежит ли сайт для всех или только для вас. Но это снимок: одна точка, один момент, один адрес.
Результату стоит не верить, когда сервисы показывают разное, клиент жалуется на сбой, которого не видно, или зелёная отметка не совпадает с тем, что вы видите в браузере. Если сайт просто не открывается у вас, начните с разбора о том, как понять, у вас проблема или у сайта.
Что показывает онлайн-проверка
Обычный сервис делает запрос к адресу и сообщает три вещи:
- Получил ли он ответ вообще (соединение, DNS, TLS, ответ сервера).
- Какой HTTP-код пришёл. Классы кодов описаны в RFC 9110: 2xx — успех, 3xx — перенаправление, 4xx — ошибка запроса, 5xx — ошибка сервера.
- За какое время пришёл ответ.
Для бизнеса отсюда следует простое: «доступен» означает лишь то, что сервер ответил по этому адресу. Работает ли форма заявки, открываются ли каталог и корзина, по такому ответу не видно. Подробнее об этом разрыве в статье про аптайм 200 OK.
Почему сервисы расходятся
Два сервиса проверяют один сайт в одну минуту и дают разный результат. Это не обязательно ошибка: у них разные условия запроса.
| Что различается | Как влияет на результат |
|---|---|
| Место проверки | Из одной страны сайт открывается, из другой нет: сеть, маршрут, блокировка |
| DNS-резолвер | Один сервис уже получил новый IP, другой ещё держит старый из кэша |
| Метод запроса | HEAD и GET иногда обрабатываются по-разному |
| User-Agent | Защита сайта может отдавать сервису проверок капчу или 403 |
| Таймаут | Один ждёт 5 секунд, другой 30, и медленный сайт будет недоступен только для первого |
| Следование редиректам | Один считает успехом 301, другой идёт по цепочке до конца |
Поэтому одно красное сообщение — повод проверить, а не паниковать. Одно зелёное тоже ничего не гарантирует.
Где проверки ошибаются
Ошибки бывают в обе стороны. Ложная тревога неприятна, но ложное спокойствие дороже: о сбое вы узнаёте от клиента.
| Что показал сервис | Что могло быть на самом деле | Как отличить |
|---|---|---|
| «Недоступен», а у вас открывается | Сервис проверок попал под защиту от ботов или лимит запросов; сбой на его стороне | Повторить из другого сервиса и через curl |
| «Недоступен» только из одной страны | Проблема маршрута или блокировка по сети | Сравнить результаты из нескольких регионов |
| «Доступен 200», а пользователи видят пустую страницу | Сервер ответил, но приложение отдаёт пустой шаблон или ошибку в тексте | Проверять содержимое ответа, а не только код |
| «Доступен», а сайт медленный | Код есть, время ответа большое | Смотреть время ответа отдельно |
| «Доступен» по http, но не по https | Проблема с сертификатом или редиректом | Проверять именно тот адрес, которым пользуются люди |
| Разовый сбой в одну минуту | Короткая перезагрузка, пик нагрузки или сетевой сбой | Смотреть несколько проверок подряд, а не одно значение |
Отдельный случай — ответы 5xx. Если сервер отдаёт 502 или 500, сервис честно покажет сбой, но причину не назовёт. Для таких ситуаций есть разборы: 502 Bad Gateway и ошибка 500.
Поисковики тоже реагируют на серверные ошибки. В документации Google Search Central сказано, что при 5xx и 429 робот снижает частоту сканирования, а URL, которые долго отдают серверную ошибку, со временем удаляются из индекса. Короткий сбой обычно проходит без последствий, затяжной — нет.
Проверка через curl
curl ставится на любой компьютер и работает из вашей сети. Он показывает то, что видите вы, а не сервис: код ответа, время и заголовки. Все ключи описаны в документации curl.
Минимальная проверка кода и времени:
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/
Команда выводит код ответа и общее время запроса в секундах. Если вместо кода пришла ошибка соединения, уже понятно, где остановилось: на DNS, на соединении или на сертификате.
Порядок действий:
- Выполните запрос без редиректов и посмотрите код. 301 или 302 для адреса без
wwwили безhttps— нормально, если цепочка короткая. - Добавьте ключ
-L, чтобы дойти до конечной страницы, и проверьте итоговый код. - Запросите заголовки командой
curl -I(это HEAD-запрос) и сравните с полным GET:curl -sS -o /dev/null -D - https://example.com/. Если ответы различаются, сервис, который шлёт HEAD, показывает неверную картину. - Задайте предел времени ключом
--max-time, чтобы команда не висела бесконечно. - Если сайт только что переехал на другой сервер, проверьте его по конкретному IP ключом
--resolve. Так видно, отвечает ли новый сервер, пока DNS не обновился.
Эту проверку удобно повторить с рабочего компьютера, с мобильного интернета и с сервера хостинга. Три результата дают картину, которую одним сервисом не получить.
Проверка с разных провайдеров
Сайт может работать на сервере и быть недоступным у части аудитории. Причины лежат в сети между пользователем и сервером: у провайдера проблема с маршрутом, его DNS-резолвер отдаёт устаревший ответ, на пути стоит блокировка. Чинить на сервере при этом нечего.
Что делать:
- Проверьте адрес из нескольких регионов, а не из одного. Как это организовать и читать расхождения, разобрано в статье о доступности сайта из разных мест.
- Откройте сайт с мобильного интернета и с домашнего. Если есть разница, дело в сети конкретного провайдера.
- Проверьте DNS. После смены записей резолверы обновляются не одновременно, потому что ответы кэшируются на время TTL; принципы описаны в RFC 1034.
- Если сайт недоступен лишь у части пользователей, попросите у них адрес страницы, время и название провайдера. Без этих данных причину искать долго.
Если жалобы идут, а у вас всё работает, проверять нужно не сервер, а путь до него.
Что делать, если результаты разошлись
- Повторите проверку через 1–2 минуты. Разовый сбой на одной проверке — не авария.
- Проверьте тот же адрес вторым сервисом и через curl.
- Сравните регион и сеть: если сбой виден из одной точки, проблема скорее в маршруте.
- Проверьте содержимое. Откройте страницу и сравните с тем, что видит клиент.
- Если ошибка подтверждается из нескольких мест, пишите хостингу и приложите код ответа, время и вывод curl.
- После исправления проверьте время ответа. Что считать нормой, написано в разборе про время ответа сервера.
Чтобы не зависеть от случайных проверок, нужен постоянный мониторинг: регулярные проверки и уведомление, пока клиент ещё не написал. Как это устроено, описано в материале о том, как узнать о падении сайта раньше клиента.
Как проверить доступность сайта прямо сейчас
Откройте проверку доступности сайта, введите адрес и посмотрите код ответа и время. Регистрация не нужна. Если результат неожиданный, повторите проверку через curl по инструкции выше и сравните: расхождение подскажет, где искать причину.
Если сайт отвечает, но браузер ругается на безопасность, посмотрите проверку SSL-сертификата: частая причина недоступности — просроченный или неверно установленный сертификат.