Ошибка 500 Internal Server Error: что это и как исправить

Что такое HTTP-ошибка 500?

HTTP-ошибка 500 (Internal Server Error) означает, что на веб-сервере что-то сломалось при обработке вашего запроса, а что именно, сервер не сообщил. Это самая общая ошибка сервера.

Стандарт HTTP определяет её одним предложением: «The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request» (RFC 9110 §15.6.1), то есть сервер столкнулся с неожиданным условием, которое не позволило ему выполнить запрос. В отличие от 503, эта ошибка ничего не говорит о том, временная ли проблема.

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

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

Текст зависит от сервера и приложения:

• 500 Internal Server Error — стандартная строка статуса
• 500 Internal Server Error с подписью «nginx» ниже — собственная страница ошибки nginx
• The server encountered an internal error or misconfiguration and was unable to complete your request. — страница Apache по умолчанию
• На сайте возникла критическая ошибка. — страница фатальной ошибки WordPress в том виде, как она показывается на русском (по-английски: «There has been a critical error on this website.»)
• HTTP Error 500.19 - Internal Server Error — IIS, где число после точки указывает причину (500.19: недопустимые данные конфигурации)
• Страница недоступна · Сайт example.com пока не может обработать этот запрос. · HTTP ERROR 500 — Chrome, когда у ответа 500 нет собственной страницы
• Request failed with status code 500 — Axios и другой JavaScript-код, который вызывает API
• 500. That's an error. — собственная страница ошибки Google

Ошибка 500 Internal Server Error на nginx

Чаще всего nginx лишь передаёт дальше ошибку 500, которую вернуло приложение за ним (PHP-FPM, Node.js, Python); при PHP-FPM собственное сообщение об ошибке PHP попадает в лог nginx. В нескольких случаях nginx формирует 500 и сам. Строки в логе ошибок, которые стоит искать:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Источник: код самого nginx; упавший или перегруженный бэкенд даёт 502 или 504, а не 500.)

Распространённые причины HTTP-ошибки 500

Ошибку 500 могут вызвать десятки проблем на стороне сервера. Самые частые:

• Сломанный файл .htaccess — одна недопустимая директива или неверная RewriteRule заставляет Apache отвечать 500 для этого каталога и всего, что ниже.
• Фатальные ошибки PHP — синтаксические ошибки, неперехваченные исключения или вызовы неопределённых функций останавливают скрипт.
• Лимиты памяти и времени PHP — скрипт, превысивший memory_limit (по умолчанию 128M) или max_execution_time (30 секунд), останавливается.
• Строки php_value на сервере с PHP-FPM — они работают только с mod_php в Apache; при PHP-FPM Apache отвергает их с ошибкой 500.
• Неверные права доступа к файлам — PHP не может прочитать подключаемый файл, либо хостинг с suPHP/suEXEC отказывается работать с файлами, доступными на запись всем (777). (Файл, который не может прочитать сам веб-сервер, даёт 403.)
• Плагин или тема — новое или обновлённое расширение WordPress, Joomla или Drupal, которое роняет весь сайт.
• Сбои подключения к базе данных — неверные учётные данные, остановленный сервер БД или слишком много соединений.
• Повреждённые файлы ядра — после неудачного обновления или прерванной загрузки.
• Заполненный диск — сервер не может записывать логи, сессии и временные файлы.
• Собственные причины nginx — цикл перезаписи, нечитаемый файл паролей или неудачная запись временного файла (часто из-за заполненного диска); см. раздел про nginx выше.

Как исправить ошибку 500 (для посетителей)

Если вы видите ошибку 500 на чужом сайте, проблема на стороне сервера, а не у вас. Тем не менее, есть несколько вещей, которые стоит попробовать.

• Один раз обновите страницу через минуту (F5 или Cmd+R на Mac). Многие ошибки 500 длятся ровно столько, сколько идёт деплой или перезапуск.
• Проверьте, не недоступен ли сайт для всех — Проверка доступности сайта открывает страницу из 11 мест, а Проверка HTTP-заголовков показывает точный код ответа, который получает наш сервер.
• Удалите cookie сайта или попробуйте приватное окно. Повреждённый cookie сессии может заставить некоторые приложения выдавать ошибку на каждой странице только у вас.
• Попробуйте позже — исправление делается на сервере, дайте владельцу время.
• Сообщите владельцу сайта, если ошибка держится несколько часов, указав адрес страницы и время, когда она возникла.

Способ 1: проверьте логи ошибок сервера

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

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Способ 2: проверьте и исправьте .htaccess

Сломанный файл .htaccess — классическая причина ошибок 500 на Apache: опечатка, неподдерживаемая сервером директива или неверная RewriteRule выводят каталог из строя. Лог ошибок Apache называет файл .htaccess и неверную директиву, например Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

Быстрее всего проверить это, временно переименовав файл. Если после переименования сайт загрузился, проблема была в .htaccess.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Способ 3: исправьте права доступа к файлам

