Ошибка 500 Internal Server Error: как найти причину на сайте

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

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

Сначала определите масштаб сбоя

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

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

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

Проверьте фактический статус ответа

На локальном компьютере выполните один запрос к проблемной странице, заменив URL на свой. Команда не изменяет сайт и не выводит содержимое ответа:

curl -sS -D - -o /dev/null https://example.com/account/

-D - выводит заголовки, а -o /dev/null не печатает тело страницы. В первой строке ожидается 500. Запомните заголовки server, date и идентификатор запроса, если приложение его добавляет. Они помогают понять, какой узел ответил и какую запись искать.

Если curl получает 200, а браузер показывает ошибку, проверьте другой URL, авторизацию, cookie и запросы в инструментах разработчика. Возможно, падает не HTML-страница, а отдельный API-запрос.

Найдите компонент, который сформировал 500

Типичный сайт состоит из Nginx, приложения или PHP-FPM и базы данных. Nginx может вернуть 500 сам либо передать такой статус от приложения. На VPS сначала посмотрите активные журналы Nginx:

sudo nginx -T 2>/dev/null | grep -E 'error_log|access_log|fastcgi_pass|proxy_pass'
sudo tail -n 100 /var/log/nginx/error.log

Первая команда читает собранную конфигурацию и показывает фактические пути журналов и способ передачи запроса. Вторая читает стандартный error log. Не публикуйте полный вывод nginx -T: в конфигурации могут быть внутренние адреса и другие служебные данные.

Ищите запись с тем же временем и URL. Сообщение Nginx может указывать на цикл внутренних перенаправлений, неверную директиву, отказ доступа или ошибку FastCGI. Если Nginx лишь передал ответ 500, переходите к журналу приложения.

Проверьте службу приложения до перезапуска

Если приложение запущено как systemd-служба, подставьте настоящее имя вместо myapp.service:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service --since "15 minutes ago" --no-pager

systemctl status показывает, работает ли процесс и не перезапускается ли он. journalctl раскрывает исключение, отсутствующую переменную окружения, ошибку подключения к базе или другую причину. Скопируйте несколько строк до и после сбоя, скрыв секреты.

Если приложение слушает локальный HTTP-порт, запросите его напрямую с VPS:

curl -v --max-time 5 http://127.0.0.1:3000/health

Замените порт и путь на значения из proxy_pass. Локальный 500 подтверждает проблему внутри приложения или его зависимостей. Локальный успешный ответ при внешнем 500 возвращает внимание к Nginx, заголовкам и отличиям публичного маршрута.

Сопоставьте ошибку с последним изменением

Вспомните, что менялось непосредственно перед сбоем:

• новый релиз приложения;
• конфигурация Nginx или PHP;
• переменные окружения;
• схема базы данных;
• версия плагина или темы;
• владелец и права файлов;
• свободное место на диске.

Не меняйте всё сразу. Если 500 появился сразу после релиза, безопаснее вернуть предыдущую известную рабочую версию и проверить ответ. Затем воспроизведите проблему на тестовой среде. Такой откат восстанавливает сервис и сохраняет одну понятную гипотезу.

Для конфигурации Nginx проверка обязательна до применения:

sudo nginx -t

Успешная проверка синтаксиса не гарантирует работу приложения, но исключает часть ошибок веб-сервера. При неуспехе не выполняйте reload: исправьте указанную строку или восстановите сохранённый файл.

Если сайт работает через PHP-FPM

Nginx передаёт PHP-файл отдельной службе PHP-FPM по TCP-порту или Unix-сокету. Уточните имя установленной службы, затем посмотрите её состояние и журнал. Например, для конкретной установленной версии команда может выглядеть так:

systemctl list-units --type=service 'php*-fpm.service'
sudo journalctl -u php8.3-fpm.service --since "15 minutes ago" --no-pager

php8.3-fpm.service здесь пример — используйте имя из первой команды. Ищите фатальную ошибку PHP, исчерпание памяти, недоступный файл, отказ базы данных или слишком долгий запрос.

В production подробности исключения не должны выводиться посетителю: они раскрывают пути и устройство приложения. Записывайте их в закрытый журнал, а пользователю отдавайте нейтральную страницу ошибки.

Не используйте права 777 как универсальное лечение

Если журнал содержит Permission denied, проверьте владельца файла и возможность пройти по каталогам:

namei -l /var/www/example/current/public/index.php

Команда ничего не меняет. Она показывает права каждого участка пути. Для чтения файла процессу нужны права чтения на сам файл и прохода по каталогам. Для загрузок WordPress запись обычно нужна только выделенному каталогу, а не всему коду сайта. Сначала определите пользователя процесса и требуемую операцию; только затем меняйте владельца или режим.

Проверьте ресурсы и внешние зависимости

Если журнал говорит об отсутствии места, памяти или соединения с базой, подтвердите именно этот симптом:

df -h
free -h
sudo ss -ltnp

df показывает заполнение файловых систем, free — память, ss — слушающие TCP-порты. Сами по себе высокие числа не доказывают причину 500; они должны совпасть со временем и текстом ошибки приложения.

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

Подтвердите исправление и сохраните возможность отката

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

curl -sS -D - -o /dev/null https://example.com/account/

Успех — это ожидаемый статус, отсутствие новой ошибки в журнале и работа соседнего сценария. Для формы выполните тест с безопасными данными; для страницы с базой проверьте чтение, а не только статический health endpoint.

Если ошибка осталась, верните последнее изменение и переходите к следующей подтверждённой гипотезе. При схеме с Nginx и приложением полезно отдельно понимать путь запроса через reverse proxy и уметь читать журналы Nginx. Если вместо 500 появился 502, используйте отдельную диагностику Bad Gateway.

Источники

• RFC 9110: 500 Internal Server Error
• Nginx: настройка журналов
• PHP: журналирование ошибок