500 Internal Server Error в WordPress: Полное руководство по диагностике

Ошибка 500 Internal Server Error — это универсальный ответ веб-сервера, означающий «что-то пошло не так, но я не знаю, что именно». В отличие от белого экрана смерти, который указывает на проблемы внутри WordPress, ошибка 500 часто возникает на уровне самого сервера (Apache, Nginx, LiteSpeed) из-за сбоя в конфигурации, исчерпания ресурсов или критической ошибки в коде.

В этом руководстве мы разберём системный подход к диагностике и устранению ошибки 500 в WordPress. Начнём с самых частых причин и перейдём к глубокому анализу логов.

Шаг 1: Проверка логов веб-сервера (самое важное)

Главное правило: никогда не гадайте, смотрите в логи. Текст ошибки на экране бесполезен, но лог сервера точно укажет на проблемный файл и строку.

Где найти логи:

  • Shared-хостинг: Панель управления хостинга (cPanel, ISPmanager) → раздел «Журналы ошибок» или «Error Log»
  • VPS/VDS на Apache: /var/log/apache2/error.log
  • VPS/VDS на Nginx: /var/log/nginx/error.log
  • LiteSpeed: /usr/local/lsws/logs/error.log

Как читать логи через SSH:

# Смотрим последние 20 строк лога в реальном времени
sudo tail -f /var/log/nginx/error.log

# Или ищем конкретную ошибку
grep -i "error" /var/log/apache2/error.log | tail -20

Если вы видите PHP Fatal error: Allowed memory size exhausted — переходите к Шагу 3. Если .htaccess: Invalid command — к Шагу 2.

Шаг 2: Исправление файла .htaccess (самая частая причина)

Битый или некорректный синтаксис в .htaccess — причина №1 ошибки 500 на серверах Apache. Достаточно одной опечатки, и весь сайт падает.

Как проверить:

  1. Подключитесь к сайту по FTP или через файловый менеджер хостинга
  2. Переименуйте файл .htaccess в .htaccess_backup
  3. Обновите сайт в браузере

Если ошибка 500 исчезла, проблема была в нём. Создайте новый .htaccess со стандартными правилами WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Если вы используете Nginx (как в нашем руководстве по reverse proxy), файл .htaccess игнорируется, и ошибку нужно искать в конфигах виртуальных хостов (/etc/nginx/sites-available/).

Шаг 3: Исчерпание лимита памяти PHP

Тяжёлые плагины, импорт больших файлов или неоптимизированные запросы могут превышать memory_limit. Сервер принудительно убивает процесс, что браузер воспринимает как ошибку 500.

// Добавьте в wp-config.php перед строкой "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Если это не помогает, значит, лимит жёстко задан на уровне сервера. Подробно разобрали все способы увеличения лимита в статье про настройку memory_limit в PHP.

Шаг 4: Проверка прав доступа к файлам и папкам

Веб-сервер должен иметь право читать файлы и заходить в папки. Если права слишком открытые (например, 777) или, наоборот, закрытые (000), сервер вернёт ошибку 500 или 403.

Правильные права для WordPress:

  • Папки: 755 (drwxr-xr-x)
  • Файлы: 644 (-rw-r--r--)
  • wp-config.php: 600 или 640 (для безопасности)

Как исправить через SSH (Linux):

# Переходим в корень сайта
cd /var/www/wordpress

# Выставляем правильные права на папки
find . -type d -exec chmod 755 {} \;

# Выставляем правильные права на файлы
find . -type f -exec chmod 644 {} \;

# Усиливаем защиту для wp-config.php
chmod 600 wp-config.php

# Меняем владельца на www-data (для Ubuntu/Debian)
chown -R www-data:www-data /var/www/wordpress

Важно: никогда не ставьте права 777. Это дыра в безопасности, и некоторые хостинги автоматически блокируют сайт с такими правами, выдавая 500-ю ошибку.

Шаг 5: Включение режима отладки WP_DEBUG

Если логи сервера молчат, включите встроенный отладчик WordPress. Он перехватит фатальные ошибки PHP и выведет их прямо на экран.

// В wp-config.php измените WP_DEBUG на true
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Не показывать посетителям
@ini_set( 'display_errors', 0 );

После этого обновите страницу с ошибкой 500. Текстовая ошибка появится на экране, а полный лог запишется в файл /wp-content/debug.log. После диагностики обязательно выключите режим отладки.

Шаг 6: Конфликт плагинов или темы

Плагины, которые пытаются выполнить некорректный PHP-код или SQL-запрос, могут вызывать фатальную ошибку. Мы подробно разбирали этот сценарий в статье про белый экран смерти — алгоритм отключения плагинов через FTP здесь абсолютно идентичен.

Шаг 7: Превышение лимита времени выполнения (max_execution_time)

Если ошибка 500 возникает только при загрузке больших файлов, импорте баз данных или работе тяжёлых скриптов, значит, PHP не успевает выполнить задачу за отведённое время (обычно 30 секунд).

; В php.ini или .user.ini
max_execution_time = 300
max_input_time = 300
max_input_vars = 3000

Нестандартные причины ошибки 500

Если базовые шаги не помогли, проверьте эти специфичные сценарии:

1. Ограничения модуля ModSecurity

На некоторых хостингах ModSecurity ошибочно блокирует легитимные запросы (например, сохранение настроек плагина безопасности) и возвращает 500-ю ошибку. Проверьте логи ModSecurity или отключите его временно для домена.

2. Неправильная версия PHP

Если хостинг обновил версию PHP (например, с 7.4 на 8.2), а ваш сайт использует устаревшие функции или плагины, возникнет фатальная ошибка. Проверьте версию PHP в панели хостинга и при необходимости откатите её назад.

3. Проблемы на стороне хостинга

Иногда ошибка 500 — это не ваша вина. Перегрузки на общем сервере, сбои MySQL или исчерпание ресурсов (Inodes) на тарифе Shared-хостинга. Если логи чистые, а сайт лежит — пишите в поддержку хостинга.

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

  • Проверить логи веб-сервера и PHP (error.log)
  • Переименовать .htaccess (для Apache)
  • Увеличить memory_limit в wp-config.php
  • Проверить права доступа (755/644)
  • Включить WP_DEBUG и проверить debug.log
  • Отключить все плагины через FTP
  • Проверить версию PHP на хостинге

Что делать, если проблема не решается?

Ошибка появляется только в админке

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

Сайт работает, но падает при высокой нагрузке

Это классический признак нехватки ресурсов. Если на Shared-хостинге лимиты исчерпаны, поможет только переход на VPS. После миграции правильно настройте стек (Nginx + PHP-FPM), чтобы сервер выдерживал пиковые нагрузки.

Ошибка возникает после обновления WordPress

Всегда делайте резервную копию перед обновлением. Если обновление сломало сайт, откатите файлы и базу данных через бэкап, затем обновляйте плагины и тему по одному на staging-копии.