Иногда сообщение приходит лаконичное: «Сайт не открывается». В этот момент хочется не паниковать, а просто открыть чек-лист и пройтись по шагам.

Делюсь своим порядком действий, который работает и для Bitrix/WordPress, и для любого PHP-проекта.

1. Сначала проверяю, точно ли проблема на сервере

Минимум, который я делаю с ноутбука:

ping site.ru curl -I https://site.ru

Смотрю: • DNS нормально резолвится или домен вообще не отвечает • какой код приходит: 200/301/302, 403/404, 500/502/504 • есть ли ответ от nginx/Apache или вообще тишина по порту

Если DNS не жив или домен только что переносили — сначала решаю этот уровень.

2. Захожу на сервер и смотрю «температуру»

На сервере первым делом:

htop # груз по CPU и памяти df -h # свободное место на дисках free -h # память и swap

Типичные картины: • диск забит на 100% → логам негде писаться, БД не может записывать • память съедена, всё ушло в swap → любой запрос превращается в пытку • один процесс php-fpm или mysqld кушает весь CPU

Пока ресурсы не освобождены, бессмысленно ковырять код.

3. Проверяю веб-сервер и PHP-FPM

Дальше по цепочке:

systemctl status nginx systemctl status php-fpm journalctl -u nginx --no-pager -n 50 journalctl -u php-fpm --no-pager -n 50

Ищу: • падения процессов • ошибки конфигурации после последних правок • превышение лимита процессов PHP-FPM (pm.max_children)

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

4. Смотрю базу данных

БД легко становится узким местом.

Минимум:

systemctl status mysql mysql -e "SHOW PROCESSLISTG" | head -n 20

Обращаю внимание: • есть ли висящие запросы в статусе Locked или Sending data • не уткнулся ли сервер в лимит подключений • не забита ли диск/папка с данными MySQL

При полном падении БД сайт обычно отдаёт 500 или Error establishing a database connection.

5. Логи проекта: что говорит сам сайт

Следующий слой — логи самого приложения: • для Laravel: storage/logs/laravel.log • для Bitrix: логи в /bitrix/php_interface/собственные обработчики • для WordPress: WP_DEBUG_LOG, свои файлы логов

Часто там видно: • фатальную ошибку после обновления PHP или пакетов • падение на конкретном модуле / плагине • ошибки подключения к внешним сервисам (CRM, платежи, API)

Задача — увидеть последний повторяющийся стек-трейс.

6. Быстрая изоляция проблемы

Когда понятно, что сервер жив, но сайт падает, я упрощаю маршрут: • пробую открыть простую info.php:

php phpinfo();

• если info.php работает, а основной сайт падает → проблема в проекте • если не работает даже info.php → смотрю PHP-FPM, nginx, модули

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