Права доступа вызывают ошибку 500, когда PHP не может прочитать подключаемый файл, а также на хостингах с suPHP/suEXEC, которые отказываются работать с файлами, доступными на запись всем. Обычно ставят 644 для файлов и 755 для папок. Никогда не ставьте 777: это угроза безопасности, а на хостингах с suEXEC/suPHP оно само по себе вызывает 500.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Способ 4: увеличьте лимиты памяти и времени выполнения PHP

PHP останавливает скрипты, превысившие лимит памяти или максимальное время выполнения, и посетитель получает 500. Значения по умолчанию, 128M памяти и 30 секунд, для тяжёлых страниц часто слишком малы.

Увеличьте их там, где их читает ваш сервер. Для PHP-FPM отредактируйте php.ini для FPM (например, /etc/php/8.3/fpm/php.ini) и перезагрузите php-fpm; изменения в .user.ini могут вступать в силу до 5 минут.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Способ 5: отключите плагины и тему (CMS)

Если вы используете WordPress, Joomla или другую CMS, неисправный плагин или тема — одна из самых частых причин ошибки 500. Самый быстрый способ проверки — отключить все плагины разом, а затем включать их по одному.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Способ 6: проверьте подключение к базе данных и выполните восстановление

Ошибка 500 может возникнуть, когда приложение не может подключиться к базе данных. Это происходит при неверных учётных данных, упавшем сервере базы данных или повреждённых таблицах.

Сначала проверьте учётные данные базы данных в конфигурационном файле (wp-config.php для WordPress, .env для Laravel). Затем протестируйте соединение и при необходимости восстановите повреждённые таблицы.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Способ 7: проверьте совместимость версии PHP

Код, написанный для старой версии PHP, может вызывать фатальные ошибки на более новой (или наоборот). После обновления PHP обычные виновники — удалённые функции и изменившееся поведение; устаревшие функции вызывают лишь уведомления.

Проверьте, какую версию PHP ваш сайт использует на самом деле. php -v в командной строке может показать не тот PHP, что использует сайт, поэтому посмотрите ещё и в панели хостинга или на временной странице с phpinfo():

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Способ 8: проверьте дисковое пространство

Когда на сервере заканчивается место на диске (или inode), он не может записывать логи, временные файлы и данные сессий, и запросы начинают завершаться ошибкой 500.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 против 502, 503 и 504: в чём разница?

Главное различие: 500 = сервер сломался изнутри. 502 = прокси получил от бэкенда мусор. 503 = сервер жив, но занят. 504 = прокси перестал ждать. Точный код ответа вашего сервера можно проверить с помощью проверки HTTP-заголовков DNS Robot.

Если ошибка — это 502, приложение может быть в порядке, а проблема находится между прокси и приложением. Этот случай разбирает наше руководство по 502 Bad Gateway.

Как ошибки 500 влияют на SEO

Что происходит, описывает сама документация Google (документация Google о поисковых роботах):

• Сканирование замедляется. При ошибках 5xx Google снижает скорость сканирования сайта пропорционально числу URL, возвращающих ошибки.
• Сначала проиндексированные страницы остаются. Уже проиндексированные URL некоторое время сохраняются, но URL, которые стабильно возвращают ошибку сервера, удаляются.
• Восстановление идёт постепенно. Когда сервер снова отвечает кодом 2xx, Google постепенно наращивает сканирование.
• Для плановой остановки на день-два используйте 503 с заголовком Retry-After (Google), чтобы простой воспринимался как временный (руководство по 503).

Как предотвратить ошибки 500

Профилактика всегда лучше отладки. Следуйте этим лучшим практикам, чтобы минимизировать риск ошибок 500 на вашем сайте.

• Настройте мониторинг доступности — Используйте инструменты вроде UptimeRobot или Pingdom для проверки сайта каждые 1-5 минут. Получайте мгновенные оповещения при возникновении ошибки 500.
• Всегда тестируйте изменения на staging — Никогда не деплойте напрямую в продакшен. Тестируйте обновления плагинов, обновления PHP и изменения конфигурации сначала в staging-среде.
• Используйте систему контроля версий (Git) — Коммитьте каждое изменение, чтобы можно было мгновенно откатить неудачный деплой одной командой.
• Реализуйте правильную обработку ошибок — Оборачивайте запросы к базе данных и вызовы API в блоки try-catch. Логируйте полные стеки ошибок на сервере.
• Мониторьте дисковое пространство и ресурсы сервера — Настройте оповещения при использовании диска более 80%, высокой нагрузке на CPU и давлении на память.
• Обновляйте программное обеспечение — Устаревшие версии CMS, плагинов и серверного ПО содержат известные баги, вызывающие сбои.
• Обеспечьте автоматическое резервное копирование — Регулярно проверяйте процедуру восстановления. Бэкап, который вы ни разу не тестировали — не бэкап.
• Установите адекватные лимиты PHP — Настройте memory_limit и max_execution_time исходя из реальной нагрузки, а не значений по умолчанию.
• Используйте CI/CD-конвейеры — Автоматизируйте тестирование перед деплоем. Если тесты не прошли, деплой не должен выполняться.