Почему сайт не открывается: полный алгоритм диагностики

Если сайт не открывается, первая задача — определить на каком уровне ломается путь от пользователя до приложения, а не перезапускать всё подряд. Один и тот же симптом браузера может быть вызван DNS, сетью, TLS, redirect, CDN, reverse proxy, приложением или конкретной бизнес-функцией.

Практичный порядок: клиент → DNS → TCP → TLS → HTTP → proxy/CDN → приложение → критичный сценарий.

Сначала определите симптом

Зафиксируйте, что именно происходит:

• DNS error;
• connection refused;
• timeout;
• TLS/certificate error;
• redirect loop;
• HTTP 4xx/5xx;
• белая страница;
• сайт открыт, но login/API/checkout не работает;
• проблема только у части пользователей.

Без этого легко исследовать Nginx, когда проблема в DNS, или DNS, когда сервер стабильно возвращает 500.

Шаг 1. Проверьте из другой сети

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

Если проблема только на одном устройстве, исследуйте локальные cookies, VPN/proxy, расширения, resolver и сеть.

Связанный материал: как проверить, работает ли сайт прямо сейчас.

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

dig example.com

или:

nslookup example.com

Проверьте наличие ответа, A/AAAA адреса и соответствие ожидаемой инфраструктуре.

Для сравнения resolver:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Различие ответов помогает увидеть DNS-кеш/распространение, но не доказывает глобальную проблему само по себе.

Шаг 3. Отделите DNS от HTTP через curl --resolve

Если известен правильный IP:

curl -i \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

--resolve сохраняет hostname в URL и для TLS/SNI, но соединяется с указанным IP.

Шаг 4. Проверьте TLS

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

-servername передаёт SNI. Если TLS не устанавливается, HTTP application ещё не получило нормальный HTTPS request.

Не используйте curl -k как исправление: он отключает certificate verification.

Шаг 5. Получите HTTP status

curl -i https://example.com/

или:

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

Если сервер возвращает HTTP status, путь DNS/TCP/TLS уже прошёл достаточно далеко для HTTP response.

Шаг 6. Проверьте redirect

Сначала:

curl -i http://example.com/

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

curl -iL http://example.com/

При redirect loop исследуйте переходы HTTP/HTTPS, www/non-www, CDN и application.

Шаг 7. Измерьте этапы запроса

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

Большой time_namelookup указывает на DNS-направление; time_connect — сеть/TCP; time_appconnect — TLS; задержка до time_starttransfer — server/proxy/application processing.

Шаг 8. Локализуйте слой

DNS отвечает?
 ├─ нет → DNS/resolver
 └─ да
    TCP:443 есть?
     ├─ нет → routing/firewall/load balancer
     └─ да
        TLS проходит?
         ├─ нет → certificate/SNI/TLS
         └─ да
            HTTP code?
             ├─ 4xx → request/access/routing
             ├─ 5xx → proxy/application/dependency
             └─ 2xx/3xx → контент/функция

Шаг 9. Если ответ 502/503/504

• 502 — proxy получил некорректный upstream response;
• 503 — сервис временно не готов;
• 504 — gateway не дождался upstream.

Связанные материалы: 502, 503, 504.

Шаг 10. Сравните public URL и upstream

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

Если local upstream работает, а public HTTPS нет, проблема находится между пользователем и приложением. Но простой /health не доказывает работоспособность бизнес-функции.

Шаг 11. Проверьте несколько 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

Главная может быть закеширована, пока динамический endpoint уже не работает.

Сайт работает по IP, но не по домену

Прямой IP-тест не воспроизводит hostname/SNI/virtual host. Используйте --resolve, если хотите корректно отделить DNS от HTTPS.

Сайт работает по HTTP, но не по HTTPS

Проверьте listener 443, certificate, SNI, TLS, CDN certificate, origin certificate и redirect HTTP→HTTPS.

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

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

Сравните DNS, IPv4/IPv6, CDN edge, WAF/IP policy, ISP route и certificate chain. Один успешный запрос не доказывает внешнюю доступность.

Сайт не открывается после релиза

Проверьте app readiness, port/listener, upstream, environment, migrations, TLS, health endpoint и logs по времени первого failure.

Если deployment явно вызвал массовый сбой и существует проверенная rollback-процедура, rollback может быть правильным действием, но причину всё равно нужно зафиксировать.

Как работать с логами

время внешнего failure
→ proxy/access log
→ request ID
→ application log
→ dependency log/metric

Сначала сузьте время и URL, потом читайте логи.

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

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

При load balancer один success может попасть на здоровый backend, пока другой ещё неисправен.

Почему нужен внешний мониторинг

Ручная проверка не показывает, когда произошёл ночной сбой и как часто он повторяется. UpWatch можно использовать для регулярных внешних HTTP/HTTPS-проверок критичных URL и фиксации времени failure/recovery.

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

• сразу перезапускать сервер;
• проверять только ping;
• использовать curl -k как решение;
• проверять только /;
• менять DNS до локализации;
• считать один 200 доказательством восстановления.

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

1. Зафиксировать симптом и URL.
2. Проверить из другой сети.
3. Проверить DNS.
4. При необходимости использовать --resolve.
5. Проверить TLS.
6. Получить HTTP status.
7. Проверить redirect.
8. Снять timings.
9. Локализовать слой.
10. Сравнить public URL/upstream.
11. Проверить критичные URL.
12. Сопоставить с logs/deployment.
13. Подтвердить recovery серией.
14. Настроить внешний контроль.

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

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