Ошибка 500 Internal Server Error означает: сервер получил запрос, но не смог его выполнить из-за внутреннего сбоя. Иногда ошибка сопровождается дополнительным кодом в логе, но чаще сервер ограничивается только числом 500. Посетителю — не отправляйте повторно форму оплаты. Владельцу сайта — зафиксируйте время ошибки, проверьте код ответа и откройте error_log: там обычно указана причина — ошибка PHP, конфликт плагина, нехватка памяти, проблема с правами или базой данных.
Что означает ошибка 500 на сайте
Код 500 относится к классу 5xx — серверным ошибкам, и именно так чаще всего описывают любой серверный сбой: «ошибка 500» стала общим ярлыком, даже когда причина технически другая. Запрос дошёл до сервера, но сервер не смог его корректно обработать. В отличие от кода 404, где проблема в адресе страницы, или 403, где не хватает прав доступа, ошибка 500 — это признак внутренней неполадки на стороне сервера, приложения или базы данных.
Что делать прямо сейчас:
Ошибка может быть кратковременной, поэтому не спешите с резкими мерами.
- Обычному посетителю. Обновите страницу через 1–2 минуты. Если ошибка повторяется на разных устройствах и в разных браузерах — сайт недоступен не только у вас. Не отправляйте форму оплаты повторно: если деньги списались, а страница показала ошибку 500, повторная отправка может привести к дублированию платежа.
- Владельцу малого бизнеса. Проверьте, доступен ли сайт с телефона через мобильный интернет — это исключит проблему локальной сети. Если ошибка подтвердилась, зафиксируйте точное время и сообщите разработчику или в поддержку хостинга.
- Вебмастеру. Откройте сайт в режиме инкогнито, проверьте несколько разных URL и вспомните последнее изменение — обновление плагина, темы, ядра CMS или правку .htaccess.
- Разработчику. Получите фактический код ответа через curl -I https://адрес-сайта и сразу переходите к серверному логу за нужную минуту.
Основные технические причины возникновения ошибки сервера 500
Плоский список причин мешает диагностике — полезнее группировать их по уровню, на котором возник сбой.
- Изменения в коде. Синтаксическая ошибка в теме, плагине или кастомном модуле после правки файлов вручную или через FTP.
- Конфигурация сервера. Некорректные директивы в .htaccess, ошибки в конфигурации виртуального хоста Apache или Nginx, неверные правила переадресации.
- CMS и плагины. Конфликт между плагинами, несовместимость плагина с новой версией ядра CMS, повреждённый файл после неполного обновления.
- Ограничения ресурсов. Превышение лимита памяти PHP (memory_limit), превышение времени выполнения скрипта (max_execution_time), нехватка места на диске.
- База данных. Недоступность сервера базы данных, повреждённые таблицы, исчерпание лимита подключений.
- Права и файлы. Неверные права доступа к файлам и папкам, из-за которых веб-сервер не может их прочитать или выполнить.
- Внешние сервисы. Сбой стороннего API, платёжного шлюза или сервиса доставки, к которому обращается сайт при обработке запроса.
- Инфраструктура. Nginx работает, но PHP-FPM или другой процесс, обрабатывающий динамические страницы, не отвечает или перегружен; исчерпан пул воркеров.
Как проверить логи ошибок сервера для поиска точной проблемы
Совет «посмотрите error_log» бесполезен без объяснения, что именно искать. Алгоритм такой:
- Зафиксируйте точное время появления ошибки.
- Воспроизведите её ещё раз, чтобы получить свежую запись.
- Откройте лог за этот временной интервал — через панель хостинга, FTP/SFTP или SSH.
- Найдите строку, помеченную как error или fatal, рядом с нужной меткой времени.
- Свяжите запись с конкретным файлом и строкой кода.
Пример записи в PHP-логе:
PHP Fatal error: Call to undefined function old_function()
in /var/www/site/wp-content/plugins/example/example.php:42
Пример записи в лог ошибок Nginx — официальная документация Nginx описывает уровни журналирования, включая warn и crit, а также отдельный отладочный журнал:
[crit] 1234#0: *5 connect() failed (111: Connection refused)
while connecting to upstream, upstream: «fastcgi://127.0.0.1:9000»
Таблица типовых записей:
| Запись в логе | Что обычно означает | Следующий шаг |
|---|---|---|
| PHP Fatal error | Ошибка в коде PHP | Открыть файл и строку, проверить последнее изменение |
| Allowed memory size exhausted | Исчерпан лимит памяти PHP | Найти тяжёлый процесс, затем поднять memory_limit |
| Permission denied | Недостаточно прав на файл | Проверить владельца и права доступа |
| Invalid command | Ошибка директивы Apache | Проверить .htaccess или конфигурацию хоста |
| No space left on device | Закончилось место на диске | Проверить занятое место и очистить логи или кеш |
| Connection refused | Не отвечает внутренний сервис | Проверить статус PHP-FPM, приложения или базы данных |
| upstream timed out | Внутренний сервис отвечает слишком медленно | Проверить нагрузку и тайм-ауты |
Не публикуйте строки из лога с паролями, токенами или путями сервера в открытых источниках — это риск безопасности, а не просто техническая деталь.
Проблемы с файлом конфигурации .htaccess как самый частый источник сбоев
Файл .htaccess часто становится причиной ошибки 500 после ручного редактирования, установки плагина безопасности или SEO-плагина, который сам дописывает в него правила. Ошибка здесь чаще всего связана именно с этим файлом — сервер тут обычно ни при чём. Типичная ситуация — лишняя или неверная директива RewriteRule, дублирующийся блок правил или опечатка в модуле, который не подключён на сервере.
Безопасный протокол проверки:
- Сделайте копию текущего файла .htaccess перед любыми изменениями.
- Переименуйте .htaccess (например, в .htaccess_old) и обновите страницу.
- Если сайт заработал — проблема подтверждена, причина в файле.
- Восстановите содержимое CMS по умолчанию через админку или официальную документацию, а не через случайный сниппет из статьи.
- Меняйте только одну директиву за раз и проверяйте результат после каждого шага.
Важно: .htaccess — механизм именно Apache, официальная документация описывает его как файл конфигурации на уровне каталога (per-directory configuration). У Nginx нет собственного механизма для чтения .htaccess: этот файл там попросту не учитывается сервером. Поэтому если хостинг работает на Nginx, искать причину нужно не в .htaccess, а в конфигурации виртуального хоста (server block).
Превышение лимитов памяти PHP (memory_limit) и времени работы скриптов
Ошибка 500 может появляться, когда скрипту не хватает выделенной оперативной памяти или он выполняется дольше разрешённого времени. Это подтверждается записью Allowed memory size exhausted в логе PHP.
Что проверить:
- Значение директивы memory_limit в php.ini или в настройках панели хостинга.
- Значение max_execution_time — время, отведённое на выполнение одного скрипта.
- Какой именно процесс потребляет память: тяжёлый импорт данных, генерация отчёта, необработанный цикл в коде.
Повышение лимита памяти без выяснения причины — временная мера, а не решение. Если после увеличения лимита ошибка исчезает, но через некоторое время нагрузка снова растёт, это признак утечки памяти в коде плагина или неоптимизированного запроса к базе данных, а не признак того, что сайту нужен более мощный тариф.
Ошибка 500 после обновления CMS: конфликт плагинов, модулей или тем оформления
Это один из самых частых сценариев в WordPress и других CMS с модульной архитектурой. После обновления ядра, плагина или темы сайт показывает белый экран или ошибку 500.
Инструкция для WordPress, в том числе без доступа в админку:
- Подключитесь по FTP/SFTP или через файловый менеджер панели хостинга.
- Переименуйте папку конкретного плагина в wp-content/plugins/ — например, добавьте суффикс _disabled.
- Обновите страницу. Если ошибка исчезла — плагин найден.
- Если проблема не в одном плагине, временно переименуйте всю папку plugins и включайте плагины по одному, проверяя сайт после каждого.
- Аналогично проверьте активную тему через папку wp-content/themes/, временно переключившись на стандартную тему CMS.
Не удаляйте файлы сразу — только переименовывайте или перемещайте, чтобы иметь возможность откатить изменение. И не включайте подробный вывод ошибок PHP (display_errors) на рабочем сайте для всех посетителей — это временная диагностическая мера только для разработчика, а не постоянная настройка, так как она раскрывает пути и структуру сервера.
Как проверить права доступа к файлам (chmod 644) и папкам (chmod 755) сайта
Веб-сервер не может выполнить файл или прочитать папку, если права доступа настроены неверно. Стандартная практика для большинства хостингов на Linux:
- Файлы — права 644 (владелец читает и пишет, остальные только читают).
- Папки — права 755 (владелец читает, пишет и заходит в папку, остальные читают и заходят).
- Исполняемые скрипты, например CGI, могут требовать отдельных прав — уточняйте у конкретного хостинга.
Слишком открытые права (777) — это не решение, а риск безопасности: любой процесс на сервере получает возможность изменить файл. Проверить и изменить права можно через файловый менеджер панели хостинга или командой chmod по SSH, указав точный путь к файлу или папке.
Что делать вебмастеру, если не удается исправить ошибку самостоятельно
Если внутренней диагностики и быстрых проверок недостаточно, чтобы исправить ошибку 500 самостоятельно, следующий шаг — грамотное обращение в поддержку хостинга или к разработчику. Подготовьте:
- точный домен и URL, на котором возникает ошибка;
- время появления ошибки по московскому времени;
- ошибка постоянная или периодическая;
- что делали непосредственно перед сбоем;
- текст записи из error_log;
- версию PHP и используемую CMS;
- результат команды curl -I для проверенного URL;
- скриншот ошибки.
Это ускоряет диагностику в разы по сравнению с обращением в формате «сайт не работает, помогите».
Чем 500 отличается от 502, 503 и 504
Все эти коды относятся к серверным ошибкам, но означают разное:
| Код | Значение |
|---|---|
| 500 | Внутренняя ошибка сервера или приложения без уточнения причины |
| 502 | Сервер-посредник получил некорректный ответ от вышестоящего сервера |
| 503 | Сервис временно недоступен — перегрузка или технические работы |
| 504 | Вышестоящий сервер не ответил вовремя — тайм-аут шлюза |
Как ошибка 500 влияет на позиции в поиске. Такая ошибка мешает индексации почти так же сильно, как отсутствие самой страницы. Яндекс Вебмастер напрямую сообщает, что страница с ответом 4xx или 5xx не участвует в поиске. Чем дольше и чаще поисковый робот получает код 5xx при обходе страницы, тем выше риск, что URL временно выпадет из индекса. Поэтому после устранения причины стоит проверить не только внешний вид страницы в браузере, но и фактический ответ сервера — например, через curl -I или инструменты Яндекс Вебмастера.
Чего не делать
Ошибка не пройдёт сама по себе, если не устранить её причину. Не перезагружайте сервер как первый способ диагностики — это скрывает причину, а не устраняет её. Не меняйте несколько настроек одновременно — тогда невозможно понять, что именно помогло. Не публикуйте логи с паролями и путями сервера в открытом доступе. Не считайте, что одна успешная загрузка страницы означает полное устранение проблемы: сохраните мониторинг доступности хотя бы на ближайшие часы.
Профилактика
Делайте резервную копию перед любым обновлением CMS, плагинов или тем. Обновляйте компоненты сайта по одному, а не все сразу. Настройте мониторинг доступности, чтобы узнавать об ошибке 500 раньше, чем о ней сообщат клиенты. Так сервер реже будет создавать неожиданности для посетителей, а ошибка — если всё же случится — будет замечена быстрее. Ведите короткий журнал изменений сайта — дата, что именно изменено, кто вносил правку — это резко сокращает время диагностики при следующем сбое.