Не открывается сайт: пошаговая диагностика для обычного пользователя и владельца

Когда не открывается сайт, первая реакция обычно одна: обновить страницу и решить, что «интернет сломался». Но причин десятки: от сбоя Wi‑Fi и кэша браузера до истёкшего SSL-сертификата, ошибки DNS, перегруженного сервера или блокировки на уровне провайдера.

Хорошая диагностика начинается не с перезагрузки сервера, а с простого вопроса: сайт не открывается только у вас или у всех? Ответ сразу сужает круг поиска. Обычному пользователю он помогает понять, можно ли что-то исправить на своём устройстве. Владельцу сайта — определить, где искать проблему: в домене, хостинге, приложении, прокси, CDN или сетевой инфраструктуре.

Ниже — пошаговый разбор без лишней теории: сначала быстрые действия для пользователя, затем более техническая диагностика для владельца сайта и команды поддержки.

Сначала определите: проблема у вас или на стороне сайта

Самая частая ошибка — сразу лезть в настройки сервера, не проверив, воспроизводится ли сбой из других сетей. Один и тот же симптом «не открывается сайт» может означать совершенно разные вещи.

1) Проверьте сайт с другого устройства — откройте его на телефоне, ноутбуке, планшете. Если на компьютере сайт не открывается, а на телефоне через мобильный интернет работает, дело скорее всего в вашей локальной сети, DNS-настройках, браузере или провайдере.

2) Смените сеть — отключите Wi‑Fi на телефоне и попробуйте открыть сайт через мобильный интернет, или наоборот подключитесь к другому Wi‑Fi. Так легко отделить проблему сайта от проблемы конкретного подключения.

3) Откройте сайт в другом браузере — Chrome, Firefox, Safari, Edge по-разному работают с кэшем, расширениями, сертификатами и политиками безопасности. Если в одном браузере сайт открывается, а в другом нет, сервер почти наверняка жив.

4) Проверьте через внешний сервис — сервисы проверки доступности показывают, открывается ли сайт из разных регионов. Владельцу сайта пригодится постоянный мониторинг: например, Statuser проверяет сайт с заданным интервалом и уведомляет, если он перестал отвечать, — это быстрее, чем ждать жалоб пользователей.

5) Зафиксируйте точный симптом — «не открывается» слишком общее описание. Запишите, что именно видно: белый экран, бесконечная загрузка, 404, 500, 502, ERR_NAME_NOT_RESOLVED, предупреждение о сертификате, редирект на другую страницу. Это главный ориентир для дальнейшей диагностики.

Если сайт не открывается только у вас, начинайте с клиентской части. Если не открывается из разных сетей и у разных людей — переходите к проверке домена, сервера и приложения.

Что сделать обычному пользователю

Если вы не владелец сайта и не управляете сервером, ваши возможности ограничены, но базовые действия часто решают проблему.

1) Обновите страницу без кэша — нажмите Ctrl+F5 или Cmd+Shift+R на macOS. Обычное обновление берёт файлы из кэша, а принудительное заставляет браузер запросить страницу заново.

2) Очистите кэш и cookies для сайта — особенно если у других сайт открывается, а у вас показывает ошибку входа, бесконечный редирект или старую версию страницы. Чистить весь браузер не обязательно: можно удалить данные только для конкретного домена.

3) Отключите расширения — блокировщики рекламы, VPN-плагины, антивирусные расширения и инструменты приватности иногда ломают загрузку скриптов, авторизацию или соединение с API. Проверьте в режиме инкогнито: там многие расширения отключены по умолчанию.

4) Отключите VPN или прокси — некоторые сайты блокируют трафик из дата-центров, зарубежных IP или известных VPN-сетей. Бывает и наоборот: без VPN сайт недоступен из-за маршрутизации или блокировки, а с VPN открывается. Сравните оба варианта.

