Я сделал Gitae, потому что слишком часто сталкивался с одним и тем же практическим вопросом: сайт действительно лежит или проблема только на моей стороне?
Одна вкладка браузера — плохой диагностический инструмент. Страница может не открываться потому, что упал origin-сервер, но причиной также могут быть DNS, проблема с HTTPS-сертификатом, маршрутизация, firewall-правило, закрытый или фильтруемый порт, сбой у провайдера, маршрут через VPN, состояние браузера или локальный кэш. Симптом один и тот же: сайт не загружается. А действия нужны совершенно разные.
Именно эту проблему я хотел решить в Gitae. Не просто показать зелёный или красный индикатор, а помочь сузить поиск до конкретного слоя, который имеет смысл проверять дальше.
Какую проблему я на самом деле хотел решить
Большинство простых website checker-инструментов отвечают на очень узкий вопрос: вернул ли конкретный URL ответ из одной точки в один момент времени? Это полезно, но это ещё не диагностика сбоя.
Если сломан DNS, перезапуск приложения ничего не исправит. Если HTTPS не работает из-за сертификата, содержимое страницы здесь ни при чём. Если TCP-порт недоступен, сам сервер при этом может продолжать работать. Если сайт открывается с внешнего сервера, но не открывается у меня, проблема может находиться где-то между моей сетью и целевым хостом, а не в приложении.
Поэтому я строил Gitae вокруг более полезной модели: сайт — это цепочка зависимостей, а каждая проверка даёт данные только об одной части этой цепочки.
Внешний взгляд, а не абсолютная истина
Проверки Gitae запускаются с моих собственных VDS-серверов в Москве и Хельсинки. Это важно, потому что я получаю точки наблюдения вне того компьютера и сети, где впервые заметил проблему.
Если сайт не открывается локально, но отвечает с обеих VDS-точек, это полезный сигнал: origin как минимум не недоступен для всех. Тогда я внимательнее смотрю в сторону локального DNS, маршрута провайдера, VPN, состояния браузера, firewall или другой проблемы, зависящей от конкретного сетевого пути. Если сайт не отвечает и с удалённых точек, основания проверять серверную часть, DNS, сертификат, маршрутизацию или более широкий сетевой сбой становятся сильнее.
Но удалённые проверки сами по себе не «надёжнее локальных», а две VDS-точки не представляют весь интернет. Сайт может нормально открываться из Москвы и Хельсинки и одновременно быть недоступным из другой страны, у другого провайдера, на другом CDN edge или в другой сети. Я воспринимаю удалённый результат как дополнительную точку наблюдения, а не как глобальный вердикт.
Что Gitae проверяет сейчас
Текущая версия объединяет инструменты, которые мне обычно нужны, когда я пытаюсь понять, на каком уровне возник сбой:
- Website check — проверяет, отвечает ли URL с внешнего сервера.
- SSL check — проверяет состояние HTTPS/TLS-сертификата и связанные с сертификатом проблемы.
- DNS check, nslookup и dig — помогают увидеть, как резолвится домен и какие DNS-записи возвращаются.
- Reverse DNS и IP check — показывают IP-информацию и PTR/reverse-DNS данные.
- Domain info и domain age — дают базовую информацию о домене.
- Port check — проверяет доступность нужного порта из точки, откуда выполняется тест.
- Find your IP — показывает публичный IP, который видит сервис.
- Ping и traceroute — дают сетевые сигналы о задержке, потерях пакетов и пути до хоста.
- Hosting check и CMS detection — показывают инфраструктурные и технологические признаки, которые могут помочь с идентификацией.
Я специально воспринимаю всё это именно как сигналы. Часть результатов — прямые наблюдения, часть — выводы по доступным признакам. PTR-запись не доказывает владельца сервера. CMS detection по публичным отпечаткам не доказывает точный стек. Порт, недоступный из одной точки, может фильтроваться, а не быть закрытым для всех.
Как я интерпретирую результаты
Польза появляется, когда несколько проверок рассматриваются вместе, а не каждая сама по себе.
Например, если DNS возвращает ожидаемый адрес, HTTPS-сертификат валиден и сайт отвечает с обеих внешних VDS-точек, но у меня локально всё ещё не открывается, я прежде всего глубже проверю локальный путь и только потом полезу менять сервер. В обратной ситуации, когда DNS ведёт себя нестабильно или удалённая проверка сайта тоже падает, причин разбирать инфраструктуру становится больше.
С ping и traceroute тоже нужна осторожность. ICMP может фильтроваться или ограничиваться по частоте. Пропавший hop в traceroute ещё не означает, что этот узел сломан, а хост, который не отвечает на ping, вполне может нормально отдавать HTTPS. Эти инструменты полезны потому, что добавляют контекст, а не потому, что дают один окончательный диагноз.
Главный инженерный принцип Gitae для меня такой: одна успешная проверка не доказывает здоровье всей системы, а одна неудачная проверка сама по себе не объясняет причину.
Почему доступность важна для SEO
Мне важна и SEO-сторона, но здесь особенно легко сделать слишком сильный вывод. Технический простой — не то же самое, что проблема с ранжированием. Crawling — не indexing, а indexing — не traffic.
Корректно говорить так: если crawler не может получить сайт из-за DNS-, сетевой или серверной ошибки, в этот момент он не может успешно загрузить затронутый контент. Google прямо пишет, что сетевые и DNS-ошибки при обходе обрабатываются аналогично серверным ошибкам 5xx, а длительная недоступность может повлиять на обход и уже проиндексированные URL. Это не означает, что каждый короткий сбой обязательно приводит к SEO-потерям, и диагностический инструмент не может доказать, что наблюдаемое изменение трафика было вызвано именно простоем.
Для пользователей всё проще: если они не могут открыть сайт, они не могут им пользоваться. В зависимости от проекта это может означать потерянные сессии, заявки, конверсии или выручку. Но и здесь диагностика фиксирует технический симптом, а не считает бизнес-ущерб.
Практический порядок диагностики «лежащего» сайта
От инструмента вроде Gitae мне нужен примерно такой рабочий порядок:
- Подтвердить симптом из другой сети. Проверить URL с внешней точки, а не считать локальный браузер представителем всего интернета.
- Проверить DNS. Убедиться, что домен резолвится и возвращаются ожидаемые записи.
- Проверить HTTPS/TLS. Посмотреть на валидность сертификата и ошибки соединения.
- Проверить нужный порт. Убедиться в его доступности хотя бы из тестовой точки.
- Сравнить сетевые сигналы. Использовать ping и traceroute как вспомогательные данные, а не как бинарный тест здоровья.
- Посмотреть IP, reverse DNS, hosting и CMS-сигналы. Они помогают проверить, что трафик вообще приходит туда, куда вы ожидаете.
- Только после этого сужать область поиска. Решить, куда сильнее указывают данные: приложение, сервер, DNS, сетевой путь или локальная среда.
Это не обязательный протокол и не универсальная инструкция для каждого инцидента. Для меня это способ не повторять ту ошибку, от которой я и хотел уйти: менять не тот слой только потому, что единственная исходная информация звучит как «сайт не открывается».
Сначала реальная польза, потом монетизация
Сейчас Gitae не монетизируется. Я сделал его в первую очередь для себя: мне нужен был быстрый способ проверить сайт извне и сразу перейти к DNS, сертификату, портам и сетевой диагностике, а не прыгать между несвязанными сервисами.
Текущая цель — сделать диагностику полезнее и посмотреть, сможет ли проект получать органический трафик через SEO и реальный спрос. Если он наберёт хотя бы умеренный трафик, я хочу добавить автоматический мониторинг сайтов с мгновенными уведомлениями в мессенджеры. Это продолжение той же идеи: сначала заметить недоступность, затем быстро дать владельцу достаточно данных, чтобы начать расследование.
Что я хочу оставить простым
Главная идея проекта не изменилась. «Работает» и «не работает» — это симптомы, а не объяснения.
DNS, HTTPS/TLS, маршрутизация, порты, хостинг, приложение и сеть самого пользователя могут влиять на то, что выглядит как обычная проблема доступности. Gitae не определяет магически любую root cause, а эти внешние VDS-точки не могут показать, что видит весь интернет. Зато инструмент может собрать в одном месте несколько независимых сигналов.
Именно такой инструмент я хотел для себя: не тот, который просто сообщает «сайт не открывается», а тот, который помогает перейти к гораздо более полезному вопросу: «какой слой мне проверять следующим?»