Ошибка 500 (Internal Server Error): причины и решение

Что такое ошибка 500

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

Ключевое отличие ошибки 500 от других серверных ошибок — её неконкретность. Если код 502 говорит о проблеме во взаимодействии прокси-сервера с бэкендом, а 503 — о временной недоступности, то 500 — это универсальная «чёрная коробка»: «что-то сломалось внутри, но сервер не знает или не хочет говорить, что именно».

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

Что видит пользователь

В зависимости от браузера и настроек сервера текст отличается:

• Chrome и Edge: «На этой странице возникла ошибка сервера» / «Эта страница не работает».
• Firefox: «При загрузке страницы произошла ошибка».
• Safari: «Внутренняя ошибка сервера».

Общее у всех вариантов одно — код состояния 500. Он виден в инструментах разработчика браузера на вкладке Network, в логах веб-сервера и в ответах curl.

Почему возникает ошибка 500: основные причины

Причин у 500-й ошибки десятки, но почти все сводятся к нескольким классам проблем. Их удобно разбить по слоям: код приложения, конфигурация сервера, окружение (интерпретаторы, расширения) и права доступа.

Ошибки в коде приложения

Самая частая причина на динамических сайтах — необработанное исключение в PHP, Python, Node.js или другом бэкенде. Классический пример — обращение к несуществующему ключу массива, вызов неопределённой функции или синтаксическая ошибка в файле после правки «на живую».

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

Ошибки конфигурации

Некорректный файл .htaccess (Apache) или конфигурация nginx.conf, неверная директива, конфликт правил перезаписи URL — всё это даёт 500 без единой ошибки в коде приложения. Сюда же относятся ошибки в конфигурации PHP-FPM, превышение лимитов памяти и времени выполнения.

Проблемы окружения

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

Таблица причин

Как найти причину: диагностика по шагам

Ошибка 500 не показывает деталей посетителю, но на сервере подробности почти всегда есть. Задача — добраться до них.

Шаг 1. Смотрим логи веб-сервера

Первым делом открываем журнал ошибок. На типичном Linux-хостинге с Apache это /var/log/apache2/error.log или /var/log/httpd/error_log, для nginx — /var/log/nginx/error.log. Часто запись выглядит так:

tail -n 50 /var/log/nginx/error.log

Вывод может содержать строку вида:

PHP Fatal error:  Uncaught Error: Call to undefined function foo() in /var/www/site/index.php:42

Разберём построчно:

• PHP Fatal error — тип ошибки: фатальная, после неё скрипт останавливается, и сервер отдаёт 500.
• Call to undefined function foo() — суть: вызывается функция, которой не существует (не подключена библиотека, опечатка в имени или плагин не загружен).
• in /var/www/site/index.php:42 — точное место: файл и строка 42.

Этой записи достаточно, чтобы понять, что чинить.

Шаг 2. Включаем вывод ошибок (только временно)

Если лог пустой, а ошибка воспроизводится, включите отображение ошибок прямо в браузере. Для PHP добавьте в начало проблемного скрипта:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

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

Шаг 3. Проверяем синтаксис без запуска

Если вы правили PHP-файл, проверьте его синтаксис командой, не запуская сайт:

php -l /var/www/site/index.php

Ответ No syntax errors detected означает, что синтаксис в порядке и проблема не в этом файле. Ответ вида Parse error: syntax error, unexpected '}' укажет строку с ошибкой.

Шаг 4. Проверяем сайт снаружи через curl

Полезно понять, что именно отдаёт сервер внешнему клиенту. Команда:

curl -I https://example.com/

Флаг -I запрашивает только заголовки ответа. Вывод покажет первую строку со статусом:

HTTP/1.1 500 Internal Server Error

Если нужно увидеть ещё и тело ответа (иногда там бывает текст ошибки), используйте:

curl -v https://example.com/ 2>&1 | head -n 40

Разбор: -v включает подробный вывод, 2>&1 перенаправляет его в стандартный поток, head -n 40 показывает первые 40 строк — статус, заголовки и начало тела.

Отдельно стоит проверить, не зависит ли ошибка от метода запроса и от того, кто обращается. Иногда 500 отдаётся только поисковому роботу или только для POST-запросов.

Типичные случаи и их решения

WordPress: «Белый экран» и 500

WordPress — самая массовая платформа, поэтому на неё приходится большая доля 500-х. Классический сценарий: после обновления плагина или темы сайт показывает пустую белую страницу.

Алгоритм действий:

1. Включите режим отладки, добавив в wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Здесь WP_DEBUG_LOG пишет ошибки в файл wp-content/debug.log (виден только вам), а WP_DEBUG_DISPLAY не выводит их посетителям.

