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

Ошибка 500 Internal Server Error означает, что сервер получил запрос, но не смог его обработать из-за внутренней ошибки. Браузер, поисковый робот или API-клиент видят только код 500, а причина скрыта в логах приложения, веб-сервера или инфраструктуры.

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

Разберём, что означает HTTP 500, чем он отличается от других ошибок 5xx, как быстро найти причину и что делать разработчику, DevOps-инженеру или владельцу сайта.

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

HTTP-статус 500 Internal Server Error входит в группу серверных ошибок 5xx: запрос дошёл до сервера, но серверная сторона не смогла вернуть корректный ответ.

Упрощённая цепочка:

Клиент отправляет запрос: открывает страницу, вызывает API, отправляет форму.
Веб-сервер или reverse proxy принимает запрос.
Запрос передаётся приложению — PHP, Node.js, Python, Go, Java, CMS или фреймворку.
Внутри приложения происходит сбой.
Клиент получает HTTP/1.1 500 Internal Server Error.

Типичный ответ:

HTTP/1.1 500 Internal Server Error
Content-Type: text/html

Для API:

{
  "error": "Internal Server Error"
}

Код 500 не объясняет причину — он только сообщает, что серверная часть не справилась с обработкой запроса. Поэтому разбираться нужно не в браузере, а в логах.

Общая карта статусов — в справочнике всех кодов ответов HTTP.

Как ошибка 500 выглядит для пользователя и поисковых систем

Для пользователя ошибка 500 обычно проявляется так:

белая страница с текстом Internal Server Error;
стандартная страница Nginx, Apache, IIS или хостинга;
сообщение «На сайте произошла критическая ошибка»;
JSON-ответ API с 500;
бесконечная загрузка, если фронтенд не обработал ошибку;
сбой при оплате, авторизации, отправке формы или загрузке файла.

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

Разовый 500 не катастрофа. Опасны:

массовые ошибки на многих URL;
повторяющиеся сбои после деплоя;
ошибки только для ботов;
ошибки на страницах входа, оплаты, корзины, API;
кратковременные сбои, которые никто не замечает без мониторинга.

Для таких случаев помогает мониторинг доступности: например, Statuser может проверять сайт с заданным интервалом и присылать уведомление, если вместо 200 OK начал возвращаться 500.

Чем 500 отличается от 502, 503 и 504

Ошибки 500, 502, 503 и 504 часто путают, хотя источник проблемы у них разный.

500 Internal Server Error — приложение или сервер обработали запрос с внутренним сбоем. Самый общий код: «что-то сломалось внутри».

502 Bad Gateway — прокси или балансировщик получил некорректный ответ от upstream-сервера, например Nginx не смог договориться с backend-приложением. Подробнее: ошибка 502 Bad Gateway.

503 Service Unavailable — сервис временно недоступен: перегрузка, технические работы, остановленное приложение или отсутствие здоровых backend-нод. Подробнее: ошибка 503 Service Unavailable.

504 Gateway Timeout — прокси не дождался ответа от upstream: приложение могло зависнуть, долго выполнять SQL-запрос или ждать внешний API. Подробнее: ошибка 504 Gateway Timeout.

Границы условны: один и тот же баг может проявиться как 500, если ответ вернуло само приложение, или как 502/504, если сбой увидел reverse proxy.

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

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

Самая распространённая причина — необработанное исключение: TypeError, NullPointerException, KeyError, обращение к несуществующему полю, ошибка сериализации JSON, некорректная работа с датами или кодировками, падение обработчика формы, баг в middleware или в шаблонизаторе.

В production такие ошибки не должны показываться пользователю полностью: клиенту возвращается 500, а детали пишутся в лог.

Например, если API на Node.js не оборачивает асинхронные обработчики в try/catch или error middleware, исключение может завершить запрос с 500 или даже уронить процесс.

2. Ошибки после деплоя

Если 500 появился сразу после релиза, подозревайте изменения: новый код, миграции базы данных, обновление зависимостей, переменные окружения, новый Docker-образ, изменения конфигурации Nginx, Apache, PHP-FPM или systemd, несовместимость версии приложения и схемы БД.

Типичный сценарий: код уже ожидает колонку users.timezone, а миграция не применена — часть страниц падает с 500. Другой вариант: переменную DATABASE_URL переименовали, приложение стартует, но при первом запросе не может подключиться к БД.

3. Недоступна база данных

Приложение часто возвращает 500, если не может выполнить запрос к базе. Причины: база не запущена, неверные host, port, login или password, закончились доступные соединения, слишком долгий SQL-запрос, дедлоки, ошибка миграции, переполненный диск с данными или WAL/binlog, база доступна только из другой сети.

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

