Сайт недоступен: что делать и как найти причину

Что значит «сайт недоступен»

Когда сайт перестаёт открываться, за фразой «сайт недоступен» скрывается множество разных сценариев: браузер может долго крутить загрузку и в итоге выдать ошибку соединения, страница может открыться с ошибкой 5xx, а может показать заглушку хостинга или реестра доменов. У каждого сценария — своя причина, а значит, и своё решение. Если не разобраться, где именно «рвётся», легко потратить часы на перезапуск не тех служб и переписку не с теми людьми.

Эта статья — пошаговый алгоритм диагностики: от самого быстрого внешнего взгляда до чтения логов сервера. Вы пройдёте путь, по которому идут администраторы, когда получают алерт «сайт лежит», и научитесь по выводу curl, ping и dig понимать, в каком слое проблема. В конце — сводная таблица «симптом → вероятная причина → что проверить», которую удобно держать под рукой.

Сразу договоримся о важном: доступность — это не «да/нет». Один и тот же сайт может быть недоступен из одной точки мира и отлично открываться из другой, падать на 40 секунд в час и формально «работать» остальные 59 минут. Поэтому диагностику всегда начинают с двух вещей — проверить факт падения независимо и зафиксировать время.

Шаг 0. Зафиксируйте симптом точно

Прежде чем что-то чинить, ответьте на четыре вопроса. От них зависит, каким инструментом вы будете «копать» дальше.

Что именно показывает браузер? Запишите текст ошибки дословно или сделайте скриншот. «ERR_CONNECTION_TIMED_OUT» — это не то же самое, что «ERR_CERT_DATE_INVALID» или «HTTP 503 Service Unavailable». Браузер уже подсказывает слой, где произошёл обрыв.

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

Когда началось? Сверьтесь с временем деплоя, обновления DNS, продления домена или установки сертификата. Большинство внезапных падений имеют конкретный триггер — действие, которое вы или кто-то ещё совершил незадолго до этого.

Что изменилось за последние сутки? Новый релиз, смена хостинга, правка конфига nginx, обновление DNS-зоны, включение Cloudflare, переезд сервера. В 8 из 10 случаев причина — последнее изменение.

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

Шаг 1. Проверьте доступность независимо от браузера

Первым делом не «попробуйте перезагрузить страницу», а проверьте сайт внешним инструментом. Это отсекает локальные факторы — кеш браузера, ваш DNS, вашу сеть — и даёт объективную картину.

Воспользуйтесь проверкой доступности uptimechecker.ru/check: введите адрес и посмотрите, какой код ответа и статус видит внешняя система из нескольких точек. Это самый быстрый способ ответить на вопрос «сайт реально лежит или это у меня не открывается».

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

curl -I https://example.com

Разберём вывод построчно:

HTTP/2 200
server: nginx
date: Mon, 15 Sep 2026 10:00:00 GMT
content-type: text/html; charset=UTF-8

• HTTP/2 200 — главное: код ответа. 200 означает «сайт жив», проблема, скорее всего, была временной или локальной. Любой код из серии 5xx (500, 502, 503, 504) — сервер жив и отвечает, но приложение за ним падает.
• server: nginx — какой веб-сервер отвечает. Полезно, когда вы не уверены, достучались ли вы до своего сервера или до заглушки CDN/провайдера.
• date — время на сервере. Если оно сильно расходится с реальным, это само по себе источник проблем (например, с проверкой сертификатов).

Если вместо заголовков вы видите что-то вроде:

curl: (7) Failed to connect to example.com port 443 after 15000 ms: Connection timed out

— это уже важный сигнал. Код (7) и «Connection timed out» означают, что соединение не установилось вообще: либо сервер не слушает порт, либо пакеты до него не доходят (файрвол, блокировка), либо машина выключена. Переходите к шагу про порты и сеть.

Если видите curl: (6) Could not resolve host — curl не смог преобразовать доменное имя в IP. Это чистая проблема DNS, идите к шагу про DNS.

Шаг 2. Определите, локальная это проблема или глобальная

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

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

Попробуйте разные DNS. Многие «падения» — это устаревшие или сломанные записи у резолвера. Временно переключите резолвер на публичный и проверьте снова:

dig example.com @1.1.1.1 +short

Вывод — просто IP-адрес, например 93.184.216.34. Если через сторонний резолвер адрес резолвится, а через ваш — нет, проблема в вашем DNS-сервере или кеше. Сбросьте локальный кеш (sudo systemd-resolve --flush-caches на Linux, ipconfig /flushdns на Windows) и проверьте настройки резолвера.

Проверьте с другого устройства. Если на телефоне сайт открывается, а на ноутбуке нет — это устройство: hosts-файл, антивирус, VPN-расширение браузера или неправильные сетевые настройки. Проверьте /etc/hosts (Linux/macOS) или C:\Windows\System32\drivers\etc\hosts (Windows) на предмет ручных записей для вашего домена.

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

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

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