1. Откройте wp-content/debug.log и найдите запись об ошибке — обычно она указывает на конкретный плагин или тему.

2. Отключите подозрительные плагины, переименовав папку плагина через FTP/SSH:

mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name.bak

Если сайт заработал — виновник найден.

1. Отдельно проверьте .htaccess — WordPress перезаписывает его при смене настроек постоянных ссылок, и повреждённый файл даёт 500. Простейшее решение — зайти в админку «Настройки → Постоянные ссылки» и сохранить без изменений, чтобы WordPress сгенерировал файл заново.

PHP-сайт: нехватка памяти

Частый случай — превышение лимита памяти:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Значение 134217728 — это 128 МБ в байтах. Решение: поднять лимит в php.ini или в начале скрипта:

ini_set('memory_limit', '256M');

Но сначала стоит понять, почему памяти не хватает: нередко виноват неэффективный SQL-запрос, который тянет в память всю таблицу. Оптимизация запроса лучше, чем бесконечное наращивание лимита.

Права доступа к файлам

Неправильные права тоже дают 500, особенно после ручного переноса файлов. Стандартные значения для большинства сайтов:

find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

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

Конфликт версий PHP

После обновления PHP с 7.x на 8.x часть старого кода перестаёт работать: в PHP 8 удалены некоторые функции и ужесточена типизация. Типичная запись в логе:

PHP Fatal error: Uncaught Error: Call to undefined function each()

Функция each() удалена в PHP 8 — код, который на неё опирался, теперь падает с 500. Решение — обновить устаревший код или временно вернуть прежнюю версию PHP в панели хостинга.

Как быстро заметить ошибку 500: мониторинг

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

Здесь полезен регулярный внешний мониторинг доступности. Проверить, как сайт отвечает прямо сейчас, можно в инструменте проверки доступности сайта — он делает запрос к указанному URL и показывает, какой код статуса возвращает сервер, а также доступность по основным протоколам.

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

Профилактика: чтобы 500 не возвращалась

Устранить одну ошибку — полдела. Важнее выстроить практику, при которой 500 появляется редко, а если появляется, то быстро ловится.

• Тестируйте изменения на стейджинге. Правки на живом сайте «по-быстрому» — главный источник 500. Заведите отдельную копию, проверяйте там.
• Держите резервные копии. Снимок базы и файлов перед каждым обновлением CMS, темы или плагинов позволяет откатиться за минуты.
• Следите за логами. Разбирайте error.log регулярно, а не только когда сайт упал: многие проблемы «тлеют» в виде предупреждений задолго до фатальной ошибки.
• Обновляйте окружение осознанно. Перед сменой версии PHP проверьте совместимость кода и плагинов.
• Контролируйте ресурсы. Нехватка дискового пространства и памяти — типичная фоновая причина 500. Настройте уведомления о превышении порогов.
• Проверяйте после развёртывания. После каждого релиза прогоняйте ключевые страницы через инструмент проверки доступности, чтобы убедиться, что сервер отдаёт 200, а не 500.

Отдельный класс инструментов — внутренний мониторинг инфраструктуры, например Zabbix. Он следит за состоянием серверов изнутри: нагрузка на CPU, память, диски, работа служб. Это другой уровень, чем внешняя проверка доступности сайта: Zabbix отвечает на вопрос «здоров ли сервер», а внешний мониторинг — на вопрос «виден ли сайт пользователю из интернета и какой код он отдаёт». Эти подходы дополняют друг друга: внутренний сигнализирует о причине, внешний — о том, что проблема уже отразилась на посетителях.

Соседние серверные ошибки

Ошибка 500 — лишь одна из группы 5xx. Полезно различать их, чтобы точнее понимать, что происходит:

• Ошибка 502 Bad Gateway — прокси-сервер не получил корректный ответ от бэкенда. Частая причина — упавший PHP-FPM или медленный upstream.
• Ошибка 503 Service Unavailable — сервер временно не может обработать запрос: перегрузка, плановое обслуживание или недоступный бэкенд.

Если сайт отдаёт 500, а не 502 или 503, это обычно значит, что проблема не в связке «прокси — приложение», а непосредственно в самом приложении или его окружении.

Коротко

Ошибка 500 означает «сервер принял запрос, но упал при обработке». Причина почти всегда находится в логах: там фиксируются фатальные ошибки PHP, нехватка памяти, проблемы прав доступа и конфигурации. Алгоритм диагностики прост: прочитать error.log, при необходимости включить временный вывод ошибок, проверить синтаксис через php -l, изолировать проблемный файл или плагин.

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