Как проверить работоспособность сайта: чеклист за 15 минут

Сайт не открывается, в браузере ERR_* или белый экран, а клиенты уже пишут в мессенджер. За 10–15 минут вы отличите локальную проблему (кэш, DNS, Wi‑Fi) от реального даунтайма, снимете HTTP/SSL-статус с внешних точек и поймёте, звать ли хостинг или чистить кэш. Результат: вердикт "у всех или только у вас" и понятный следующий шаг без паники и без Zabbix.

Проверка работоспособности сайта – это triage, а не PageSpeed и не настройка мониторинга. Сначала инкогнито и мобильный интернет, затем две внешние точки (код или timeout), потом чтение 200/4xx/5xx и SSL. Для 1С-Битрикс: Управление сайтом штатная Проверка системы и Инспектор – только если админка доступна; они не заменяют внешний HTTP.

Речь про обычный сайт на своём хостинге, в том числе на CMS "1С-Битрикс: Управление сайтом". Это не CRM Bitrix24 и не статус чужого облака – смотрите свой домен.

Типичная история: владелец магазина с офисного Wi‑Fi не открывает витрину и звонит хостеру "сайт лежит". Хостер видит 200 OK – после переезда DNS ещё отдавал старый IP. На практике это типичная ошибка triage: путают локальный DNS с даунтаймом. Ниже алгоритм, который ловит такие ложные тревоги до звонка в поддержку.

Проверьте локально: у вас или у всех

Пока вы не исключили "только у меня", любая внешняя диагностика будет шуметь. Цель шага – за 2–3 минуты понять, жив ли доступ с вашей сети.

1. Откройте сайт в режиме инкогнито или в другом браузере – так вы обойдёте закэшированную ошибку.
2. Попробуйте мобильный интернет (раздайте с телефона) вместо офисного Wi‑Fi.
3. Откройте два-три чужих крупных сайта: если и они "легли", проблема в вашем канале, а не в витрине.
4. Запишите текст ошибки браузера (DNS_PROBE, ERR_CONNECTION_TIMED_OUT, сертификат) – это подсказка для следующего шага.
5. Если с мобильного интернет всё открывается, а с Wi‑Fi нет – не звоните хостеру с формулировкой "всё упало".

Делать: зафиксировать "локально / не локально" до любых сервисов. Не делать: чистить кэш хостинга и менять NS "на всякий случай", пока нет внешней точки.

Снимите статус с внешних точек онлайн

Внешняя проверка – запрос к сайту с чужого сервера. Так видно, открывается ли витрина из других сетей. Старт: Reg.ru, check-host, ping-admin.

1. Введите полный URL с https:// и запустите проверку минимум с двух локаций или сервисов.
2. Запишите HTTP-код ответа или timeout и IP, который видит сервис.
3. Сравните результат: везде 200, везде ошибка или "лоскутное" поведение по регионам.
4. Если нужен быстрый срез SSL/DNS без регистрации, можно заглянуть в публичные tools на проверку SSL и DNS dig.

Схема triage:
Локально (инкогнито / LTE) → 2 внешние точки (код / timeout) → чтение кода и SSL → DNS только если "у вас нет, снаружи есть" → CMS-инструменты Битрикс при доступной админке

Делать: сохранять скрин или текст результата (код + локация). Не делать: опираться на один сервис и один город – у провайдеров маршруты разные.

Прочитайте HTTP-код и отдельный сигнал SSL

HTTP-код – короткий ответ сервера на запрос страницы. По классам статуса RFC 9110 они такие: 2xx – успех, 3xx – редирект, 4xx – проблема доступа/запроса, 5xx – сбой на стороне сервера или шлюза. Пример: 502 Bad Gateway значит, что прокси (nginx, CDN) не получил нормальный ответ от бэкенда.

1. Откройте DevTools → Network и обновите страницу или выполните curl -I https://ваш-домен.ru и посмотрите первую строку ответа.
2. При 200 убедитесь, что это не "пустая" страница и не неожиданный редирект на заглушку; при 301/302 проверьте конечный URL.
3. При 403/401 не лечите "падение" – сначала доступ и WAF.
4. При 502/503 сразу смотрите хостинг, PHP-FPM, лимиты, апстрим – это классика "белый экран у nginx".

