Готовые сервисы проверки доступности: когда одного ping уже мало
Чрезмерная временная фильтрация шагает по стране семимильными шагами. Где-то на время включают белые списки, где-то выборочно перестают ходить отдельные протоколы, адреса, CDN или целые сети. Добавим к этому обычные аварии, ошибки DNS, неудачную маршрутизацию и бодрый антибот на стороне самого сайта — и получим современное «интернет вроде есть, но ничего не понятно».
Поэтому мы тоже понемногу вооружаемся диагностическими сервисами.
Сразу оговорюсь: это не рейтинг и не реклама. Инструменты решают разные задачи и хорошо дополняют друг друга. Одни смотрят на ресурс снаружи, другие проверяют его именно через проблемное подключение, третьи запоминают, когда и на сколько минут всё падало.
Почему ping уже недостаточно
Ping проверяет ICMP: дошёл ли специальный пакет до узла и вернулся ли ответ. Это полезно, но к открытию сайта относится довольно косвенно.
Возможны оба варианта:
— ping проходит, а HTTPS не работает из-за TLS, SNI, фильтрации порта, ошибки веб-сервера или недоступного CDN; — ping не проходит, потому что ICMP отключён или ограничен, а сайт при этом прекрасно открывается.
Иными словами, ping честно сообщает: «узел ответил на мой ICMP-запрос». Пользователь же в этот момент пытался открыть личный кабинет, посмотреть видео или получить ответ от API. Это уже совсем другой разговор.
Для сайта полезнее смотреть хотя бы всю цепочку:
- разрешилось ли доменное имя;
- установилось ли TCP-соединение;
- прошёл ли TLS для HTTPS;
- какой HTTP-код вернул сервер;
- пришёл ли ожидаемый контент;
- одинаков ли результат из разных сетей и регионов.
Ping-Admin: подробный внешний замер
Ping-Admin пригодится, когда нужно быстро посмотреть на сайт из большого числа внешних точек. Можно выбрать случайные узлы, отдельно российские точки или более широкий набор по разным странам.
Это именно HTTP/HTTPS-проверка, а не просто красивый список задержек. В результате по каждой точке видны:
— IP-адрес, в который разрешилось имя; — полное время загрузки; — время DNS; — установка соединения; — TLS/SSL; — ожидание ответа сервера; — редиректы; — скорость загрузки и размер страницы.
Такой разбор помогает отличить «долго думает сам сервер» от «долго устанавливается соединение» и «в одном регионе домен вообще указывает в другую сторону». Последнее нормально для CDN и Anycast, но иногда именно в различиях между точками и прячется проблема.
Особенно полезен большой набор российских узлов. Если из части городов страница открывается, а из части стабильно нет, это уже намного интереснее, чем один ping с рабочего ноутбука.
Минус очевиден: Ping-Admin проверяет сайт со своих серверов. Он ничего не знает о конкретном домашнем роутере, корпоративном DNS, Wi‑Fi, канале последней мили и маршруте проблемного пользователя. Это внешний свидетель, а не очевидец с места происшествия.
Check-Host: быстрый ответ «а снаружи как?»
Check-Host я обычно воспринимаю как быстрый мультитул. У него отдельно доступны проверки:
— HTTP/HTTPS, в том числе на нестандартном порту; — ping; — TCP-порта; — UDP-порта; — DNS.
Для первичной проверки это удобно: вставили точный URL, выбрали HTTP и через несколько секунд получили ответы из разных стран. Затем тем же ресурсом можно отдельно посмотреть TCP-порт или DNS, если HTTP-проверка показала что-то странное.
По глубине HTTP-разбора Ping-Admin интереснее, зато Check-Host быстрее отвечает на практический вопрос: ресурс не виден вообще, не виден только по HTTP/HTTPS или проблема наблюдается лишь с отдельных точек.
Есть и важная тонкость: проверять надо не только домен, но и тот протокол, которым реально пользуется клиент. Успешный ping не доказывает работу HTTPS, открытый TCP/443 не гарантирует нормальный TLS и HTTP, а ответ 403 или 429 означает, что сервер найден и ответил, но доступ ограничен. Для пользователя сайт всё равно может быть непригоден — просто причина уже не похожа на обрыв маршрута.
connect-check: проверка с места происшествия
После истории «Две недели без интернета» у нас появилась собственная утилита connect-check.
Она отвечает на другой вопрос: не «виден ли сайт из чужого дата-центра», а «что именно работает и не работает с этого компьютера через это подключение».
Утилита запускается локально на Windows, macOS или Linux. Готовые сборки лежат в разделе Releases, исходники открыты. В актуальном пакете диагностика и отдельные пробы встроены в GUI.
Полный прогон проверяет не один адрес, а целый набор классов ресурсов и протоколов: базовую сеть, DNS, captive portal, время, HTTP/HTTPS, TCP, CDN, значимые российские и зарубежные ресурсы, банки, почту, облака, репозитории обновлений, игры, видео, IoT и AI-сервисы. Для некоторых сайтов проверяется не только главная страница, но и API, CDN или статический файл — потому что витрина с антиботом и реальный клиентский трафик могут вести себя совершенно по-разному.
Если проверка ресурса провалилась, в отчёт добавляются ping и traceroute. Результат можно сохранить в HTML и отправить провайдеру или коллеге. Это уже существенно полезнее сообщения «у меня не работает интернет».
Отдельная URL-проба умеет повторять HTTP/HTTPS-запросы с заданным интервалом и числом раундов. Она показывает время, HTTP-код, разрешившийся IP, редирект и итоговый URL. Такой режим хорошо ловит плавающую проблему: пять запросов прошли, шестой завис, ещё два получили редирект куда-то не туда.
Но и connect-check не является абсолютным арбитром. Он показывает взгляд конкретного устройства и конкретного подключения. В этом и его достоинство, и ограничение. Если нужно понять географию проблемы, результат надо сравнить с Ping-Admin или Check-Host.
Uptime Kuma: не проверить сейчас, а следить постоянно
Uptime Kuma — self-hosted-мониторинг, который удобно поднять в Docker на своей ВМ или небольшом VPS.
Он умеет постоянно проверять HTTP/HTTPS, TCP, ping, DNS, WebSocket, push-мониторы и некоторые другие типы целей. Для веб-сервисов особенно полезны проверки по ключевой строке или JSON-запросу: обычный HTTP 200 OK ещё не означает, что приложение действительно отдало нужную страницу, а не вежливую заглушку «всё сломалось».
У Kuma есть история доступности, графики, контроль сертификатов, публичные статус-страницы и уведомления через Telegram, почту и множество других каналов. Минимальный интервал проверки, указанный в проекте, — 20 секунд.
Главное — правильно выбрать место установки. Kuma рядом с наблюдаемым сервером хорошо замечает падение приложения, но может не увидеть региональную или операторскую фильтрацию: внутри одного дата-центра всё будет зелёным. Экземпляр на внешнем VPS лучше показывает доступность снаружи. А если важен взгляд конкретного офиса, монитор надо ставить внутри этого офиса.
Одна точка наблюдения всегда остаётся одной точкой наблюдения. Даже если у неё очень красивый зелёный интерфейс.
Как использовать всё это вместе
Нормальная последовательность при жалобе «сайт не работает» выглядит примерно так.
1. Проверяем точный URL по HTTP/HTTPS
Начинаем с Check-Host. Вставляем именно тот адрес, который не открывается, включая https://, путь и нестандартный порт, если он есть. Смотрим, отвечает ли ресурс из разных стран.
2. Если проблема неоднородная — идём в Ping-Admin
Запускаем подробную проверку из нескольких российских и зарубежных точек. Сравниваем DNS, IP, соединение, TLS, ожидание сервера и редиректы.
3. Запускаем connect-check на проблемном подключении
Теперь получаем взгляд изнутри: как работает DNS, открываются ли соседние классы ресурсов, не сломаны ли только HTTPS, CDN, обновления, видео или отдельные сети. Сохраняем HTML-отчёт.
Если проблема плавающая, оставляем URL-пробу на несколько раундов. Это часто продуктивнее, чем двадцать раз вручную обновлять браузер и пытаться понять, показалось или нет.
4. Для важных сервисов включаем Uptime Kuma
Добавляем постоянную HTTP/HTTPS-проверку. Где возможно — проверяем не только код ответа, но и ключевую строку или JSON. Настраиваем уведомления и сохраняем историю.
Монитор лучше размещать не на том же сервере, который он наблюдает. Иначе при общей аварии они могут исчезнуть вместе, сохранив удивительное единодушие.
Короткая шпаргалка
| Вопрос | Что взять |
|---|---|
| Сайт прямо сейчас виден из разных городов и стран? | Check-Host или Ping-Admin |
| Где тратится время: DNS, соединение, TLS или ответ сервера? | Ping-Admin |
| Открыт ли конкретный TCP/UDP-порт? | Check-Host |
| Почему сервис не работает именно у этого пользователя? | connect-check на его подключении |
| Нужно поймать плавающие HTTP/HTTPS-сбои локально? | URL-проба connect-check |
| Когда сервис упал и сколько был недоступен? | Uptime Kuma |
| Нужны уведомления и история? | Uptime Kuma |
| Нужен внятный материал для обращения к провайдеру? | connect-check + внешняя проверка Ping-Admin/Check-Host |
На что не наступить
Во-первых, не вставляйте во внешние сервисы приватные URL с токенами, одноразовыми подписями, адресами внутренних панелей и другими секретами. Проверка выполняется чужой инфраструктурой, и введённый адрес перестаёт быть только вашим.
Во-вторых, не делайте вывод по одной красной точке. Проверочный узел тоже может быть перегружен, временно потерять маршрут или попасть под ограничение самого сайта.
В-третьих, браузер и HTTP-проба — не одно и то же. JavaScript, авторизация, антибот, API и загрузка статических файлов могут ломаться независимо. Иногда 403 означает «сервер жив, но нас не пустили», а 200 — «заглушка успешно загружена».
И наконец, сохраняйте время проверки, адрес, IP, выбранные узлы и результаты. Фраза «13 августа с 10:15 до 10:27 HTTPS не устанавливался через такого-то провайдера, при этом из шести внешних точек работал» сильно полезнее бессмертного «у вас интернет сломался».
Получается не один идеальный сервис, а небольшой набор инструментов:
— Check-Host быстро подтверждает внешний симптом; — Ping-Admin раскладывает HTTP/HTTPS по этапам и географии; — connect-check показывает картину с проблемного подключения; — Uptime Kuma следит за сервисом постоянно и помнит историю.
В эпоху, когда интернет всё чаще ломается не целиком, а художественно и выборочно, такая коллекция отвёрток уже не выглядит избыточной.
Ссылки
— Ping-Admin: разовая проверка доступности
— Check-Host: HTTP/HTTPS-проверка