Ошибка 500: что это, почему возникает и как ее исправить

Вы заходите на свой сайт и вместо привычной страницы видите «500 Internal Server Error». Для многих начинающих администраторов эта ошибка становится головной болью: она не называет причину, может пропасть сама и вернуться через час, и одинаково выглядит и когда упал один плагин, и когда закончилось место на диске.

В этой статье разберём, что означает ошибка 500, откуда она берётся и — это главное — как найти причину и устранить её, с командами и путями к логам, которые нужны для диагностики.

Что означает ошибка 500

Ошибка 500 (Internal Server Error) — стандартный HTTP-код, который сервер возвращает, когда получил запрос, но не смог его обработать из-за внутреннего сбоя. Код относится к группе серверных ошибок (5xx) и остаётся самым общим в этой группе: в отличие от 404 (страница не найдена на стороне клиента), 500 указывает на проблему на сервере, но не говорит, в чём именно она заключается.

Сервер показывает такой код, когда для конкретной ситуации нет более точного (например, 502 или 503) и когда детали сбоя специально не выводятся наружу — чтобы не показывать посетителю путь к файлам или структуру базы данных.

В чём коварство ошибки 500

Она не называет место проблемы: причина может быть в коде, в .htaccess, в правах доступа, в базе данных или в закончившемся месте на диске. Появляется и пропадает она тоже без видимых действий с вашей стороны — например, после автоматического обновления плагина или после того, как вырос трафик и упёрся в лимит PHP. А поскольку одна и та же ошибка на экране может означать десяток разных причин на сервере, вслепую менять настройки бесполезно — сначала нужен лог.

Как выглядит ошибка 500

• Стандартная страница «500 Internal Server Error»
• белый экран без единого сообщения;
• брендированная страница ошибки в оформлении сайта;
• «Ошибка сервера» / «Server Error» / «HTTP Error 500».
• Ошибка может касаться одной страницы или всего сайта, появляться постоянно или спорадически — сайт то отдаёт страницы, то падает.

Что происходит с сервером при ошибке 500

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

Почему появляется ошибка 500

1. Ошибки в .htaccess. Некорректный синтаксис в этом файле — одна из самых частых причин, особенно сразу после того, как в него что-то дописали (правило редиректа, ограничение доступа). Актуально только для сайтов, которые работают через Apache: если у сайта в ispmanager выбран шаблон «только Nginx», .htaccess вообще не читается, и эту причину можно сразу исключить.

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

3. Конфликты плагинов и тем. На CMS вроде WordPress или Joomla несовместимый или устаревший плагин — частая причина, особенно после обновления CMS или самого плагина.

4. Превышение лимитов ресурсов: закончилась PHP-память (memorylimit), скрипт работал дольше, чем разрешает maxexecution_time, на диске не осталось места, либо сервер захлебнулся от трафика.

5. Неправильные права доступа на файлы и директории — например, файл недоступен для чтения тому пользователю, от имени которого работает PHP.

6. Проблемы с подключением к базе данных: неверные логин/пароль/хост в конфиге сайта или сам сервер БД не отвечает.

7. Обновление PHP. После смены версии PHP на хостинге старый код может обращаться к функциям, которых в новой версии уже нет (или ещё нет).

Чем опасна ошибка 500 для сайта

• Для посетителей сайт недоступен: нельзя посмотреть страницы, оформить заказ, прочитать статью — а значит, часть посетителей уходит и не возвращается.
• Поисковые роботы не индексируют страницу с кодом 500. Если ошибка массовая и держится долго, это сигнал технической проблемы для поисковика, который может отразиться на позициях сайта.
• Сайт, который время от времени «падает», вызывает меньше доверия — особенно если ошибка возникает у части посетителей регулярно, а не один раз.

Как продиагностировать и исправить ошибку 500

Для начала обновите страницу (F5) — иногда сбой разовый. Если не помогло, двигайтесь дальше. Большинство проблем устраняются после проверки логов и .htaccess.

1. Смотрим логи

Это главный источник информации, и в ispmanager у него точный адрес.

Лог ошибок конкретного сайта:

Debian/Ubuntu/CentOS

/var/www/httpd-logs/ВАШ_ДОМЕН.error.log 

FreeBSD      

/home/httpd-logs/ВАШ_ДОМЕН.error.log        

Через панель ispmanager тот же лог открывается в разделе Сайты → выбранный домен → Логи. По SSH — быстрее командой tail.