5) Перезагрузите роутер и устройство — банально, но помогает при зависшем DNS-кэше, проблемах DHCP, нестабильном Wi‑Fi и временных сбоях домашнего маршрутизатора.

6) Смените DNS-сервер — если браузер пишет, что домен не найден, попробуйте публичные DNS: 1.1.1.1, 8.8.8.8, 77.88.8.8. После смены перезапустите браузер или устройство.

7) Проверьте дату и время — неправильная дата приводит к ошибкам HTTPS: браузер может посчитать сертификат «ещё не действительным» или «уже истёкшим», хотя с сайтом всё в порядке.

Если после этих шагов сайт по-прежнему не открывается, а у других людей работает, причина почти наверняка в вашем устройстве, сети, DNS или провайдере. Если не работает ни у кого — решать проблему должен владелец сайта.

Как читать ошибки браузера и HTTP-коды

Сообщение браузера часто сразу указывает направление поиска. Запоминать все варианты не нужно — достаточно понимать группы.

1) ERR_NAME_NOT_RESOLVED или «Не удаётся найти DNS-адрес» — браузер не смог преобразовать домен в IP-адрес. Возможные причины: домен не продлён, DNS-записи удалены, указан неправильный NS-сервер, изменения DNS ещё не распространились, локальный DNS-кэш отдаёт старые данные.

2) ERR_CONNECTION_TIMED_OUT — соединение не установилось за отведённое время. Сервер может быть выключен, порт закрыт фаерволом, трафик теряется по маршруту, CDN не может достучаться до origin-сервера.

3) ERR_CONNECTION_REFUSED — хост ответил, но на нужном порту (обычно 80 или 443) никто не принимает соединение. Возможные причины: Nginx/Apache не запущен, контейнер не пробросил порт, приложение слушает только localhost, фаервол отклоняет запросы.

4) Ошибка сертификата — браузер дошёл до сервера, но не доверяет TLS-сертификату. Он мог истечь, быть выпущен для другого домена, не содержать промежуточную цепочку или обслуживаться не тем виртуальным хостом.

5) 404 Not Found — сервер работает, но конкретная страница не найдена. Главная может открываться, а старый URL — нет. Это не всегда означает, что сайт упал.

6) 500, 502, 503, 504 — запрос дошёл до серверной части, но что-то сломалось внутри. 500 чаще связан с ошибкой приложения, 502 — прокси получил некорректный ответ от backend, 503 — сервис временно недоступен или перегружен, 504 — backend не ответил вовремя.

Для быстрой проверки HTTP-ответа удобно использовать curl:

curl -I https://example.com

Команда покажет код ответа, редиректы, заголовки сервера и иногда подсказки от CDN. Подробнее об инструменте — в материале что такое curl и как им пользоваться, а по кодам ответов — полный справочник HTTP-кодов.

DNS: когда домен не находится или ведёт не туда

DNS — одна из самых частых причин, почему сайт внезапно не открывается. Пользователь видит простую ошибку, а за ней может стоять целая цепочка: регистратор, NS-серверы, A/AAAA-записи, кэш провайдера, CDN.

1) Проверьте, продлён ли домен — если срок истёк, сайт может перестать открываться, даже если сервер работает идеально. Иногда регистратор подменяет DNS-записи на парковочную страницу или полностью отключает делегирование.

2) Проверьте NS-серверы — домен должен быть делегирован на правильные серверы имён. Ошибка в NS приводит к тому, что зона вообще не находится или отдаёт старую конфигурацию.

3) Проверьте A- и AAAA-записи — A указывает IPv4-адрес, AAAA — IPv6. Если A ведёт на старый сервер, а AAAA — на неработающий IPv6, часть пользователей может видеть ошибку: браузеры часто пробуют IPv6 первым.

4) Учитывайте DNS-кэш — после изменения записей часть пользователей ещё некоторое время получает старый IP. Это зависит от TTL, провайдера и локального резолвера, поэтому сайт может открываться у одних людей и не открываться у других.

