Как проверить доступность сайта из России: 5 способов — от пинга до мониторинга

«Сайт работает» — понятие географическое. Один и тот же сайт может открываться у вас, тормозить в Новосибирске и не открываться во Владивостоке. Разбираем пять способов проверить доступность сайта именно из России — от 10-секундных до постоянных, с реальными цифрами и командами.

Почему «у меня открывается» ничего не доказывает

Ваш браузер — худший инструмент проверки. Он показывает страницу из кэша, ваш провайдер отдаёт DNS-ответ из своего кэша, а если включён VPN — вы вообще смотрите на сайт из другой страны. Плюс география: путь пакета от Москвы до Владивостока и обратно физически не может занять меньше ~64 миллисекунд — 6 400 км по прямой в оба конца при скорости света в оптоволокне около 200 000 км/с, а реальный маршрут длиннее прямой. Проблемы конкретного региона, оператора или магистрали из вашего кресла не видны в принципе.

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

Способ 1. Другая сеть: мобильный интернет и инкогнито

Самая быстрая триангуляция без единого инструмента: откройте сайт в режиме инкогнито (отсекает кэш браузера), затем с телефона через мобильный интернет, не через Wi-Fi (отсекает вашего домашнего провайдера и его DNS). Если через мобильную сеть открывается, а через домашнюю нет — проблема на стороне провайдера или в DNS-кэше, а не на сайте. Это проверка за 30 секунд, но с очевидным пределом: вы проверили две сети в одном городе, а не страну.

Способ 2. Консоль: ping и curl

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

ping -c 5 example.ru

Вторая — curl с таймингами: она показывает не только «открылся/не открылся», но и на какой фазе теряется время — DNS, соединение, TLS или ответ сервера.

curl -o /dev/null -s -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
Всего: %{time_total}s
Код: %{http_code}
" https://example.ru

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

Способ 3. Онлайн-чекеры

Сервисы разовой проверки («введите URL — покажем, доступен ли сайт») удобны как второе мнение: они смотрят на сайт не из вашей сети. Но у большинства из них проверяющие серверы стоят за рубежом — и тогда вы узнаёте, доступен ли сайт из Европы или США, что для аудитории из России отвечает на другой вопрос. Перед использованием стоит проверить, откуда именно сервис выполняет проверку и умеет ли он показывать результат по городам России отдельно. Второе ограничение принципиальное: чекер отвечает «доступен ли сайт сейчас», а инцидент в 3 часа ночи он за вас не заметит.

Способ 4. Публичные страницы мониторинга: живые цифры

Полезный промежуточный вариант — открытые страницы, где мониторинг уже работает постоянно и показывает результаты всем. У Пруфена таких две: на /status видно состояние сети точек мониторинга по городам, на /popular — как крупнейшие сайты Рунета отвечают прямо сейчас. Вот реальный срез на момент написания статьи (цифры живые и меняются — актуальные всегда на самих страницах):

Такой срез показателен сам по себе: даже у гигантов Рунета «доступен» не значит «быстр» — разброс полной загрузки HTML между сайтами в этом срезе больше чем в 30 раз, и у каждого «тормоза» своя фаза-виновник. У одного время уходит в установку соединения, у другого — в медленный DNS, у третьего быстрые все фазы, кроме ответа самого сервера. Ровно такую диагностику по фазам стоит делать и для собственного сайта: она сразу говорит, куда смотреть — на DNS-хостинг, на сеть или на бэкенд.

Ориентиры: какое время ответа считать нормальным

Чтобы цифры из проверок было с чем сравнивать, полезна грубая шкала для полной загрузки HTML-документа (без картинок и скриптов) при проверке из того же региона, где живёт аудитория:

Оговорка про географию обязательна: те же 300 мс из Москвы легко превращаются в 400+ мс из Владивостока просто из-за расстояния — вспомните физический минимум ~64 мс на круговой путь пакета. Поэтому сравнивать своё время ответа нужно не с абстрактным идеалом, а по каждой точке проверки отдельно и в динамике: «во Владивостоке всегда было 400 мс, а сегодня стало 1 200» — сигнал, даже если 1 200 мс формально «терпимо».

Способ 5. Постоянный мониторинг из городов России

Все способы выше — разовые: они отвечают на вопрос «доступен ли сайт сейчас из этой точки». Систематический ответ даёт только внешний мониторинг с проверяющими серверами внутри страны: он опрашивает сайт по расписанию из многих городов сразу и присылает уведомление, когда сайт перестал отвечать хотя бы где-то. Время обнаружения инцидента при этом равно выбранному интервалу проверки: при интервале 2 минуты о падении вы узнаете максимум через 2 минуты, при 15 — через 15. Зачем проверять именно из нескольких городов, а не из одного, — отдельная статья; короткий ответ: блокировки и сбои операторов почти никогда не накрывают всю страну равномерно.

Особый случай: «то открывается, то нет»

Самые запутанные жалобы — плавающие: у одних открывается, у других нет, через час наоборот. За этим почти всегда стоит одна из трёх механик. Первая — DNS-кэширование: после смены записей старый адрес живёт в кэшах провайдеров до истечения TTL, то есть от минут до суток, и разные посетители честно ходят на разные серверы. Мы разбирали это подробно в статье про TTL в DNS. Вторая — частичная блокировка: ограничения применяются на уровне операторов и внедряются ими неравномерно, поэтому сайт может пропасть у абонентов одного оператора и оставаться доступным у другого. Третья — перегрузка: сервер отвечает, но не всем и не всегда, и разовая проверка ловит то удачный, то неудачный момент. Различить эти три случая разовыми проверками почти невозможно — здесь нужна именно история проверок из нескольких точек: по паттерну «где и когда не открывалось» диагноз читается за минуту.

Что проверять, кроме главной страницы

Типичная ошибка — проверять только главную. Она нередко закэширована CDN и «живёт» даже тогда, когда сайт по сути не работает. Минимальный осмысленный набор для бизнес-сайта — четыре-пять точек: главная, страница оформления заказа или форма заявки (то, что приносит деньги), вход в личный кабинет, API-эндпоинт, если на нём держится приложение, и SSL-сертификат домена. У интернет-магазина к списку добавляется товарный фид, у контентного проекта — robots.txt: их поломки не роняют сайт, но незаметно бьют по деньгам и трафику. Наборы под конкретные типы сайтов мы разбирали в чек-листах для магазина и SaaS.

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

Сайт открывается через VPN, но не открывается без него. Что это значит? Скорее всего, доступ к сайту ограничен именно на российском сегменте — блокировкой или гео-фильтром на стороне самого сайта либо его CDN. Проверьте статус домена в реестре блокировок и посмотрите на сайт из нескольких российских городов: картина «где открывается, где нет» сразу сузит диагноз.

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

Какой интервал проверки выбрать? Отталкивайтесь от цены минуты простоя: время обнаружения инцидента равно интервалу. Для страницы оформления заказа логичны минимальные 2 минуты, для блога или корпоративного сайта — 10–15.

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