Ошибка 500 Internal Server Error — внутренняя ошибка сервера

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

HTTP 500 — общий ответ: сервер получил запрос, но не смог его выполнить, а причина указана не в браузере, а в журнале ошибок. Для посетителя сделать почти ничего нельзя: можно обновить страницу и подождать. Владельцу сайта нужно искать запись в error.log веб-сервера или PHP — там почти всегда написана строка и файл, где произошёл сбой.

#Причины и решения

#Пошаговое решение

1. Подождите и обновитеЕсли вы просто посетитель сайта, подождите несколько минут и один раз обновите страницу клавишами Ctrl+F5. Попробуйте открыть главную страницу того же сайта. Ошибка 500 обычно возникает на сервере и не исправляется очисткой ваших паролей или переустановкой браузера; при повторении сообщите владельцу адрес страницы и время ошибки.
2. Откройте журнал ошибокДля владельца сайта. Откройте панель хостинга и найдите раздел «Журналы/Логи» для проблемного домена, затем посмотрите записи на момент ошибки. На собственном сервере журнал Apache часто расположен в /var/log/apache2/error.log, Nginx — в /var/log/nginx/error.log; фактические пути зависят от настройки виртуального хоста и PHP-FPM.
3. Найдите последнюю ошибкуДля владельца сервера. Получите из панели или настроек сайта точный путь к журналу PHP либо веб-сервера. Подключитесь по SSH и выполните sudo tail -n 80 /var/log/nginx/error.log только если этот журнал действительно используется; для Apache или PHP-FPM путь может отличаться. Найдите запись, совпадающую со временем ошибки, доменом и запросом; при наличии Fatal error запишите файл и строку. Не отправляйте полный журнал публично — там могут быть токены, пути и данные пользователей.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Это АЛЬТЕРНАТИВЫ для администратора Linux: используйте только журнал своего сервера (пути могут отличаться). Команды ничего не исправляют, только показывают сообщения; не выполняйте массовый chmod или chown. Синтаксис PHP проверяйте отдельно через CLI той же версии, что использует сайт.

   sudo tail -n 80 /var/log/nginx/error.log

   sudo tail -n 80 /var/log/apache2/error.log

4. Проверьте .htaccessЕсли ошибка появилась сразу после изменения .htaccess, сохраните резервную копию файла и временно верните его прежнюю рабочую версию. На Apache переименование файла может помочь проверить влияние правил, но на Nginx .htaccess вообще не обрабатывается. Не удаляйте правила безопасности и перенаправления без понимания последствий; после проверки восстановите нужные настройки.
5. Проверьте праваТолько администратору. Если журнал показывает Permission denied, выясните, какой конкретный файл или каталог недоступен и под каким пользователем работает PHP-FPM. Для диагностики используйте ls -ld для самого каталога и каждого родительского каталога и ls -l для файла. Сравните владельца и разрешения с рабочим соседним сайтом и документацией панели. Исправляйте только проблемный путь после резервной копии; не применяйте chmod -R, chown -R и 777 ко всему сайту.
6. Проверьте версию PHPЕсли ошибка появилась после переключения версии PHP, в панели хостинга посмотрите, какой обработчик и версия назначены домену. Проверьте совместимость кода и расширений, а затем откройте журнал PHP именно для этого сайта. Не меняйте версию сразу на всех сайтах; сначала устраните конкретную ошибку или безопасно вернитесь к предыдущей поддерживаемой конфигурации.
7. Отключите плагиныДля WordPress проверьте в журнале название сбойного дополнения. Если панель недоступна, через FTP можно временно переименовать папку только подозреваемого дополнения внутри wp-content/plugins, предварительно сохранив её копию. Это может отключить его функции; после проверки верните имя и исправьте или обновите дополнение штатно.
8. Увеличьте лимитыТолько администратору и только при подтверждённом исчерпании памяти. Если журнал содержит Allowed memory size exhausted, проверьте версию PHP и memory_limit для сайта в панели, а также доступную оперативную память и число процессов PHP. При достаточном ресурсе допустимо увеличить лимит для этого сайта в настройке обработчика PHP и повторить запрос, записав прежнее значение для отката. Если ошибка другая, менять лимит бессмысленно; при повторной нехватке памяти ищите причину расхода в коде.

После обновления CMS сначала сопоставьте время ошибки 500 с журналом PHP и изменёнными файлами; при необходимости восстановите конкретное неудачное обновление из проверенной резервной копии, а не всю систему наугад. Для WordPress отладку включайте лишь временно: в wp-config.php после резервной копии задайте WP_DEBUG и WP_DEBUG_LOG как true, а WP_DEBUG_DISPLAY как false; проверьте, что журнал wp-content/debug.log не доступен посторонним через веб. После диагностики выключите отладку и удалите конфиденциальные записи по правилам проекта. При нехватке места проверьте df -h и df -i.