SiteGuard4 ноября 202611 мин чтения

Как проверить доступность сайта и понять, у кого он не работает

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

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

Как быстро проверить, работает ли сайт

Начните с пяти действий. Они дадут больше полезной информации, чем многократное обновление одной вкладки.

Скопируйте точный адрес проблемной страницы. Сохраните протокол https://, поддомен и путь после имени сайта. Главная страница и адрес конкретного товара — разные объекты проверки. Если не открывается https://example.com/catalog/, успешная загрузка https://example.com/ ещё не разрешает вопрос.
Откройте этот адрес на телефоне через мобильную сеть. Выключите Wi-Fi на время теста, иначе компьютер и телефон могут использовать одно подключение. Используйте тот же URL и запишите устройство и оператора. Для более строгого сравнения можно подключить тот же компьютер к мобильной точке доступа и повторить запрос в прежнем браузере.
Выполните внешнюю HTTP-проверку. Выберите инструмент с несколькими точками проверки. Смотрите на результаты отдельных точек, код ответа и сообщение об ошибке, а не только на общую оценку.
Убедитесь, что загрузилась нужная страница. Вместо сайта могут открыться заглушка хостинга, страница входа или сообщение об обслуживании. Даже если адрес в браузере выглядит привычно, прочитайте содержимое.
Повторите неудачную проверку и запишите время. Для повторения достаточно небольшой паузы, например одной-двух минут. Это помогает отличить повторяющийся сбой от единичного неудачного запроса. При явной аварии не откладывайте обращение в поддержку ради длительного наблюдения.

Если страница открывается через мобильный интернет и внешние точки, но не открывается через домашнюю сеть, у вас есть основание проверять конкретное подключение. Если одинаковая ошибка повторяется из нескольких независимых сетей, соберите результаты и передайте их владельцу сайта. Это сильнее, чем предположение «у всех всё сломалось», но всё ещё относится к проверенным точкам и времени.

Что именно подтверждает проверка доступности

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

Доступность адреса: удаётся ли обратиться к указанному URL и получить HTTP-ответ.
Доступность страницы: возвращается ли ожидаемая страница, а не ошибка, перенаправление в неожиданное место или заглушка.
Работоспособность сценария: удаётся ли выполнить конкретное действие — войти в кабинет, отправить форму, оформить заказ.

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

Отдельно учитывайте время. Успешный ответ через длительное ожидание не обязательно соответствует требованиям бизнеса. При этом одно медленное измерение из удалённой точки ещё не доказывает, что всем посетителям неудобно пользоваться сайтом. Для вывода нужны сопоставимые повторения и условия тестирования.

Как проверить доступность сайта онлайн

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

Check-Host: HTTP-проверка из разных точек

В Check-Host есть отдельные режимы HTTP, DNS, Ping и TCP. Для проверки открытия веб-страницы выберите HTTP, укажите её адрес и изучите ответы доступных точек. Сервис позволяет сопоставить доступность и время HTTP-ответа из разных стран и дата-центров.

Не подменяйте HTTP-проверку режимом Ping. Если сервер отвечает на сетевые пакеты, это ещё не говорит о том, что он отдаёт нужную страницу. Режим DNS пригодится как дополнительное измерение, когда требуется сравнить разрешение имени, но сам по себе также не проверяет содержимое сайта.

Если инструмент показывает перенаправление, уточните конечный адрес. Ответ 301 с переходом на HTTPS может быть нормальной частью настройки сайта. Остановка проверки на первом перенаправлении не сообщает, успешно ли загрузилась страница в конце цепочки.

Uptrends: проверка ответа по географии

Uptrends Website Uptime Test проверяет HTTP-доступность из нескольких географических точек и показывает результаты по отдельным локациям. Такой отчёт удобен, когда нужно увидеть, повторяется ли проблема в разных регионах. Смотрите подробности неудачного соединения и время ответа, если они доступны в результатах.

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

