Когда сайт на WordPress начинает вести себя нестабильно, “проверить настройки” почти всегда превращается в долгие догадки. Логи на VPS дают опору: они показывают, что именно упало, в какой момент и какой компонент это сделал. Важно не просто собрать файлы, а связать событие из браузера с записью в журнале.
Ниже — практический маршрут диагностики: от веб-сервера и PHP до базы данных и системных журналов. Подойдет для VPS с Nginx или Apache, PHP-FPM и типичной схемой размещения WordPress.
Какие логи на VPS обычно отвечают за сбои WordPress
WordPress — это не один процесс. Он работает внутри связки: веб-сервер принимает запрос, PHP выполняет код, дальше могут подключаться база данных, файловая система и фоновые задачи. Поэтому “где искать ошибку” зависит от того, на каком участке цепочки она возникает.
Журналы веб-сервера: Nginx или Apache
Веб-сервер отвечает за HTTP-уровень. Он фиксирует статусы (200/404/500), URL, IP пользователя и часто первопричину на входе в приложение (например, upstream sent too big headers, connect() failed и т.д.).
Именно эти логи полезны, когда ты видишь:
- 500 Internal Server Error
- 502/504 (проблемы с PHP-FPM или upstream)
- резкие всплески 404 на админке
- ошибки времени ожидания
Логи PHP: PHP-FPM и PHP CLI
Большая часть “настоящих” ошибок WordPress живет в PHP. Это фатальные ошибки, warnings, проблемы с памятью, исключения, падения в плагинах и темах.
На VPS с PHP-FPM лог может быть:
- отдельным файлом на уровне pool (часто отдельные логи по пользователям/сайтам)
- через systemd/journald, если сервис настроен на вывод в журнал
- плюс ошибки, возникающие в консольных командах (WP-CLI, cron), которые могут писать в свои места
Системные логи: systemd/journald, kernel
Системные журналы нужны, когда проблема не только в WordPress. Например:
- сервис PHP-FPM часто перезапускается из‑за OOM (out of memory)
- диск заполняется и приложения начинают падать
- есть проблемы с сетью или DNS
- kernel показывает ошибки I/O
На практике это всплывает, когда в логах веб-сервера видно обрывы upstream, а в PHP нет понятной причины.
Логи базы данных: MySQL/MariaDB
WordPress очень зависим от базы. Когда MySQL/MariaDB недоступна или перегружена, сайт может возвращать:
- ошибку подключения к базе данных
- ошибки с таймаутами
- “соединение потеряно” в процессе записи
- задержки из-за медленных запросов
Отдельно полезен slow query log, если он включен, но даже без него error log обычно содержит важные события.
Логи фоновых задач: cron, очереди, mail
Часть проблем проявляется не при открытии страницы, а по расписанию:
- “плановые статьи” не публикуются
- обновления ядра/плагинов зависают
- синхронизация метрик и рассылки ломаются
- cron событий “scheduled” не выполняется
Это видно в системных логах cron и в логах, которые пишет WP-CLI, если ты им пользуешься.
Где именно смотреть логи на VPS: пути и команды
Чтобы не тратить время, начни с быстрых действий: подключение по SSH, выбор нужного файла и чтение “хвоста”. Далее ты перейдешь к точной диагностике.
Быстрая проверка: SSH и tail/grep
- Подключись к VPS по SSH.
- В момент, когда ты воспроизводишь ошибку в браузере, открой “хвост” логов.
Примеры команд:
«`bash ssh user@your-vps «`
«`bash sudo tail -n 200 /var/log/nginx/error.log «`
«`bash sudo tail -f /var/log/nginx/error.log «`
Поиск по ключевым фрагментам:
«`bash sudo grep -n «PHP Fatal error» /var/log/nginx/error.log «`
«`bash
- sudo grep -R —line-number «Allowed memory size» /var/log: head
«`
Если ты не уверен, какой лог трогать первым, следуй алгоритму ниже: сначала веб-сервер, потом PHP, затем база и системные журналы.
Nginx: access.log и error.log
Для Nginx чаще всего встречается такая структура:
- access.log — запросы и коды ответов
- error.log — ошибки, связанные с обработкой
Типичные пути:
- /var/log/nginx/access.log
- /var/log/nginx/error.log
Проверка “когда” и “что”:
«`bash sudo tail -n 200 /var/log/nginx/access.log «`
«`bash sudo tail -n 200 /var/log/nginx/error.log «`
Чтобы быстро выловить проблему по коду 500/502/504 и по времени, можно отфильтровать по статусу:
«`bash
- sudo grep » 500 » /var/log/nginx/access.log: tail -n 50
«`
Если у тебя несколько сайтов, в error.log будут записи со строками server_name или upstream. Это помогает сузить круг.
Apache: errorlog и modproxy_fcgi
Для Apache обычно:
- /var/log/apache2/error.log (часто на Debian/Ubuntu)
- /var/log/httpd/error_log (часто на CentOS/Alma/Rocky)
Команды для хвоста:
«`bash sudo tail -n 200 /var/log/apache2/error.log «`
Поиск в error_log:
«`bash
- sudo grep -n «PHP Fatal error» /var/log/apache2/error.log: tail -n 20
«`
Если используется php-fpm через modproxyfcgi, upstream ошибки тоже будут в error_log Apache.
PHP-FPM: что читать и как находить pool
PHP-FPM пишет ошибки двумя основными способами:
- в отдельный файл, заданный в конфигурации пула
- в journald, если так настроен сервис
Сначала посмотри, работает ли php-fpm и какие пулы есть:
«`bash systemctl status php-fpm —no-pager «`
Иногда имя сервиса зависит от версии PHP: php8.1-fpm, php7.4-fpm и т.д. Уточнить можно так:
«`bash
- systemctl list-units —type=service: grep -i fpm
«`
Дальше найди конфиг пула:
«`bash ls /etc/php*/fpm/pool.d/ «`
Примерно в конфиге пула будут параметры типа:
- error_log
- access.log (реже)
- catchworkersoutput
Чтобы быстро найти строку с error_log:
«`bash sudo grep -R «error_log» /etc/php*/fpm/pool.d/ -n «`
Когда нашел файл, читаешь его хвост:
«`bash sudo tail -n 200 /path/to/php-fpm-error.log «`
Если error_log указывает на stdout/stderr или используется journald, удобнее смотреть через journalctl (см. ниже).
systemd/journald: journalctl для ошибок WordPress
Если php-fpm настроен на журнал, данные будут доступны в journald. Команда:
«`bash journalctl -u php-fpm —since «1 hour ago» —no-pager «`
С учетом версии PHP:
«`bash journalctl -u php8.2-fpm —since «2 hours ago» —no-pager «`
Можно искать прямо по шаблонам:
«`bash
- journalctl -u php-fpm —since «1 hour ago» —no-pager: grep -i «fatal\; error\; warning»
«`
Плюс journald удобен тем, что не нужно угадывать путь к файлу, а еще проще сопоставить время события.
MySQL/MariaDB: error log и slow query log (если включен)
Пути зависят от дистрибутива, но часто встречается:
- /var/log/mysql/error.log
- /var/log/mariadb/mariadb.log
- либо error log определяется в конфиге MySQL
Быстрый поиск:
«`bash sudo ls /var/log/mysql /var/log/mariadb 2>/dev/null «`
Хвост error log:
«`bash sudo tail -n 200 /var/log/mysql/error.log «`
Если не знаешь точный путь, можно посмотреть конфиг:
«`bash sudo grep -R «log_error» /etc/mysql /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null «`
Про slow query log (медленные запросы) имеет смысл вспоминать при проблемах с производительностью: долгие загрузки страниц, таймауты, резкие скачки CPU.
Логи WordPress: WPDEBUGLOG и debug.log
WordPress умеет писать логи ошибок PHP-подобного уровня. Работает через настройки в wp-config.php.
О том, как включить и где потом искать, будет отдельный раздел. Сейчас важная мысль: без WPDEBUGLOG ты можешь видеть только HTTP-симптомы (500/502), но не знать точный текст ошибки.
Настройка WordPress для диагностических логов
Логи WordPress — это то, что чаще всего помогает быстрее всего. Ты видишь сообщение уровня “куда упало” внутри приложения: конкретная функция, класс, плагин или тема, и иногда строки, где ошибка произошла.
WPDEBUG и WPDEBUG_LOG в wp-config.php
В wp-config.php добавь/изменить параметры:
«`php define(‘WP_DEBUG’, true); define(‘WPDEBUGLOG’, true); define(‘WPDEBUGDISPLAY’, false); «`
После этого WordPress начнет писать ошибки в файл:
- wp-content/debug.log
Сразу после воспроизведения проблемы открой хвост:
«`bash tail -n 200 /path/to/wordpress/wp-content/debug.log «`
Если debug.log не появляется, проверь права на директорию wp-content. У многих сайтов она доступна только пользователю веб-сервера и владельцу файлов, поэтому важно, чтобы WP мог писать.
Как безопасно включать вывод ошибок (WPDEBUGDISPLAY)
WPDEBUGDISPLAY отвечает за то, показывает ли WordPress ошибки прямо на странице. Для диагностики иногда нужно, но чаще это мешает: вместо понятного HTTP ответа ты получишь “шум” на экране и потенциальные утечки деталей.
Для VPS-диагностики обычно лучше:
- включить WPDEBUGLOG
- держать WPDEBUGDISPLAY в false
И уже по логам решать, что делать дальше.
Что делать, если ошибок нет, но сайт всё равно падает
Такая ситуация встречается, когда:
- проблема не в PHP (например, SSL/TLS, 502 от upstream, ошибочная маршрутизация в Nginx)
- включенные ошибки не покрывают конкретный тип сбоя
- код падает так рано, что WordPress ещё не успевает обработать (иногда это видно в PHP-FPM логах, но не в debug.log)
Тогда возвращайся к веб-серверу и PHP-FPM:
- в Nginx error.log/Apache error_log будут upstream и ошибки обработки
- в php-fpm error log будут fatals/parse errors
Уровни логирования в плагинах и темах
Некоторые плагины пишут в свои логи или используют библиотеки логирования. Если есть подозрение на конкретный плагин, полезно:
- временно отключить его (лучше через файловую систему или безопасный режим, чем через админку)
- проверить его логические файлы (папки с cache/logs обычно называются похоже, но зависят от плагина)
Типичная ошибка новичков — искать причину в WordPress debug.log, хотя реальная запись была в логах плагина. Если в debug.log пусто, а в веб-сервере видны 500, это повод проверить php-fpm и системные журналы.
Алгоритм диагностики: от симптома к причине
Диагностика ускоряется, если действовать по цепочке и не перескакивать между логами без связи по времени и запросу. Ниже — порядок, который работает в большинстве случаев.
Сначала фиксируй симптом и время
Запиши:
- когда проблема началась (с точностью хотя бы до минут)
- что происходит: 500, белый экран, ошибка в админке, бесконечная загрузка
- есть ли воспроизводимость: только для админа, только после обновления, только для мобильных
Если проблема случилась при конкретном действии (например, публикация записи), воспроизведи снова после включения логов.
Ищи соответствующую запись в логах веб-сервера
Открой access.log/error.log и проверь записи рядом с моментом события. Для Nginx это обычно:
- error.log — причина на уровне обработки запроса
- access.log — статус-код и URL
Полезные вопросы:
- есть ли статус 502/504 (часто upstream или php-fpm недоступен)
- есть ли заметная цепочка запросов (например, редиректы или loop)
- совпадает ли IP пользователя/админки с записью
Переходи к PHP-логам по request и времени
Как только в access/error логах есть подтверждение, что запрос реально был обработан и упал, переходи в логи PHP-FPM. Сопоставляй:
- время (минуты/секунды)
- путь (URI) и часто “сайт” через server_name
- совпадение с тем, что видишь в браузере
Частые находки в PHP-файлах:
- PHP Fatal error: Uncaught …
- Allowed memory size of …
- Parse error: syntax error
- обращение к несуществующему файлу/классу
Проверяй базу данных и фоновые задачи
Если ошибка относится к базе (коннект, таймауты, “Error establishing a database connection”), обязательно проверь:
- error log MySQL/MariaDB
- нагрузку (если есть возможность посмотреть метрики)
- наличие блокировок и рост очередей
Если сайт “не падает”, но функциональность ломается периодически, смотри cron и фоновые события WordPress.
Системные логи cron часто содержат подсказки, например, что команда не запустилась или WP-CLI упал с кодом ошибки.
Учитывай типичные “ложные” причины
Иногда запись в WordPress debug.log не проливает света, потому что проблема в инфраструктуре:
- диск заполнен → ошибка записи файлов, кешей, апдейтеров
- неверные права на директории → WordPress не может записать кэш/обновления
- DNS/сертификаты → сайт “ломается” до PHP (это видно в nginx/apache и системных логах)
Поэтому если PHP кажется “чистым”, всегда проверяй Nginx/Apache и системные журналы на наличие OOM, I/O и переполнения диска.
Типичные ошибки WordPress и куда смотреть
Ниже — привязка симптом → где обычно искать причину. Это не исчерпывающий список, но он хорошо экономит время.
500 Internal Server Error
Где искать:
- Nginx error.log / Apache error_log — причины на уровне обработки
- php-fpm error log — PHP Fatal error или проблемы конфигурации
- wp-content/debug.log — точные ошибки в коде WordPress/плагина
Частые причины:
- фатальная ошибка в плагине/теме
- ошибка в синтаксисе после обновления
- нехватка памяти
- неверные пути к файлам или права на них
Что проверить быстро:
- хвост PHP-FPM логов за минуту до ошибки
- наличие Parse error или Fatal error
- наличие Allowed memory size
Белый экран и фатальные ошибки PHP
Белый экран часто связан с fatal error, но иногда он не доходит до WordPress debug.log из-за ранней точки падения. Поэтому стратегия:
- сначала php-fpm error log
- затем Nginx/Apache error_log
- и только потом debug.log
Если включал WPDEBUGLOG, но debug.log пустой, это намек на падение до старта WordPress (или на то, что ошибка не попадает в уровень логирования).
Ошибка подключения к базе данных
Где смотреть:
- wp-content/debug.log (иногда показывает текст, но не всегда)
- MySQL/MariaDB error log — отказ коннекта, недоступность сокета
- Nginx/Apache error_log — подтверждение, что это именно 500, а не инфраструктура
Что часто вызывает:
- неправильные значения DB_* в wp-config.php
- база недоступна/перезапускалась
- неверные креденшелы
- исчерпание ресурсов (коннектов) на стороне MySQL
Израсходована память (Allowed memory size)
Где искать:
- php-fpm error log и/или wp-content/debug.log
- иногда Nginx error.log показывает upstream “выпал”
Что делать:
- увидеть конкретный message об Allowed memory size
- оценить, какой компонент потребляет память (плагин, импорт, генерация контента)
- проверить лимиты PHP-FPM/pool и настройки memory_limit
Важно: попытка “в лоб увеличить лимит” иногда маскирует проблему в коде, но для быстрой диагностики это приемлемый шаг.
Проблемы прав на файлы и директории
Симптомы:
- не удаются обновления WordPress
- плагины не могут записать кэш/файлы
- ошибки при генерации миниатюр или обновлении тем
Где проявляется:
- php-fpm error log (warnings/failed to open stream)
- wp-content/debug.log
- системные логи, если есть ошибки I/O
Что проверить:
- владельца и права на wp-content и поддиректории
- права на директорию uploads
- наличие в логах текстов вроде Permission denied, Failed to write, cannot open
Ошибки обновлений и миграций базы
При обновлениях ломается иногда не сам WordPress, а миграция структуры БД или запись опций. Ищи:
- php-fpm error log — ошибки кода обновления/миграции
- MySQL/MariaDB error log — проблемы с ALTER/CREATE
- cron логи — если обновления инициируются фоновой задачей
Если проблема возникла после обновления конкретного плагина, лог почти всегда покажет его путь/класс.
Ошибки почты/cron (Scheduled events)
Симптомы:
- регистрационные письма не уходят
- запланированные задачи не выполняются
- рассылки “зависают”
Где смотреть:
- системные логи cron
- логи mail transfer agent (если настроено) — зависит от вашей инфраструктуры
- WordPress debug.log — иногда фиксирует сбои планировщика
Если cron в VPS отключен или не настроен, WordPress может показывать, что “задачи не выполнялись”.
Практические приёмы чтения логов на VPS
Когда логов много, важна фильтрация. Иначе ты увидишь лишь “стену текста”.
Фильтрация по IP, URL и статус-коду
Для access.log удобно фильтровать по URI или статусу.
Пример: найти все 500 по определенному пути (замени URI): «`bash
- sudo grep » 500 » /var/log/nginx/access.log: grep «/wp-admin»; tail -n 50
«`
Если известен IP пользователя: «`bash
- sudo grep «IP_ПОЛЬЗОВАТЕЛЯ» /var/log/nginx/access.log: tail -n 50
«`
Поиск по ошибке: grep по FATAL, PHP Parse error
После воспроизведения ошибки найди точные строки в PHP логах:
«`bash
- sudo grep -i «fatal» /path/to/php-fpm-error.log: tail -n 50
«`
«`bash
- sudo grep -i «parse error» /path/to/php-fpm-error.log: tail -n 50
«`
Если используется journald:
«`bash
- journalctl -u php-fpm —since «30 minutes ago» —no-pager: grep -i «fatal\; parse error\; memory»
«`
Копирование фрагмента лога для анализа
Когда нужно показать информацию разработчику или себе завтра, не копируй “весь лог”. Выбери короткий фрагмент:
- 50–200 строк вокруг ошибки
- плюс 1–2 минуты до нее (там часто контекст)
Команда для Nginx error.log: «`bash sudo sed -n ‘1000,1100p’ /var/log/nginx/error.log > log_excerpt.txt «`
Точные номера строк ты берешь после просмотра хвоста и поиск по времени.
Управление ротацией и размером: logrotate и место на диске
Если логи “исчезли”, проблема может быть не в том, что ошибки не было, а в том, что лог ротирован и текущая запись ушла в архив.
Проверь:
- наличие .gz архивов
- не заполнен ли диск на VPS
Быстрая проверка места: «`bash df -h «`
Проверка текущего размера логов: «`bash sudo du -sh /var/log/nginx /var/log/php* 2>/dev/null «`
И еще момент: если disk full случился в момент проблемы, симптомы на PHP и WordPress могут выглядеть как “не могу писать файлы” или “фатал без явного контекста”.
Чего избегать при работе с логами
Логи — это мощный инструмент, но у него есть типичные ловушки.
Не оставлять WPDEBUGDISPLAY включенным
Если включал WPDEBUGDISPLAY ради проверки, выключи его после диагностики. Это снижает риск утечки внутренних путей и деталей ошибок наружу.
Обычно оставляют:
- WPDEBUGLOG = true
- WPDEBUGDISPLAY = false
Не хранить секреты в логах
Иногда в логах встречаются заголовки запросов, токены, куки или параметры. Это зависит от настройки приложений и прокси.
Проверяй, нет ли в логах:
- Authorization
- cookies с сессионными данными
- секретов из URL
Если лог нужно переслать, вырежь чувствительное или используй фрагменты вокруг ошибки без лишнего контента.
Не перезапускать сервисы вслепую
Перезапуск php-fpm или веб-сервера может:
- стереть часть “живых” подсказок из journald (если настроена агрегация)
- привести к новым ошибкам
- скрыть первичную причину, если проблема в конфиге
Когда нужно срочно стабилизировать сайт, перезапуск допустим, но параллельно сохраняй контекст: хвост логов и время события.
Не пропустить права доступа к лог-файлам
WordPress и сервисы должны иметь право писать в нужные директории и лог-файлы. Если debug.log не создается, чаще всего причина в правах на wp-content.
Если php-fpm не пишет error_log, проверь права на файл и владельца, а также корректность пути в конфиге пула.
Заключение: план диагностики за 30 минут
Если тебе нужно быстро разобраться с ошибками WordPress на VPS, используй короткий план вместо хаотичного просмотра файлов:
- Зафиксируй время и симптом. Снова воспроизведи ошибку и держи рядом окно с просмотром логов.
- Проверь веб-сервер: Nginx error.log/error или Apache error_log. Ищи записи за пару минут до момента, когда ты открыл страницу.
- Открой PHP-FPM логи: по пути error_log или через journalctl. Сопоставь время и найди Fatal/Parse/memory messages.
- Включи WPDEBUGLOG при необходимости и проверь wp-content/debug.log. Это дает точку внутри WordPress/плагина.
- Если причина не в PHP-коде, проверь MySQL/MariaDB error log и системные логи: диск, OOM, сеть, cron.
Сделай это один раз по каждому типу симптома (500, белый экран, ошибки базы) — и дальше диагностика будет занимать намного меньше времени.