Что вообще значит HTTP 500
Когда браузер отправляет запрос серверу, тот должен ответить числовым кодом. Двухсотые коды — всё хорошо. Четырёхсотые — проблема на стороне пользователя (например, 404 — страница не найдена). А пятисотые — это сервер признаётся: «Я не справился, но сам не понимаю почему».
Код 500 — самый общий из пятисотых. Он не говорит ничего конкретного. Это как если бы врач сказал: «Вы больны» — и на этом закончил приём. Поэтому вся задача сводится к тому, чтобы найти настоящую причину, которая скрывается за этим безликим сообщением.
Первое, что нужно сделать: открыть логи
Это правило номер один. Какой бы ни была CMS, какой бы ни был хостинг — логи ошибок содержат ответ в 90% случаев.
Где их искать:
- На обычном shared-хостинге — в панели управления (cPanel, ISPmanager, Plesk) в разделе «Логи» или «Журнал ошибок»
- На VPS/VDS — файл `/var/log/apache2/error.log` для Apache или `/var/log/nginx/error.log` для Nginx
- В WordPress можно включить дебаг-режим через wp-config.php
- В Битрикс — смотрим `/bitrix/modules/main/include.php` и лог в `/bitrix/`
Открываем лог, ищем записи за последние минуты. Обычно там чёрным по белому написано: какой файл, какая строка, какая ошибка. Дальше — дело техники.
Как включить отображение ошибок в WordPress
Если сайт на WordPress и вы видите белый экран или лаконичное «500 Internal Server Error», полезно временно включить отладку. Для этого нужно открыть файл `wp-config.php` в корне сайта и найти строку:
define('WP_DEBUG', false);Меняем `false` на `true` и добавляем ещё две строки:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Теперь ошибки пишутся в файл `wp-content/debug.log`, но не показываются посетителям. Это безопасный вариант для рабочего сайта. После того как нашли причину — не забудьте вернуть `WP_DEBUG` обратно в `false`.
Самые частые причины ошибки 500
Вот практический чек-лист. Когда сайт выдаёт «ошибка 500» — стоит мысленно пройти по этим пунктам.
Проблема в .htaccess
Это причина номер один на сайтах, работающих под Apache. Файл `.htaccess` — по сути набор инструкций для веб-сервера. Одна лишняя буква, незакрытая директива или несуществующий модуль — и весь сайт отвечает пятисоткой.
Что делать: подключиться к серверу по FTP или SSH, переименовать `.htaccess` в `.htaccess_backup` и обновить страницу. Если сайт заработал — значит, дело в этом файле. Дальше открываем его и ищем проблемную строку.
Типичные ошибки в `.htaccess`:
- Использование `mod_rewrite` при отключённом модуле на сервере
- Синтаксические ошибки после ручного редактирования (забытый `</IfModule>`)
- Бесконечные редиректы, когда правило перенаправляет страницу саму на себя
- Директивы `php_value` или `php_flag` на серверах, где PHP работает через FastCGI (там эти директивы запрещены)
В WordPress после удаления `.htaccess` можно пересоздать его через «Настройки → Постоянные ссылки» — просто нажмите «Сохранить изменения», и WordPress сгенерирует новый чистый файл.
Сломанный плагин или тема
Классическая ситуация: владелец сайта обновил плагин — и всё упало. Или установил новую тему, которая конфликтует с текущей версией PHP.
Подход: если админка WordPress недоступна, заходим через FTP в папку `wp-content/plugins` и переименовываем её, например, в `plugins_off`. Все плагины разом деактивируются. Если сайт оживает — возвращаем оригинальное имя папки и начинаем включать плагины по одному через админку, пока не найдём виновника.
С темами аналогично: переименовываем папку активной темы — WordPress автоматически откатится на стандартную.
Нехватка памяти PHP
PHP-скрипты потребляют оперативную память. Если лимит слишком низкий, а скрипт пытается обработать что-то тяжёлое (импорт товаров, генерация отчёта, обработка изображений) — сервер возвращает ошибку 500.
Проверить текущий лимит можно так:
<?php phpinfo(); ?>Создаёте файл `info.php` с этой строкой в корне сайта, открываете его в браузере и ищете строку `memory_limit`. На shared-хостингах часто стоит 128 МБ или даже 64 МБ — для современного WordPress с десятком плагинов этого может не хватать.
Увеличить лимит можно несколькими способами — в зависимости от хостинга:
# В .htaccess (Apache + mod_php)
php_value memory_limit 256M
# В php.ini или .user.ini
memory_limit = 256M
# В wp-config.php (только для WordPress)
define('WP_MEMORY_LIMIT', '256M');Права доступа к файлам
На Linux-серверах у каждого файла и папки есть права доступа (chmod). Если они выставлены неправильно, веб-сервер просто не может прочитать или выполнить нужные файлы.
Стандартные права для большинства CMS:
- Папки: 755
- Файлы: 644
- `wp-config.php` (WordPress): 600 или 640
Массово исправить права можно по SSH:
find /path/to/site -type d -exec chmod 755 {} \;
find /path/to/site -type f -exec chmod 644 {} \;Никогда не ставьте 777 на файлы и папки. Да, это «решает» проблему с правами, но создаёт серьёзную дыру в безопасности.
Ошибки в PHP-коде
Банальная опечатка, незакрытая скобка, вызов несуществующей функции — всё это приводит к 500-й ошибке, если на сервере отключено отображение ошибок (а на рабочих сайтах оно и должно быть отключено).
Если вы недавно редактировали какой-то файл вручную — начните с него. Откройте и перепроверьте последние изменения. Для таких случаев всегда стоит держать git или хотя бы делать бэкап файла перед правкой.
Проблемы с базой данных
Повреждённые таблицы в MySQL тоже приводят к ошибке 500. Особенно часто это случается после аварийного отключения сервера или при переполнении диска.
В WordPress можно включить встроенный режим восстановления базы. Добавьте в `wp-config.php`:
define('WP_ALLOW_REPAIR', true);Затем откройте `yoursite.com/wp-admin/maint/repair.php`. После восстановления — обязательно удалите эту строку из конфига.
Ошибка 500 в Битрикс: отдельная история
Битрикс — это отдельный мир со своими особенностями. Когда сайт на 1С-Битрикс выдаёт 500, стоит проверить несколько специфичных вещей.
Первое — версия PHP. Битрикс исторически имеет жёсткие требования к версии. Если хостер обновил PHP с 8.1 до 8.3, а модули Битрикса ещё не адаптированы — сайт ложится. Решение: откатить версию PHP в панели хостинга или обновить ядро Битрикса.
Второе — файл `.settings.php` и `dbconn.php`. Если в них неверные данные для подключения к базе, Битрикс иногда выдаёт именно 500, а не понятное сообщение об ошибке соединения.
Третье — переполнение папки `/bitrix/cache/` или `/upload/`. На больших интернет-магазинах кэш может разрастись до нескольких гигабайт. Если на диске кончается место, сервер не может создать временные файлы — и падает с 500.
Четвёртое — агенты. В Битрикс есть система фоновых задач (агенты). Если какой-то агент «зависает» или вызывает фатальную ошибку — он может блокировать загрузку всего сайта. Иногда помогает принудительная очистка таблицы `b_agent` через phpMyAdmin, но делать это нужно аккуратно.
Ошибка 500 на Nginx без Apache
Если сайт работает на чистом Nginx (без Apache в связке), то `.htaccess` роли не играет — Nginx его просто игнорирует. Здесь ошибка 500 чаще всего связана с:
- Неправильной конфигурацией Nginx (`/etc/nginx/sites-available/`)
- Проблемами PHP-FPM: процесс упал, переполнился пул воркеров, закончилась память
- Слишком большим телом запроса при загрузке файлов (директива `client_max_body_size`)
- Таймаутами при обращении к бэкенду
Диагностика та же — логи. Только теперь смотрим два лога параллельно: Nginx error log и PHP-FPM log (обычно `/var/log/php-fpm/error.log` или `/var/log/php8.x-fpm.log`).
Когда 500-я ошибка появляется периодически
Самый коварный случай — когда сайт работает нормально, но иногда, под нагрузкой или в определённое время, начинает отдавать 500. Вот что обычно бывает:
- Заканчиваются свободные PHP-FPM воркеры при всплеске трафика. Решение — увеличить `pm.max_children` в конфигурации пула или перейти на более мощный тариф
- Cron-задачи создают пиковую нагрузку. Тяжёлая переиндексация или рассылка совпадает с часом пик посещений
- Утечка памяти в PHP-скриптах. Длительно работающий процесс постепенно съедает всю память
- Лимиты хостинга. На shared-хостинге провайдер может ограничивать число процессов, CPU-time, количество одновременных подключений к базе. При превышении — 500
Для диагностики таких случаев стоит поставить мониторинг. Можно использовать простой скрипт на cron, который каждую минуту проверяет доступность сайта и записывает результат. Или подключить внешние сервисы вроде UptimeRobot — он бесплатно мониторит до 50 адресов и присылает уведомления при падении.
Чек-лист: быстрая диагностика ошибки 500
Рекомендуемый порядок действий:
- Открыть лог ошибок сервера — в 90% случаев ответ будет там
- Переименовать `.htaccess` (если сервер Apache) — проверить, не в нём ли дело
- Отключить плагины/модули — поочерёдно, чтобы найти конфликтующий
- Проверить версию PHP — убедиться, что CMS поддерживает текущую версию
- Проверить свободное место на диске (`df -h` по SSH)
- Проверить права на файлы (755 для папок, 644 для файлов)
- Проверить подключение к базе данных
- Откатить последние изменения, если помните, что меняли
Как обезопасить себя от ошибки 500
Полностью застраховаться невозможно, но можно свести риски к минимуму.
Регулярные бэкапы — это святое. Автоматическое резервное копирование файлов и базы данных минимум раз в сутки. На критичных проектах — каждые 6 часов. Многие хостинги делают бэкапы сами, но полагаться только на них не стоит — лучше хранить копию отдельно.
Обновления CMS и плагинов — не откладывать надолго, но и не применять бездумно. Сначала обновить на тестовой копии или staging-сервере, убедиться, что ничего не сломалось, и только потом — на боевом сайте.
Мониторинг — настроить оповещения о падении сайта. Чем быстрее узнаете о проблеме, тем меньше посетителей увидят ошибку.
Staging-окружение — тестовая копия сайта, на которой можно безопасно экспериментировать. Если что-то пойдёт не так, рабочий сайт не пострадает.
Когда стоит обратиться к специалисту
Если описанные выше шаги кажутся сложными — это нормально. Ошибка 500 по своей природе требует технической диагностики. Нет ничего страшного в том, чтобы обратиться к специалисту.
Обязательно стоит привлечь разработчика, когда:
- Ошибка появляется после миграции сайта на другой сервер
- Проблема связана с конфигурацией Nginx или PHP-FPM
- Сайт на Битрикс с кастомными модулями
- Ошибка плавающая и воспроизводится только под нагрузкой
- Вы не уверены в своих действиях и боитесь сломать что-то ещё
Обычно опытному разработчику достаточно 10–30 минут, чтобы найти и устранить причину. Это быстрее и безопаснее, чем разбираться самостоятельно методом проб и ошибок.