Сайт упал: чек-лист диагностики
Сначала: сайт действительно упал?
«Сайт упал» — это диагноз, который нужно поставить, а не принять на веру. Прежде чем будить разработчика или писать в поддержку хостинга, потратьте две минуты и ответьте на главный вопрос: сайт недоступен для всех или только для вас. От этого зависит, где искать причину.
Первый шаг — внешняя проверка. Откройте инструмент проверки доступности сайта и введите свой домен. Проверка выполняется с независимых серверов, а не из вашей сети, поэтому она показывает объективную картину.
| Результат внешней проверки | Что это значит | Куда копать дальше |
|---|---|---|
| HTTP 200, нормальное время | Сайт жив, проблема локальная | Раздел «Сайт не открывается только у меня» |
| HTTP 5xx | Ошибка на стороне приложения/сервера | Раздел «Ошибки сервера» ниже |
| Timeout, нет ответа | Сервер или сеть не отвечают | Разделы про сеть, DNS, хостинг |
| TLS-ошибка | Проблема с сертификатом | Раздел «SSL-сертификат» |
Если внешняя проверка показывает, что сайт жив, а у вас он не открывается, — это локальная проблема вашего устройства или сети. Ей посвящён отдельный материал: «Сайт не открывается только у меня: что делать». Дальше в этой статье разбираем случай, когда сайт действительно недоступен для всех.
Чек-лист диагностики: от простого к сложному
Двигайтесь по пунктам сверху вниз. Каждый шаг занимает меньше минуты и либо находит причину, либо уверенно исключает целый класс проблем.
- Внешняя проверка доступности. Подтвердите, что проблема глобальная.
- HTTP-код ответа. Поймите, на каком слое падает запрос.
- DNS-записи. Убедитесь, что домен указывает туда, куда нужно.
- Порт и соединение. Проверьте, открыт ли порт 443.
- SSL-сертификат. Исключите просрочку или неверную выдачу.
- Логи сервера. Найдите конкретную ошибку.
- Ресурсы хостинга. Проверьте CPU, память, диск, трафик.
Шаг 1. Определите HTTP-код ответа
Код ответа — самый информативный первый сигнал. Снимите его напрямую, без браузера:
curl -I -L https://example.com
Первая строка вывода — версия протокола и код:
HTTP/2 500
Или, при редиректах, последовательность кодов. Вот расшифровка самых частых:
| Код | Значение | Типичная причина | Куда смотреть |
|---|---|---|---|
| 500 | Internal Server Error | Ошибка в коде, PHP/backend | Логи ошибок приложения |
| 502 | Bad Gateway | Backend (PHP-FPM, proxy) не отвечает | Статус PHP-FPM/backend, логи |
| 503 | Service Unavailable | Перегрузка, обслуживание, лимиты | Ресурсы, конфигурация веб-сервера |
| 504 | Gateway Timeout | Backend не успел ответить | Медленные запросы, БД, ресурсы |
| 403 | Forbidden | Права доступа, WAF, блокировка | Конфигурация прав, правила WAF |
| 404 | Not Found | Файл/страница удалена, маршрут | Конфигурация роутинга, файлы |
Важно: коды 502 и 504 почти всегда означают, что сам веб-сервер (nginx, Apache) жив, а вот приложение за ним — нет. Код 503 часто ставят вручную при обновлениях. Ошибка 403 может быть следствием блокировки вашего IP — проверьте, не отличается ли результат внешней проверки от локального.
Шаг 2. Проверьте DNS-записи
Частая причина «упавшего» сайта — проблемы с DNS: домен перестал резолвиться, указывает на старый IP или NS-записи сменились некорректно. Проверьте, что реально отдаёт DNS:
dig example.com A +short
Вывод — просто IP-адрес:
93.184.216.34
Если вывод пустой — запись A отсутствует или домен не делегирован. Посмотрите полный набор записей и цепочку NS:
dig example.com NS +short
dig example.com A
Полную картину удобно снять инструментом проверки DNS-записей: он покажет A, AAAA, NS, MX, TXT и CNAME с точки зрения публичных резолверов. Сверьте результат с тем, что должно быть:
- Запись A должна указывать на актуальный IP сервера (не старый, если вы недавно переезжали).
- NS-серверы должны совпадать с теми, что прописаны у регистратора.
- TTL — если вы недавно меняли записи, старые значения могут жить в кэшах до истечения TTL.
Классический сценарий после переезда: домен всё ещё указывает на старый сервер, который уже выключили. Внешне это выглядит как «сайт упал», хотя код и база целы — просто трафик идёт не туда.
Шаг 3. Проверьте порт и сетевое соединение
Если DNS в порядке, а сайт не отвечает, проверьте, доступен ли порт сервера извне:
nc -zv example.com 443
Успешный ответ:
Connection to example.com 443 port [tcp/https] succeeded!
Если порт закрыт или соединение виснет — возможные причины: файрвол блокирует порт, веб-сервер не слушает этот порт, сервис не запущен, или проблема на сетевом уровне хостинга. Для диагностики сети с внешней стороны полезны проверка порта и пинг-проверка: они покажут, доступен ли хост вообще и открыт ли конкретный порт, независимо от вашей сети.
Шаг 4. Проверьте SSL-сертификат
Просроченный или неверно выданный сертификат внешне выглядит как «сайт упал», хотя сервер работает. Браузеры показывают предупреждение, а некоторые клиенты и вовсе отказываются подключаться. Проверьте сертификат напрямую:
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 2025 GMT
notAfter=Jan 1 00:00:00 2026 GMT
Если текущая дата выходит за диапазон notBefore–notAfter — сертификат просрочен. Обратите внимание и на subject: если там другое имя домена, сертификат выдан не на ваш домен.
Отслеживать срок действия заранее помогает инструмент проверки срока SSL-сертификата: он покажет, сколько дней осталось до истечения, и предупредит заранее, чтобы просрочка не стала неожиданностью в самый неподходящий момент.
Шаг 5. Посмотрите логи сервера
Когда внешние проверки не дают однозначного ответа, идите в логи — именно там лежит конкретная причина ошибки. Расположение зависит от стека:
# nginx / Apache — логи доступа и ошибок
tail -n 100 /var/log/nginx/error.log
# системный журнал
journalctl -u nginx --since "10 minutes ago"
Что искать: PHP-фатальные ошибки, ошибки подключения к базе данных (например, connection refused или Too many connections), ошибки прав доступа, сообщения о нехватке памяти (Allowed memory size exhausted). Каждая из них — это конкретный адрес проблемы, а не абстрактное «сайт лежит».
Шаг 6. Проверьте ресурсы сервера
Если ошибка нестабильная — сайт то открывается, то падает — почти наверняка дело в исчерпании ресурсов. Проверьте базовые показатели:
free -h # память
df -h # диск
uptime # нагрузка (load average)
Таблица типичных сценариев:
| Симптом | Причина | Решение |
|---|---|---|
| Load average сильно выше числа ядер | Перегрузка CPU | Найти тяжёлые процессы, оптимизировать, добавить ресурсы |
| Память исчерпана, сервер убивает процессы | Нехватка RAM, OOM | Увеличить RAM, ограничить число workers, swap |
| Диск заполнен на 100% | Логи, бэкапы, кэш | Почистить логи, настроить ротацию |
| 503 при всплеске трафика | Превышение лимитов хостинга | Поднять лимиты, кэширование, балансировка |
| «Too many connections» в БД | Исчерпан лимит соединений | Увеличить max_connections, оптимизировать пул |
Отдельно стоит проверить, не упёрлись ли вы в лимиты тарифа хостинга: ввод-вывод, количество запросов, исходящий трафик. Многие «падения» — это на самом деле сработавший лимит.
Шаг 7. Проверьте базу данных
Для динамических сайтов (CMS, интернет-магазины, веб-приложения) база данных — самое частое узкое место и самый частый источник ошибок 500/502/504. Даже если сам код в порядке, неработающая БД «роняет» весь сайт.
Проверьте, отвечает ли сервер БД:
mysqladmin -u root -p status
Или, для PostgreSQL:
pg_isready
Ключевые проблемы и их признаки:
| Проблема | Признак | Решение |
|---|---|---|
| БД не запущена | connection refused в логах приложения |
Запустить сервис, проверить автозапуск |
| Исчерпан лимит соединений | Too many connections |
Увеличить max_connections, закрыть «зависшие» соединения |
| Медленные запросы | 504 Gateway Timeout, рост TTFB | Найти медленные запросы, добавить индексы |
| Переполненный диск БД | Ошибки записи, отказ транзакций | Освободить место, настроить ротацию логов |
| Репликация отстала | Чтение устаревших данных | Проверить лаг реплики, устранить причину |
Отдельный момент — быстрая проверка именно скорости ответа БД на простейший запрос. Медленный ответ на SELECT 1 говорит о том, что сервер БД перегружен или ему не хватает ресурсов, и это нужно решать до того, как сайт окончательно ляжет.
Шаг 8. Проверьте редиректы и конфигурацию
Если сайт отвечает, но не тем, что нужно, проверьте цепочку редиректов и конфигурацию веб-сервера. Инструмент проверки редиректов покажет всю цепочку переходов и выявит зацикливание или лишний редирект:
curl -IL https://example.com
Зацикленный редирект (301 на самого себя) или редирект на несуществующую страницу выглядят для пользователя как «сайт не работает», хотя сервер жив. После изменения конфигурации nginx/Apache всегда проверяйте синтаксис перед перезагрузкой:
nginx -t
Что делать, если сайт за CDN или прокси
Если ваш сайт работает за CDN (Cloudflare и аналоги) или за обратным прокси, картина диагностики меняется: снаружи пользователь видит CDN, а не ваш сервер. Это важно понимать, потому что ошибки 5xx при этом могут иметь две разные причины:
- Сбой на вашем origin-сервере. CDN передаёт ответ вашего сервера, и если origin лежит, CDN честно отдаёт 502/504.
- Сбой самого CDN. Реже, но бывает: проблемы на стороне CDN-провайдера.
Как разделить: проверьте origin-сервер напрямую, минуя CDN. Определите реальный IP сервера (например, по истории DNS или из панели хостинга) и обратитесь к нему:
curl -I -k --resolve example.com:443:203.0.113.10 https://example.com
Если напрямую сервер отвечает 200, а через CDN — ошибка, проблема на стороне CDN или в его конфигурации (кеш, правила, origin-настройки). Если origin тоже не отвечает — копайте сам сервер по чек-листу выше.
Ещё один нюанс CDN — кеш. После исправления ошибки старый «битый» ответ может какое-то время раздаваться из кеша CDN. Если после починки сайт всё ещё показывает ошибку, проверьте очистку кеша CDN и повторите проверку через инструмент проверки доступности, который запрашивает страницу заново, не из локального кеша.
Что делать, если причина не найдена
Если вы прошли весь чек-лист и не нашли причину, соберите факты и обращайтесь к тому, кто может помочь — в поддержку хостинга или к разработчику. Сформулируйте запрос предметно:
- Точное время начала недоступности.
- HTTP-код или текст ошибки из браузера.
- Результат внешней проверки — скриншот или вывод.
- Что вы уже проверили и что исключили.
Чем точнее исходные данные, тем быстрее ответит поддержка — вместо «у меня сайт не работает» вы приходите с готовым диагнозом «502 Bad Gateway, backend не отвечает, порт 443 открыт».
Профилактика: чтобы не гадать в следующий раз
Разовый разбор причин — хорошо, но надёжнее ловить проблему до того, как её заметят клиенты. Регулярная внешняя проверка доступности фиксирует сбой в момент его начала, а не когда о нём написали в чат. Это позволяет:
- понять, когда начался сбой и сколько длился;
- отличить кратковременный скачок от затяжного отказа;
- проверить доступность с разных точек, а не только из одной сети.
UptimeChecker умеет регулярно опрашивать сайт с внешних серверов и показывать историю доступности — это удобно и для собственного спокойствия, и как факт для обсуждения с хостингом или заказчиком. Начните с простого: добавьте свой домен в проверку доступности и посмотрите, как он ведёт себя в течение недели.