Для диагностики смотрите логи приложения и СУБД, метрики соединений, latency запросов, блокировки и ошибки аутентификации.

4. Неверные права на файлы и директории

Для сайтов на PHP, CMS и фреймворках частая причина 500 — права доступа: приложение не может записать в storage/, cache/ или logs/, веб-сервер не может прочитать файл, владелец файлов изменился после деплоя, директории имеют слишком строгие права, SELinux или AppArmor блокирует доступ.

На Linux стоит проверить пользователя, от которого работает приложение (www-data, nginx, apache, deploy), владельца файлов через ls -la, права на директории и логи Nginx, Apache, PHP-FPM.

Не решайте всё командой chmod -R 777 — это риск безопасности. Лучше выставлять минимально необходимые права и корректного владельца.

5. Ошибка конфигурации веб-сервера

Nginx, Apache, Caddy или IIS могут вернуть 500 из-за некорректной конфигурации: неправильный путь к backend-сокету, неверные директивы .htaccess, ошибка в rewrite-правилах, конфликт виртуальных хостов, неверная настройка FastCGI, проблемы с try_files, некорректные заголовки или кодировка, ошибка в include-файлах.

Для Apache чаще встречаются проблемы в .htaccess: запрещённые директивы, рекурсивные rewrite-правила, несовместимость с настройками хостинга. Для Nginx стоит смотреть error.log и проверять конфиг командой nginx -t.

6. Переполнен диск или inode

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

Проверить место:

df -h
df -i

df -h покажет занятое место, df -i — количество inode: свободные гигабайты могут быть, а inode закончиться из-за миллионов мелких файлов.

Отдельно стоит проверить /var/log, /tmp, /var/lib/docker, директории приложения и базы данных, папки с upload-файлами и кэшем.

Если логи растут бесконтрольно, настройте ротацию — подробнее в инструкции по logrotate для ротации и очистки логов.

7. Нехватка памяти и OOM Killer

Если приложение потребляет слишком много памяти, Linux может завершить процесс через OOM Killer. Снаружи это выглядит как 500, 502 или кратковременная недоступность.

Проверяйте dmesg, journalctl -k, логи systemd, рестарты контейнеров, docker inspect, метрики памяти, лимиты cgroups или Kubernetes.

Признаки: процесс периодически исчезает, контейнер получает OOMKilled, после рестарта сайт снова работает, ошибки появляются на тяжёлых запросах и усиливаются под нагрузкой.

Подробно механизм разобран в статье про OOM Killer в Linux.

8. Внешний сервис вернул ошибку

Приложение может отдавать 500, если зависит от внешнего API: платёжного провайдера, сервиса авторизации, SMTP, S3-хранилища, CRM, геокодинга, антифрода или внутреннего микросервиса.

Плохой вариант — когда любое падение внешнего сервиса превращается в 500 для пользователя. Лучше использовать таймауты, retries с ограничениями, circuit breaker, fallback-логику и понятные ошибки уровня приложения.

Например, если сервис рекомендаций недоступен, карточка товара не должна падать целиком — можно просто вернуть страницу без блока рекомендаций.

Как быстро проверить ошибку 500 снаружи

Начните с воспроизведения. Откройте URL в браузере и проверьте: ошибка возникает всегда или иногда, только на одной странице или на всём сайте, только после авторизации или для всех, зависит ли от параметров запроса, повторяется ли в другом браузере, появляется ли с мобильной сети или VPN.

Затем проверьте HTTP-ответ через curl:

curl -I https://example.com/

Для подробностей:

curl -v https://example.com/

Для API:

curl -X POST https://example.com/api/order \
  -H "Content-Type: application/json" \
  -d '{"productId":123}'

Смотрите статус ответа, заголовки, тело, редиректы, время ответа и различия между GET, POST, HEAD.

Если curl возвращает 500, проблема не в браузере. Подробнее о возможностях утилиты — в статье что такое curl и как им пользоваться.

Для владельца сайта без доступа к серверу минимальный набор действий такой:

Проверить, воспроизводится ли ошибка с разных сетей.
Вспомнить последние изменения: плагины, темы, деплой, настройки хостинга.
Проверить панель хостинга и логи ошибок.
Отключить недавно добавленные плагины или расширения.
Написать в поддержку хостинга с конкретным URL, временем ошибки и скриншотом.

Где искать причину на сервере

1. Логи веб-сервера