5) Сравните ответы разных DNS — на Linux и macOS используйте dig, на Windows можно начать с nslookup.

dig example.com A

dig @1.1.1.1 example.com A

dig @8.8.8.8 example.com A

Если разные резолверы возвращают разные IP, проблема может быть в кэше или неполном распространении изменений. Если никто не возвращает IP — ищите ошибку в зоне или делегировании. Подробный разбор есть в статьях как работает DNS и как проверять DNS-записи через dig.

HTTPS и сертификаты: сайт есть, но браузер не пускает

Иногда сайт технически доступен, но браузер блокирует вход из-за HTTPS. Для обычного пользователя это выглядит как красная страница с предупреждением: «Соединение не защищено», «Ваше подключение не является приватным», NET::ERR_CERT_DATE_INVALID.

1) Сертификат истёк — самая понятная причина. Владелец не продлил сертификат или автоматическое обновление Let's Encrypt перестало работать. Обходить такое предупреждение опасно, особенно если сайт просит пароль, данные карты или персональную информацию.

2) Сертификат выпущен для другого домена — например, сертификат есть для example.com, но нет для www.example.com, или наоборот. Ещё вариант: сервер отдаёт сертификат соседнего сайта из-за неправильной настройки виртуального хоста или SNI.

3) Неполная цепочка сертификатов — сервер отдал основной сертификат, но не передал промежуточные. На одних устройствах сайт открывается, на других — нет, потому что хранилища сертификатов отличаются.

4) Сбой после переноса сайта — при миграции на новый сервер часто забывают скопировать сертификаты, настроить server_name, включить HTTPS-редирект или открыть порт 443.

5) Проблема в локальной дате — если ошибка видна только у одного пользователя, сначала проверьте дату, время и часовой пояс на его устройстве.

Владельцу сайта стоит проверить сертификат из браузера и с сервера:

curl -Iv https://example.com

В выводе будут детали TLS-соединения, сертификата и возможные ошибки проверки. Если хотите глубже понять, что происходит при защищённом соединении, полезен разбор как работает HTTPS, SSL и TLS. Для продакшена лучше не ждать жалоб: мониторинг SSL-сертификатов заранее показывает срок действия и проблемы цепочки.

Сервер и приложение: диагностика для владельца сайта

Если DNS указывает на правильный IP, сертификат в порядке, а сайт всё равно не открывается, переходите к серверу. Здесь важно двигаться слоями: сеть, веб-сервер, приложение, база данных, ресурсы.

1) Проверьте, доступен ли сервер — убедитесь, что хост вообще отвечает. ping не всегда показателен: ICMP может быть закрыт. Лучше проверить порт:

curl -I http://IP-адрес

curl -I https://example.com

Если по IP отвечает, а по домену нет — возвращайтесь к DNS или виртуальным хостам. Если не отвечает ни так, ни так — проверяйте фаервол, хостинг, сеть и статус сервера.

2) Проверьте веб-сервер — для Nginx:

systemctl status nginx

nginx -t

journalctl -u nginx -n 100

Для Apache аналогично: systemctl status apache2 или systemctl status httpd. Частая причина — ошибка в конфиге после деплоя, из-за которой веб-сервер не перезапустился.

3) Проверьте приложение — если Nginx работает, но отдаёт 502, backend может быть недоступен. Проверьте сервис приложения:

systemctl status app-name

journalctl -u app-name -n 200

Если приложение в Docker:

docker ps

docker logs container-name --tail 200

docker compose ps

Иногда контейнер циклически падает из-за переменных окружения, недоступной базы, миграций или ошибки в новой версии.

4) Проверьте порты — убедитесь, что приложение слушает нужный адрес и порт:

ss -lntp

Типичная ошибка: приложение слушает 127.0.0.1:3000, а прокси настроен на другой порт. Или порт контейнера не проброшен наружу.