Какой адрес можно отправлять на внешнюю проверку

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

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

Как проверить сайт с компьютера через curl

Командная строка полезна, когда нужен воспроизводимый результат: HTTP-заголовки, конечный URL и время запроса. В примерах ниже замените https://example.com/ на публичный адрес проверяемой страницы. example.com здесь служит примером, а не адресом вашего проекта.

Для Linux и macOS выполните в терминале:

curl --location --max-redirs 5 --connect-timeout 10 --max-time 30 --silent --show-error --dump-header - --output /dev/null --write-out "\nHTTP=%{http_code}\nURL=%{url_effective}\nTIME=%{time_total}s\n" "https://example.com/"

В Windows используйте curl.exe, чтобы явно вызвать curl. Вставьте команду одной строкой в PowerShell:

curl.exe --location --max-redirs 5 --connect-timeout 10 --max-time 30 --silent --show-error --dump-header - --output NUL --write-out "\nHTTP=%{http_code}\nURL=%{url_effective}\nTIME=%{time_total}s\n" "https://example.com/"

Команда выполняет GET-запрос, показывает заголовки и не выводит тело страницы. При перенаправлениях блоков заголовков будет несколько; итоговый код смотрите в строке HTTP. Она следует не более чем пяти перенаправлениям, ограничивает установление соединения десятью секундами, а всю операцию — тридцатью. Эти значения выбраны для примера и не являются нормативом скорости сайта.

HTTP — код последнего полученного HTTP-ответа.
URL — адрес, на котором закончилась проверка.
TIME — время операции в секундах; оно не описывает полную загрузку страницы браузером.

Оценивайте HTTP-статус вместе с сообщениями об ошибке и кодом завершения curl: ответ 200 может прийти до обрыва загрузки. Сразу после команды в PowerShell проверьте $LASTEXITCODE, а в Linux/macOS — echo $?. Ноль означает выполнение передачи по заданным условиям; в приведённой команде ответы 404 и 500 сами по себе не дают ненулевой код, поскольку опция --fail не включена. Различие объясняет документация curl о кодах завершения. Для вывода о доступности проверяйте оба результата.

Если ответа HTTP не было, возможен вывод HTTP=000. Это не серверный статус: читайте сообщение curl об ошибке. Не добавляйте -k, чтобы скрыть проблему проверки TLS-сертификата. Заголовки могут содержать cookies, поэтому удаляйте такие данные перед передачей отчёта.

Особенности GET и HEAD. HEAD не передаёт тело ответа и удобен для просмотра метаданных. Некоторые приложения обрабатывают его иначе, чем GET, поэтому ошибка HEAD требует дополнительной проверки обычным GET-запросом. И даже успешный GET из этого примера стоит дополнить просмотром страницы: тело ответа мы намеренно не изучали.

Как понимать результаты проверки

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

Результат	Что он подтверждает	Чего он не доказывает
`200 OK`	Сервер сообщил об успешном выполнении запроса.	Что содержимое верное, JavaScript работает и заявка дойдёт до менеджера.
`301` или `302`	Получено перенаправление.	Что конечная страница доступна и переход ведёт туда, куда нужно.
`401` или `403`	Запрос столкнулся с требованием авторизации или отказом в доступе.	Что весь сайт недоступен всем посетителям.
`404`	Запрошенный ресурс не найден либо сервер не раскрывает его наличие.	Что главная и остальные страницы тоже не работают.
`500`, `502`, `503`, `504`	Получен ответ об ошибке на стороне сервера или промежуточного узла.	Какой компонент сломан и насколько широко проявляется сбой.
Тайм-аут, ошибка DNS или TLS	Проверка не завершилась ожидаемым успешным обменом в данных условиях.	Что причина обязательно в хостинге или сайт недоступен из любой сети.
Успешный Ping	Получен ответ на ICMP-запрос.	Что HTTP, HTTPS и приложение работают.