Первым делом посмотрите, что вообще резолвит ваш домен, через uptimechecker.ru/dns-check: инструмент покажет A- и AAAA-записи, MX, NS и TXT. Сверьте их с ожидаемыми адресами вашего сервера.

То же самое вручную через dig:

dig example.com A

Ключевые строки вывода:

;; ANSWER SECTION:
example.com.		300	IN	A	93.184.216.34

• 300 — TTL (время жизни записи в секундах), то есть сколько её будут кешировать резолверы.
• IN A — тип записи и её значение. Здесь домен указывает на 93.184.216.34.

Что смотреть:

• Запись отсутствует (ANSWER SECTION пустая) — домен не резолвится. Либо зона была удалена/не прописана, либо домен истёк. Проверьте срок регистрации домена.
• Запись указывает не на ваш сервер — кто-то менял DNS, либо вы недавно переносили сайт и не обновили запись. Сравните IP с реальным адресом вашего сервера.
• Домен не делегирован — если dig example.com NS не возвращает серверов имён или возвращает чужие, проблема в NS-записях у регистратора.

Отдельная частая история — «домен освободился». Если сайт вдруг стал показывать заглушку регистратора или рекламную парковку, проверьте срок регистрации домена через uptimechecker.ru/domain-check: возможно, оплата не прошла, и домен ушёл на удержание. Это редкий, но драматичный сценарий, который стоит исключить на раннем этапе.

Помните про TTL: даже после исправления записи часть посетителей будет видеть старый адрес ещё столько секунд, сколько указано в TTL. Поэтому на время миграций TTL заранее снижают (например, до 300 или 60 секунд).

Шаг 4. Проверьте SSL-сертификат

Вторая по частоте «тихая» причина недоступности — истёкший или неверно установленный SSL-сертификат. Браузеры в этом случае не просто показывают предупреждение, а блокируют сайт целиком, и для посетителя это выглядит как «сайт недоступен».

Симптомы узнаваемы: «ERR_CERT_DATE_INVALID», «NET::ERR_CERT_COMMON_NAME_INVALID», «Ваше соединение не защищено». Причины разные:

• сертификат истёк (забыли продлить или не сработал авто-renew);
• сертификат выпущен на другой домен (забыли добавить www или поддомен);
• цепочка сертификатов неполная (не подложен промежуточный сертификат);
• на сервере после обновления остался старый сертификат.

Проверьте состояние сертификата через uptimechecker.ru/ssl-check: инструмент покажет срок действия, домен, на который выпущен сертификат, и корректность цепочки.

То же самое вручную через openssl:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

Построчный разбор вывода:

subject=CN = example.com
notBefore=Jan  1 00:00:00 2026 GMT
notAfter=Dec 31 23:59:59 2026 GMT

• subject=CN = example.com — на какой домен выдан сертификат. Если вы заходите на www.example.com, а сертификат только на example.com (без www), браузер выдаст ошибку несовпадения имени.
• notBefore / notAfter — период действия. Если текущая дата вышла за notAfter, сертификат истёк.

