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

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

Надёжная проверка идёт слоями: DNS → соединение → TLS → HTTP → содержимое/функция. Это позволяет не только ответить «работает или нет», но и сразу сузить область поиска причины.

Быстрый ответ за минуту

Начните с трёх проверок:

curl -I https://example.com/

curl -sS -o /dev/null \
  -w 'code=%{http_code} total=%{time_total}s\n' \
  https://example.com/

и откройте тот же URL из другой независимой сети, например мобильной.

Если обе сети получают нормальный HTTP-ответ, а проблема остаётся только на одном устройстве, вероятна локальная причина. Если ошибки воспроизводятся независимо — исследуйте инфраструктуру сайта.

Что значит «сайт работает»

Сначала определите критерий.

Для информационного сайта это может быть:

HTTPS устанавливается
AND GET / возвращает 200
AND время ответа приемлемо

Для SaaS этого мало:

главная → 200
/login → 200
критичный API → ожидаемый ответ

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

Шаг 1. Исключите локальную проблему

Проверьте:

1. приватное окно браузера;
2. другой браузер;
3. другое устройство;
4. другую сеть;
5. прямой запрос через curl.

Не делайте вывод «сайт лежит» только по одному браузеру. Кеш, расширение, VPN или локальный DNS способны дать отдельный сбой.

Шаг 2. Проверьте DNS

dig example.com

или:

nslookup example.com

Нужно понять:

• есть ли DNS-ответ;
• какой IP возвращается;
• соответствует ли он ожидаемой инфраструктуре.

Если DNS не разрешается, до HTTP-проверки дело не дойдёт.

При недавнем изменении DNS разные resolver могут временно видеть разные значения в рамках TTL и кеширования.

Шаг 3. Проверьте HTTPS и TLS

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null

-servername передаёт SNI, что важно для хостинга нескольких доменов на одном IP.

Если TCP/TLS не устанавливается, curl не сможет получить обычный HTTP-код.

Для срока сертификата есть отдельный материал: как узнать срок действия SSL-сертификата.

Шаг 4. Получите реальный HTTP-код

curl -i https://example.com/

или компактно:

curl -sS -o /dev/null \
  -w '%{http_code}\n' \
  https://example.com/

Интерпретация зависит от URL:

• 200 — HTTP-запрос успешно обработан;
• 301/302/307/308 — redirect, нужно понять, ожидаем ли он;
• 401/403 — ограничение доступа;
• 404 — ресурс не найден;
• 5xx — server-side/gateway failure.

Сам по себе 200 ещё не доказывает исправность приложения.

Шаг 5. Проверьте redirect без маскировки

Сначала:

curl -i http://example.com/

Посмотрите Location.

Затем при необходимости:

curl -iL http://example.com/

-L следует перенаправлениям. Если сразу использовать только -L, можно не заметить неправильную промежуточную цепочку.

Шаг 6. Измерьте время ответа

curl -sS -o /dev/null \
  -w 'code=%{http_code} total=%{time_total}s\n' \
  https://example.com/

Сайт может формально отвечать, но делать это настолько медленно, что пользователи воспринимают его как недоступный.

Не существует одного универсального порога «нормально» для всех сайтов. Сравнивайте с собственной базовой линией и требованиями критичного сценария.

Шаг 7. Проверьте несколько URL

for url in \
  'https://example.com/' \
  'https://example.com/login' \
  'https://example.com/api/health'
do
  curl -sS -o /dev/null \
    -w "$url -> %{http_code} %{time_total}s\n" \
    "$url"
done

Если главная 200, а login/API 500, сайт не «полностью здоров» — это частичный downtime.

Подробнее: что такое downtime сайта.

Шаг 8. Сравните внешнюю и внутреннюю проверку

Внутри сервера приложение может отвечать:

curl -i http://127.0.0.1:8080/health

но публичный URL быть недоступным из-за DNS, firewall, load balancer, TLS или reverse proxy.

локальный health → 200
публичный HTTPS → ошибка

означает, что проверять нужно путь между пользователем и приложением, а не только процесс приложения.

Если сайт работает у вас, но не у других

Проверьте:

• DNS из разных resolver;
• IPv4/IPv6;
• географические/CDN правила;
• WAF/IP blocks;
• разные сети;
• сертификат и SNI;
• кеш CDN;
• конкретные ISP routes.

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

Если сайт не работает только у вас

Наиболее полезная последовательность:

1. открыть через мобильную сеть;
2. проверить DNS;
3. отключить локальный proxy/VPN только для диагностики;
4. проверить curl;
5. проверить другой DNS resolver;
6. сравнить IP.

Не меняйте DNS или сетевые настройки без необходимости, если проблема уже локализована в браузере.

Ping — недостаточная проверка

Возможны оба сценария:

ping → OK
HTTPS → FAIL

и:

ping → FAIL
HTTPS → 200

ICMP и HTTPS — разные протоколы и разные политики firewall. Для сайта важнее реальный HTTP/HTTPS-запрос.

Как понять, что сайт восстановился

Один 200 после сбоя недостаточен. Сделайте серию:

for i in {1..20}; do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_total}\n' \
    https://example.com/
  sleep 2
done

Проверьте также ключевые URL. Если ответы чередуются, возможно, одна replica за load balancer всё ещё неисправна.

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

Ручная проверка отвечает только на вопрос «что происходит в эту секунду». Она не показывает:

• когда начался сбой;
• сколько он длился;
• были ли короткие падения ночью;
• насколько часто повторяется проблема.

Для этого нужна регулярная внешняя проверка с историей результатов.

UpWatch можно использовать для автоматической проверки публичных HTTP/HTTPS URL. Мониторинг не заменяет server logs, но помогает быстро зафиксировать внешний факт недоступности и момент восстановления.

Типичные ошибки

Проверять только главную

Она может быть закеширована, пока API или checkout уже не работают.

Делать вывод по ping

ICMP не проверяет веб-приложение.

Считать любой redirect ошибкой

HTTP→HTTPS redirect может быть полностью ожидаемым.

Считать один успешный запрос восстановлением

При нескольких backend проблема может проявляться через запрос.

Проверять только изнутри сервера

Пользовательский путь включает DNS, сеть, TLS и proxy.

Практический чек-лист

1. Определить, какой URL/функция должна работать.
2. Проверить из другой сети.
3. Проверить DNS.
4. Проверить TLS/SNI.
5. Получить HTTP-код через curl.
6. Проверить redirect.
7. Измерить время ответа.
8. Проверить несколько критичных URL.
9. Сравнить внешний URL и upstream.
10. После исправления подтвердить восстановление серией запросов.
11. Для постоянного контроля настроить автоматический мониторинг.

Источники и документация

• curl: официальная документация
• OpenSSL s_client