Для владельца сайта полезно заранее описать ожидаемый результат. Например: «Публичная страница контактов открывается по HTTPS, после допустимого перенаправления возвращает 200 и показывает действующий телефон». Это понятнее и точнее, чем требование «домен должен отвечать».

Почему сайт доступен в одном тесте и недоступен в другом

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

Адрес. Одинаковы ли протокол, поддомен, путь и параметры? Версия с www может вести по другой цепочке перенаправлений.
Время. Сравнивались ли результаты одного периода? За несколько минут сайт мог восстановиться или снова перестать отвечать.
Сеть. Проверки действительно шли через разных провайдеров? Географические метки помогают ориентироваться, но не описывают все маршруты реальных посетителей.
Доступ. Не открыта ли у вас авторизованная сессия, которой нет у внешнего инструмента? Не требует ли сайт от автоматического запроса дополнительной проверки?
Содержимое. Одинаковую ли страницу вы получили? Кэшированная копия, страница защиты и рабочее приложение могут выглядеть как разные результаты одной проверки.

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

Если сайт должен обслуживать определённую страну или регион, проверяйте его из соответствующей сети. Успешный тест из другой страны не снимает проблему конкретного клиента. Аналогично один неуспешный зарубежный запрос не позволяет объявить недоступность для всей основной аудитории.

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

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

Можно использовать такой шаблон:

Адрес: https://example.com/catalog/
Время проверки и часовой пояс: ...
Устройство и браузер: ...
Сеть: домашний провайдер / мобильный оператор
Результат: код HTTP или точный текст ошибки
Повторная проверка: время и результат
Проверка из другой сети: результат
Внешний тест: выбранные точки и результаты
Ожидалось: страница каталога с товарами
Получено: ...

Перед отправкой уберите секретные параметры URL, cookies и персональные сведения со скриншотов. Если вы владелец проекта, дополните обращение временем последних изменений и идентификатором запроса из ошибки, если он есть. Не приписывайте причину заранее: формулировка «три точки получили 502 в такое-то время» полезнее утверждения «у хостинга сломалась база данных» без подтверждения.

Когда разовой проверки уже недостаточно

Ручной тест помогает разобраться в текущем эпизоде. Он не покажет сбой, который произошёл ночью и закончился до начала рабочего дня. Если сайт принимает заявки или на него ведёт платная реклама, имеет смысл настроить регулярные проверки и получать уведомления при обнаружении недоступности.

Для регулярного контроля определите, какие ответы считать сбоем, сколько подтверждений требуется и куда отправлять сигнал. История результатов должна охватывать период, который вы анализируете. Перейдите на SiteGuard, чтобы изучить актуальное предложение и сопоставить условия с этими требованиями. Выберите канал связи, который действительно читает ответственный за сайт.

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

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

Частые вопросы

Как узнать, сайт не работает у всех или только у меня?

Сравните один URL через свою сеть, мобильного оператора и внешний HTTP-тест. Если ошибка повторяется в нескольких независимых местах, проблема выходит за пределы вашего устройства. Говорить буквально «у всех» по ограниченному набору точек нельзя: указывайте, где и когда получен результат.

HTTP 200 означает, что сайт исправен?

Он означает успешный ответ на конкретный запрос. На странице при этом может оказаться неправильное содержимое, а отдельные действия — не работать. Откройте страницу, проверьте ожидаемый текст и отдельно выполните важный пользовательский сценарий.

Почему сайт открывается, хотя Ping не проходит?

Ping использует ICMP, а браузер обращается к веб-сервису другим способом. Отсутствие ответа на ICMP само по себе не подтверждает недоступность страницы. Для вопроса «открывается ли сайт» используйте HTTP/HTTPS-проверку.

Достаточно ли проверки из одной страны?

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

Как узнать, был ли сайт недоступен вчера?

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