Для Nginx обычно смотрят /var/log/nginx/error.log, /var/log/nginx/access.log и отдельные логи virtual host, если они настроены.

tail -f /var/log/nginx/error.log
tail -f /var/log/nginx/access.log

Ищите строки с нужным временем, URL и IP. В access.log будет статус 500, а в error.log — более полезная причина: upstream error, permission denied, rewrite loop, FastCGI issue.

Для Apache: /var/log/apache2/error.log, /var/log/apache2/access.log, на некоторых дистрибутивах — /var/log/httpd/error_log.

2. Логи приложения

Приложение обычно знает больше, чем веб-сервер. Смотрите stack trace, имя исключения, request ID, user ID, endpoint, параметры запроса без чувствительных данных, версию релиза, ошибку подключения к БД, ошибки внешних API.

Типичные пути логов зависят от стека: Laravel — storage/logs/laravel.log, Symfony — var/log/prod.log, Django — настроенный handler логов, Rails — log/production.log, Node.js — stdout/stderr процесса, PM2 или Docker logs, Java — файлы приложения или journald, Go — stdout/stderr, journald или файлы логов.

Если приложение работает как systemd-сервис:

journalctl -u myapp.service -n 200 --no-pager
journalctl -u myapp.service -f

Подробный подход к системным логам — в материале про анализ логов с помощью journalctl.

3. Логи контейнеров

Если приложение в Docker:

docker ps
docker logs --tail=200 app
docker logs -f app

Проверьте рестарты:

docker ps -a
docker inspect app

Для Docker Compose:

docker compose ps
docker compose logs --tail=200 app
docker compose logs -f app

Обращайте внимание на Exited, Restarting, OOMKilled, ошибки переменных окружения, невозможность подключиться к БД, ошибки миграций.

Базовые команды — в шпаргалке по основным командам Docker.

4. Метрики сервера

Если в логах нет очевидной причины, проверьте ресурсы:

uptime
free -h
df -h
df -i
top

Смотрите load average, потребление CPU, свободную память, swap, диск, количество процессов, сетевые соединения, рестарты сервисов.

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

Пошаговый алгоритм диагностики

1. Зафиксируйте факт ошибки

Соберите минимум данных: URL, время с часовым поясом, HTTP-метод, статус, тело ответа, пользователя или тестовый аккаунт, request ID, если он есть, IP клиента, версию релиза.

Если ошибка кратковременная, без мониторинга её легко пропустить. Statuser в этом случае — внешний наблюдатель: он регулярно проверяет сайт и фиксирует момент, когда вместо успешного ответа появился сбой.

2. Определите масштаб

Ответьте на вопросы: падает весь сайт или один endpoint, ошибка у всех или только у части пользователей, проблема постоянная или периодическая, зависит ли от нагрузки, возникла ли после деплоя, есть ли корреляция с базой, очередями или внешними API.

Если падает только один URL, вероятнее баг в конкретном обработчике. Если весь сайт — смотрите инфраструктуру, конфигурацию, базу, процесс приложения.

3. Найдите точку, где появляется 500

Проверьте цепочку: клиент → CDN → балансировщик → Nginx/Apache → приложение → база/кэш/очередь/внешние сервисы.

Подсказки: стандартная HTML-страница Nginx — вероятно, веб-сервер; JSON в формате вашего API — вероятно, приложение; страница CMS — вероятно, CMS или плагин; ответ CDN — возможна ошибка на уровне edge или origin; если в access log Nginx есть 500, а в логах приложения пусто — запрос мог не дойти до приложения.

4. Сопоставьте логи по времени

Откройте одновременно access log, error log, application log, database log, логи контейнеров или systemd — и ищите одну и ту же временную точку. Хорошо, если в системе есть request ID или correlation ID: тогда один запрос можно проследить через несколько сервисов. Без него тоже можно работать — по времени, URL, IP, user agent и endpoint.

5. Проверьте последние изменения

Если ошибка началась недавно, составьте список изменений: релиз приложения, миграции, обновление пакетов, изменение секретов, изменение DNS или прокси, изменение лимитов, очистка или восстановление базы, обновление плагинов CMS, изменение конфигурации веб-сервера.

Быстрый rollback часто лучше долгого расследования на production, если ошибка массовая и влияет на пользователей.

6. Исправьте причину и проверьте регрессию

После исправления повторите запрос вручную, проверьте несколько проблемных URL, посмотрите логи на новые ошибки, убедитесь, что статус стал 200, 201, 204 или другим ожидаемым, проверьте фоновые задачи, очереди, cron, оставьте наблюдение на период пиковой нагрузки.

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