5) Посмотрите логи ошибок — у Nginx это часто /var/log/nginx/error.log, у приложения — свои файлы или journald. Не ограничивайтесь последней строкой: ищите момент начала сбоя и первое сообщение об ошибке. Остальные ошибки часто просто следствие.

6) Проверьте ресурсы сервера — нехватка диска, памяти или файловых дескрипторов легко приводит к падению сайта.

Минимальный набор команд:

df -h

free -m

top или htop

uptime

journalctl -p err -n 100

Если диск заполнен, приложение может не писать сессии, кэш, логи и временные файлы. Если память закончилась, Linux мог убить процесс через OOM Killer. Если высокий load average, сайт может не падать полностью, а отвечать с огромной задержкой.

7) Проверьте базу данных и внешние зависимости — сайт может не открываться из-за недоступной БД, Redis, S3-хранилища, платёжного шлюза или внутреннего API. Особенно часто это проявляется как 500, 502, 503 или бесконечная загрузка.

Здесь помогает health check: отдельный endpoint, например /health, который проверяет не только «процесс жив», но и критичные зависимости. Но не перегружайте его: если health check сам делает тяжёлые запросы, он может усугубить проблему.

Сеть, CDN, фаервол и блокировки

Бывает, что сервер и приложение исправны, но пользователи всё равно жалуются: у одних сайт открывается, у других нет. Тогда ищите сетевую проблему между клиентом и сервером.

1) Проверьте фаервол сервера — правила ufw, iptables, security groups в облаке или настройки панели хостинга могут закрыть 80 и 443. После миграций и аварийных работ это встречается чаще, чем кажется.

2) Проверьте CDN или reverse proxy — если сайт работает через Cloudflare, DDoS-защиту, балансировщик или другой прокси, проблема может быть не на origin-сервере. CDN может не достучаться до backend, получить неверный сертификат, упереться в таймаут или заблокировать запрос по правилу WAF.

3) Сравните прямой доступ и доступ через CDN — если знаете origin IP, можно временно проверить его напрямую через curl с подстановкой хоста:

curl -I --resolve example.com:443:ORIGIN_IP https://example.com

Так вы поймёте, отвечает ли origin без участия публичного DNS и CDN. Используйте аккуратно: не публикуйте origin IP, если он должен быть скрыт за защитой.

4) Проверьте маршрутизацию — если сайт недоступен из конкретного региона или сети, используйте traceroute, mtr или WinMTR. Потери на последнем узле не всегда означают проблему, но резкий обрыв маршрута или потери на нескольких промежуточных узлах дают зацепку. Для анализа пригодится материал как читать трассировку в mtr и WinMTR.

5) Учитывайте блокировки и фильтрацию — корпоративные сети, публичный Wi‑Fi, антивирусы, родительский контроль и провайдерские фильтры могут блокировать домены, IP, категории сайтов или отдельные протоколы. Если через мобильный интернет сайт работает, а в офисной сети нет, дело может быть не в вашем сервере.

6) Проверьте лимиты и защиту от атак — rate limiting, WAF, fail2ban, геоблокировки и анти-DDoS иногда блокируют легитимных пользователей. Особенно после всплеска трафика, парсинга, массовых логинов или ошибочной настройки правил.

Сетевые проблемы сложнее диагностировать, потому что они редко видны из одной точки. Поэтому полезно проверять доступность из нескольких локаций и хранить историю: когда началось, какой код ответа был, сколько длился сбой, какие регионы затронуты.

Как владельцу сайта действовать во время сбоя

Когда сайт не открывается у реальных пользователей, важно не только найти причину, но и не усугубить ситуацию необдуманными действиями.

1) Зафиксируйте время начала — оно понадобится для сопоставления с деплоем, изменениями DNS, продлением сертификата, ростом нагрузки, работами хостинга или инцидентом у CDN.

2) Проверьте последние изменения — деплой, обновление зависимостей, изменение переменных окружения, правку Nginx, миграции БД, перенос домена, выпуск сертификата, изменение firewall-правил. Большая часть сбоев начинается сразу после изменений.