tail -n 100 /var/www/httpd-logs/example.ru.error.log
tail -f /var/www/httpd-logs/example.ru.error.log   # смотреть в реальном времени

Если ошибка не привязана к одному сайту, а падает весь сервер — смотрите общий лог веб-сервера:

tail -f /var/log/apache2/error.log     # Debian/Ubuntu
tail -f /var/log/httpd/error_log       # CentOS
tail -f /var/log/nginx/error.log       # Nginx на любой ОС

Если PHP на сайте работает через PHP-FPM, PHP-ошибки могут писаться не в error.log домена, а в лог самого пула PHP-FPM — путь к нему указан в конфиге пула (/etc/php-fpm.d/ для нативной версии PHP, /opt/php/etc/php-fpm.d/ — для альтернативных версий, которые ставились через ispmanager). Если файла с логом нет, проверьте системный журнал:

journalctl -u php-fpm -n 100 --no-pager

2. Проверяем .htaccess

Работает только для сайтов на Apache — на чистом Nginx этот шаг можно пропустить. 

Временно переименуйте файл и обновите страницу:

mv /var/www/user/data/www/example.ru/.htaccess /var/www/user/data/www/example.ru/.htaccess_old

Если сайт заработал, дело в .htaccess: возвращайте содержимое небольшими кусками, проверяя синтаксис перед каждым перезапуском:

apachectl configtest      # на Debian/Ubuntu — apache2ctl configtest

3. Проверяем права доступа

ls -la /var/www/user/data/www/example.ru/

Обычно нужно 644 для файлов, 755 для директорий, и владелец — системный пользователь сайта, а не root. Чтобы исправить, выполните,(вместо user подставьте системное имя владельца сайта). 

find /var/www/user/data/www/example.ru/ -type f -exec chmod 644 {} \;
find /var/www/user/data/www/example.ru/ -type d -exec chmod 755 {} \;
chown -R user:user /var/www/user/data/www/example.ru/

4. Проверяем скрипты и включаем отладку

Временно включите вывод ошибок. Если пользуетесь ispmanager, то так: Сайты → клик по нужному сайту → PHP → Значок шестиренок (Переход в первоначальную настройку PHP). Найдите и включите display_errors. На VPS с root-доступом то же самое можно прописать в пользовательском php.ini сайта:

display_errors = On
errorreporting = EALL

Обновите страницу. Вместо белого экрана появится текст с файлом и строкой, где упала ошибка. После диагностики обязательно верните display_errors = Off: с включённым выводом посетители увидят пути к файлам на сервере.

Если сайт работает через PHP-FPM, проверьте заодно, жив ли сам процесс:

systemctl status php-fpm        # нативная версия PHP
systemctl status php7.4-fpm     # если ставили конкретную версию через ispmanager — имя сервиса зависит от версии

Упавший PHP-FPM — частая причина 500, которую легко пропустить, если смотреть только в код.

5. Отключаем плагины и тему

Для WordPress, если админка недоступна из-за той же ошибки отключите плагины через SSH и WP-CLI:

wp plugin deactivate --all --path=/var/www/user/data/www/example.ru
wp theme activate twentytwentyfour --path=/var/www/user/data/www/example.ru

Без WP-CLI переименуйте папку плагинов:

mv wp-content/plugins wp-content/plugins_disabled
mkdir wp-content/plugins

Если сайт заработал, возвращайте плагины по одному (по одной папке), пока ошибка не появится снова — так вы найдёте виновника.

6. Проверяем подключение к базе данных

mysql -u ИМЯПОЛЬЗОВАТЕЛЯ -p -h localhost ИМЯБАЗЫ -e "SELECT 1;"

Если MySQL/MariaDB вообще не отвечает:

systemctl status mysql      # или mariadb — смотря что установлено

Сверьте логин, пароль, имя базы и хост в конфиге сайта (wp-config.php для WordPress, configuration.php для Joomla) с данными в разделе Базы данных в ispmanager.

7. Проверяем ресурсы сервера

df -h      # место на диске
free -m    # оперативная память

Если место кончилось не на самом диске, а в конкретной папке сайта, найдите, что его съело:

du -sh /var/www/user/data/www/*

Лимиты PHP смотрите там же, где меняли displayerrors: Сайты → домен → PHP → Расширенные настройки — там же memorylimit, maxexecutiontime, uploadmaxfilesize. Проверить текущие значения на VPS можно и так:

php -i | grep -E "memorylimit|maxexecution_time"

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