Как исправить ошибку 500 в популярных сценариях

Если проблема в коде

Найдите stack trace.
Воспроизведите ошибку локально или на staging.
Добавьте обработку исключения.
Исправьте входные данные, валидацию или бизнес-логику.
Напишите тест на проблемный кейс.
Задеплойте исправление.
Проверьте логи production.

Не подменяйте исправление общим try/catch, который скрывает ошибку и возвращает «успешный» ответ, — это только усложнит расследование.

Если проблема в базе данных

Проверьте доступность хоста и порта, credentials, лимит соединений, долгие запросы, блокировки, миграции, свободное место, состояние репликации, если она есть.

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

Если проблема в конфигурации

Для Nginx:

nginx -t
systemctl reload nginx

Для Apache:

apachectl configtest
systemctl reload apache2

Не перезапускайте сервис вслепую — сначала проверьте конфиг. Если ошибка из-за .htaccess, временно отключите подозрительные правила и возвращайте их по одному.

Если проблема в правах

Проверьте владельца и права:

ls -la

Для директорий, куда приложение пишет, обычно нужны права на запись пользователю процесса. Например, если PHP-FPM работает от www-data, директории storage и cache должны быть доступны этому пользователю.

Исправляйте точечно:

chown -R www-data:www-data storage cache

Команда примерная: имена директорий и пользователя зависят от проекта.

Если проблема после обновления CMS или плагина

Для WordPress, 1С-Битрикс, Joomla, Drupal и других CMS проверьте недавно установленные плагины, тему оформления, версию PHP, лимит памяти, .htaccess, права на файлы, логи хостинга, совместимость расширений.

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

Что не стоит делать при ошибке 500

Не включайте подробный debug для всех пользователей. Stack trace может раскрыть пути на сервере, переменные окружения, SQL-запросы, токены и внутреннюю структуру приложения.

Не чистите всё подряд. Очистка кэша, перезапуск сервера и удаление файлов без понимания причины может временно скрыть проблему или сделать хуже.

Не ставьте chmod 777. Это быстрый, но небезопасный способ: он может открыть запись туда, где её быть не должно.

Не игнорируйте единичные ошибки. Один 500 может быть началом деградации: утечки памяти, роста очереди, проблем с БД или нестабильного внешнего API.

Не возвращайте 200 OK при внутренней ошибке. Это ломает мониторинг, клиентов API и поисковых роботов: если запрос не обработан, статус должен отражать проблему.

Как снизить риск повторения ошибки 500

Полностью исключить 500 невозможно, но можно сделать их редкими, понятными и быстро устранимыми.

Полезные практики: централизованные логи с request ID, корректная обработка исключений, валидация входных данных, таймауты на внешние вызовы, лимиты retries, circuit breaker для нестабильных зависимостей, health checks, staging перед production, миграции с обратной совместимостью, rollback-план, мониторинг доступности и алерты, метрики 5xx, latency, saturation, ротация логов, резервные копии, контроль места на диске, ограничение ресурсов контейнеров.

Для API полезно отдельно отслеживать долю 5xx, latency и трафик по endpoint: если сервис возвращает 500 только на одном методе, общий uptime может выглядеть нормальным, но пользователи всё равно будут сталкиваться с ошибками.

Материалы про uptime monitoring и мониторинг HTTP API: RED-метрики, latency и error budget помогут выстроить наблюдаемость шире.

Короткий чеклист: что делать при ошибке 500

Проверить URL через браузер и curl.
Зафиксировать время, endpoint, метод, пользователя, request ID.
Понять масштаб: один URL, весь сайт, часть пользователей.
Проверить access log и error log веб-сервера.
Проверить логи приложения.
Проверить логи БД, очередей, внешних сервисов.
Проверить ресурсы: диск, память, CPU, load average.
Сопоставить ошибку с последним деплоем или изменением конфигурации.
Исправить причину или откатить релиз.
Проверить, что ошибки 500 больше не появляются в логах и мониторинге.

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

FAQ

Ошибка 500 — это проблема у меня или у сайта?

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

Можно ли исправить ошибку 500 перезапуском сервера?

Иногда перезапуск временно помогает — например, при зависшем процессе или утечке памяти. Но без анализа логов причина останется, и ошибка может вернуться.

Почему ошибка 500 появляется только иногда?

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

Что лучше возвращать пользователю вместо стандартной страницы 500?

Нейтральную страницу: «Произошла ошибка, мы уже разбираемся». Не выводите stack trace, SQL-запросы, пути к файлам и внутренние данные.

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