Если сертификат истёк — перевыпустите его (для Let's Encrypt это делается одной командой certbot renew). Если имя не совпадает — перевыпустите сертификат с правильным списком доменов. Если цепочка неполная — подложите промежуточный сертификат в конфиг веб-сервера.

Отдельно стоит настроить отслеживание срока действия, чтобы не попадать в эту ситуацию раз в год: инструмент uptimechecker.ru/ssl-expiry покажет, когда истекает сертификат, чтобы продлить его заранее, а не после того, как сайт уже лёг.

Шаг 5. Проверьте сеть и порты

Если DNS в порядке и сертификат валиден, а сайт всё равно не открывается — проверяем, доходит ли вообще трафик до сервера и слушает ли сервер нужный порт.

Пинг — проверка «жив ли хост». Пинг проверяет доступность машины по протоколу ICMP и не зависит от веб-сервера:

ping -c 4 example.com

Разбор вывода:

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=52 time=18.5 ms
...
--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

• Строки с 64 bytes from ... — ответы от хоста. time=18.5 ms — задержка.
• 0% packet loss — все пакеты дошли. Хост жив, сеть до него работает.
• Если видите 100% packet loss — пакеты не доходят. Но осторожно: многие серверы отключают ICMP-ответы намеренно, поэтому «не пингуется» не всегда равно «сервер лежит». Пинг — косвенный признак, а не приговор.

Проверка порта — «слушает ли сервер нужный порт». Веб-сайт по HTTPS работает на порту 443, по HTTP — на 80. Если пинг проходит, а порт закрыт, сайт всё равно не откроется:

nc -zv example.com 443

Возможные результаты:

Connection to example.com 443 port [tcp/https] succeeded!

— порт открыт, сервер принимает соединения. Дальше копаем в сторону приложения.

nc: connect to example.com port 443 (tcp) failed: Connection refused

— машина доступна, но на порту 443 никто не слушает: веб-сервер (nginx/Apache) упал или слушает другой порт.

nc: connect to example.com port 443 (tcp) failed: Connection timed out

— пакеты вообще не доходят до порта: файрвол (локальный или у провайдера) режет трафик, либо сервер под блокировкой.

Проверить порт можно и через uptimechecker.ru/port-check, не настраивая ничего на своей машине.

Если порт закрыт — зайдите на сервер и проверьте, запущен ли веб-сервер (systemctl status nginx), на каком порту он слушает (ss -tlnp), и не добавилось ли недавно правило файрвола (ufw status / iptables -L).

Шаг 6. Сервер: статусы, процессы и логи

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

Проверьте код ответа целиком. Вернитесь к curl, но на этот раз посмотрите полный ответ, а не только заголовки:

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

Вывод — просто код: 200, 500, 502, 503. Разберём самые показательные:

• 502 Bad Gateway — веб-сервер (nginx) запущен, но не может достучаться до приложения за ним (PHP-FPM, Node, Gunicorn упал или перегружен).
• 503 Service Unavailable — сервер сознательно отвечает «недоступен»: обычно потому, что приложение в режиме обслуживания или все воркеры заняты.
• 504 Gateway Timeout — приложение не успело ответить за отведённое время: медленный запрос, зависшая база, перегрузка.

Проверьте ресурсы машины. Частая причина внезапных падений — исчерпанные ресурсы:

df -h
free -h

Если диск заполнен на 100% (df -h), сервисы могут перестать писать логи и падать. Если память исчерпана и система ушла в своп (free -h), приложение может быть убито OOM-killer'ом. Освободите место или добавьте ресурсы, затем перезапустите сервисы.

Читайте логи. Это самый информативный источник — именно здесь лежит конкретное сообщение об ошибке:

tail -n 50 /var/log/nginx/error.log
journalctl -u nginx --since "1 hour ago"

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

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

Сводная таблица: симптом → причина → решение

Держите эту таблицу под рукой: она сжимает весь маршрут диагностики в один лист.

Почему сайты падают: типичные причины

Чтобы не искать причину вслепую, полезно знать, из-за чего сайты падают чаще всего. Подробный разбор с примерами — в статье «Почему падают сайты: основные причины». Здесь — краткая выжимка по частоте:

• Обновления и деплои — самый частый триггер. Новая версия кода, смена конфига, неудачная миграция. Лечится откатом к предыдущей версии.
• Истечение сроков — домен и SSL-сертификат. Обе вещи «внезапно» заканчиваются, если за ними не следить.
• Исчерпание ресурсов — диск, память, лимиты хостинга. Растёт вместе с трафиком незаметно.
• DNS-сбои — у регистратора, провайдера DNS или после ручной правки зоны.
• Перегрузка — всплеск трафика, DDoS, «эффект Хабра» после публикации.
• Сбои провайдера/дата-центра — за пределами вашего контроля, но их надо уметь отличать от своих проблем.

Понимание того, что падение может иметь внешнюю причину, снимает половину паники: не всё, что лежит, лежит из-за вашего кода.

Что делать, пока сайт недоступен: чек-лист

Когда сайт уже упал и пользователи ждут, действуйте по короткому чек-листу, не по наитию. Развёрнутую версию с приоритетами и таймингами смотрите в статье «Сайт упал: чек-лист действий».

Минимальная последовательность:

1. Подтвердите факт независимой проверкой — не доверяйте одному браузеру и одной сети.
2. Оцените масштаб — падает у всех или локально, один регион или весь мир.
3. Найдите слой по описанной выше цепочке: DNS → SSL → сеть/порты → сервер → приложение.
4. Откатите последнее изменение — чаще всего это решает проблему быстрее, чем поиск первопричины.
5. Сообщите пользователям, если падение затянулось, — заглушка с объяснением лучше, чем молчание.
6. Зафиксируйте причину после восстановления, чтобы падение не повторилось.

Главный принцип — не менять ничего «наугад» в момент паники. Каждое действие должно быть ответом на конкретный симптом из таблицы выше.

Как не оказаться в этой ситуации снова

Разово поднять сайт — это полдела. Настоящая задача — узнать о падении раньше, чем о нём узнают ваши пользователи, а в идеале не допустить его вовсе.

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

UptimeChecker как раз решает эту задачу: он проверяет доступность сайта, срок действия SSL-сертификата и домена, а результаты всех проверок можно свести в единую картину — что доступно, что скоро истечёт, что уже упало. Начните с разовой проверки доступности на uptimechecker.ru/check, чтобы убедиться, что ваш сайт сейчас отвечает корректно, а дальше решите, нужен ли вам постоянный контроль.