3) Определите масштаб — сайт недоступен всем или части пользователей? Не открывается главная или только личный кабинет? Проблема в вебе, API, админке, оплате, загрузке файлов? Чем точнее границы, тем быстрее диагностика.

4) Сначала восстановите доступность, потом ищите корень — если причина в новом релизе, откатите релиз. Если заполнен диск, освободите место. Если истёк сертификат, перевыпустите его. Глубокий разбор делайте после восстановления, иначе расследование затянет простой.

5) Не чистите логи до анализа — при нехватке диска соблазнительно удалить всё из /var/log. Лучше сначала сохранить нужные фрагменты: ошибки веб-сервера, приложения, базы, системные события за период инцидента.

6) Сообщите пользователям — если сбой длится заметное время, короткое сообщение в статус-странице, Telegram-канале или интерфейсе поддержки снижает поток однотипных обращений. Не нужно писать длинные объяснения: достаточно статуса, затронутых функций и следующего обновления.

7) После восстановления сделайте короткий postmortem — что сломалось, почему мониторинг заметил или не заметил проблему, какие проверки добавить, какой ручной шаг автоматизировать. Это особенно полезно для повторяющихся сбоев: истекающих сертификатов, переполненного диска, зависших процессов, ошибок после деплоя.

Для постоянного контроля пригоден uptime monitoring: сервис регулярно делает HTTP-проверку и уведомляет, если сайт недоступен или отвечает неправильным кодом. Подробнее о подходе можно почитать в материале что такое uptime monitoring и как он работает. В Statuser такую проверку можно настроить с нужным интервалом и получать уведомления о сбоях, не дожидаясь жалоб клиентов.

Чеклист быстрой диагностики

Если нужен короткий порядок действий, используйте этот чеклист.

1) Откройте сайт из другой сети — мобильный интернет, другой Wi‑Fi, внешний проверочный сервис.

2) Запишите точную ошибку — код HTTP, текст браузера, скриншот, время, URL.

3) Проверьте DNS — домен продлён, NS корректные, A/AAAA ведут на правильные IP.

4) Проверьте HTTPS — срок сертификата, домены в сертификате, цепочка, порт 443.

5) Проверьте HTTP-ответ — curl -I https://example.com, редиректы, статус-коды, заголовки CDN.

6) Проверьте веб-сервер — статус Nginx/Apache, конфиг, error log.

7) Проверьте приложение — процесс, контейнеры, логи, переменные окружения, последние релизы.

8) Проверьте ресурсы — диск, память, CPU, load average, OOM, лимиты.

9) Проверьте зависимости — база данных, кэш, очереди, внешние API, файловое хранилище.

10) Проверьте сеть и защиту — фаервол, CDN, WAF, rate limit, маршрутизацию, блокировки.

Главный принцип: идите от внешнего симптома к внутренним слоям. Не начинайте с базы данных, если домен не резолвится. Не перезапускайте приложение, если истёк сертификат. Не меняйте DNS, если проблема только в одном браузере.

FAQ

Почему сайт не открывается только у меня?
Чаще всего причина в кэше браузера, расширениях, VPN, локальном DNS, роутере, провайдере или неправильной дате на устройстве. Проверьте сайт из другой сети и другого браузера.

Что значит, если сайт долго грузится и потом показывает таймаут?
Соединение не завершилось вовремя. Возможны проблемы с сервером, перегрузка, закрытый порт, сетевые потери, CDN или backend, который не отвечает.

Сайт открывается по IP, но не открывается по домену. Что проверять?
DNS: делегирование домена, NS-серверы, A/AAAA-записи, TTL и кэш. Также проверьте конфигурацию виртуального хоста на веб-сервере.

Можно ли заранее узнать, что сайт перестал открываться?
Да. Для этого используют мониторинг доступности: регулярные HTTP-проверки с уведомлениями при ошибке, таймауте или неправильном коде ответа.