SSL – отдельная ветка: браузер ругается на сертификат, а HTTP может быть 200. Проверьте срок внешним инструментом. Истёкший SSL ≠ "сервер выключен", но для клиентов витрина "мертва".

Делать: писать в тикет код и время проверки. Не делать: считать 200 доказательством, что корзина жива – это только "сервер ответил".

Разберите DNS, если снаружи жив, а у вас нет

DNS – "телефонная книга": имя сайта → IP. Если после переезда у части провайдеров ещё старый адрес, получите сценарий из лида: у вас "лежит", у хостера 200.

1. Сверьте IP в whois/DNS-сервисе с IP, который называет хостинг.
2. Смените DNS на публичный (например 8.8.8.8 / 1.1.1.1) на тестовом устройстве и откройте сайт снова.
3. Сделайте flush DNS на рабочей станции (команда зависит от ОС) и повторите инкогнито.
4. Если снаружи тоже нет резолва или NS "битые" – тема уже у регистратора домена и хостинга, не в кэше браузера.

Делать: сравнивать IP "как видит мир" и "как видите вы". Не делать: менять NS и A-записи пачкой без фиксации текущего состояния – откат станет болью.

Откройте инструменты Битрикс только при доступной админке

Если внешний HTTP уже красный, штатные утилиты CMS не откроются – сначала поднимите доступ снаружи. Когда админка доступна, два инструмента полезны как снимок, не как замена triage.

Проверка системы (Настройки → Инструменты → Проверка системы) – разовый осмотр окружения: PHP, безопасность, почта, диск и другие группы. Документация: Проверка системы. Это не uptime: зелёный отчёт сегодня не гарантирует ночной алерт.

Инспектор сайтов (Настройки → Облако 1С-Битрикс → Инспектор сайтов) смотрит доступность, домен, SSL и лицензию. Сайт должен быть доступен снаружи, домен в списке сайтов – корректный. Справка: Инспектор сайтов.

1. Сначала закройте внешний triage (шаги выше).
2. Если админка открывается – прогоните Проверку системы и сохраните красные пункты.
3. Сверьте Инспектор: нет ли предупреждений по SSL/домену при живом HTTP.
4. Не путайте "внутри зелёный" с "снаружи 502" – приоритет у внешней точки.

Делать: использовать CMS-проверки как второй слой. Не делать: начинать диагностику падения с site_checker, когда главная не отвечает с улицы.

Решите: разовый сбой закрыт или нужен мониторинг

Разовая проверка отвечает "что сейчас". Мониторинг – "узнаю ли раньше клиента". Если сбой закрыт – зафиксируйте причину. Если звонки повторяются – нужен круглосуточный контроль.

Мост без дубля setup: HTTP раз в 5–15 минут + SSL + один канал алертов. Разбор для Битрикс – в гайде как настроить мониторинг сайта на Битрикс. Старт кабинета – создать аккаунт BX Pulse.

Делать: после triage явно выбрать "разово закрыли" или "ставим мониторинг". Не делать: собирать Zabbix из-за одного ложного DNS_PROBE.

Соберите чеклист на 10–15 минут

• Инкогнито + другой браузер + LTE vs Wi‑Fi.
• Чужие сайты открываются? Ошибка браузера записана.
• Две внешние точки: код или timeout, время, IP.
• Прочитан смысл кода (200/3xx/4xx/5xx) и отдельно SSL.
• При "только у меня" – сверка DNS/IP, не тикет "всё лежит".
• При доступной админке Битрикс – Проверка системы / Инспектор как снимок.
• Вердикт: локально / везде / лоскутно + следующий шаг (кэш, хостинг, SSL, мониторинг).

Делать: пройти список сверху вниз без прыжков. Не делать: смешивать скорость загрузки, SEO и битые ссылки в эту же сессию – сейчас нужен ответ "упал ли сайт".

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, инженер по эксплуатации 1С-Битрикс.
Источники: RFC 9110 status codes, check-host HTTP, Reg.ru check_site, Проверка системы, Инспектор сайтов.