Ошибки сервера 5xx: как диагностировать и исправить

Когда сайт вместо долгожданной страницы выдает «500 Internal Server Error» или «502 Bad Gateway», это всегда стресс. Особенно для того, кто этот сайт делает или поддерживает. Самое неприятное в ошибках 5xx — они говорят, что проблема на сервере, но почти никогда не объясняют, что именно сломалось.

В этой статье разберем пять самых популярных кодов из серии 500: 500, 501, 502, 503 и 504. Узнаем, откуда они чаще всего берутся, как их диагностировать, и главное — что сделать, чтобы сайт снова работал.

Что вообще значат все эти 500, 502, 503…

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

Протокол HTTP использует коды состояния, чтобы сервер мог объяснить браузеру, как прошел запрос. Код 200 — отлично, страница загружена. 404 — страница не найдена. А все коды, начинающиеся с пятерки, — это сигнал SOS: «На сервере что-то сломалось, я не могу выполнить твой запрос». Детали часто скрыты, но сам факт принадлежности к классу 5xx сразу говорит, что копать нужно в сторону серверной части.

Вот краткий справочник по главным «пятисотым»:

• 500 (Internal Server Error). Универсальный солдат. Сервер столкнулся с неожиданной ситуацией и не знает, как на нее ответить. Может означать что угодно: от ошибки в коде сайта до проблем с настройками сервера. Это самая частая, но и самая коварная ошибка, потому что ее причина неочевидна.
• 501 (Not Implemented). «Я не умею такого». Сервер не поддерживает метод, который вы от него запросили. Например, если ваш сайт попытается отправить на сервер PATCH-запрос, а сервер о нем даже не слышал, он вполне может вернуть 501. На практике встречается нечасто.
• 502 (Bad Gateway). «Я тут посредник, и тот, от кого я ждал ответа, ответил какой-то ерундой». Ошибка возникает, когда один сервер (например, Nginx, выступающий в роли шлюза) не смог получить внятный ответ от другого сервера (например, от PHP-FPM или Apache). Классика для связок и сложных систем.
• 503 (Service Unavailable). «Извините, я сейчас очень занят/на техобслуживании, зайдите позже». Сервер временно не может обработать запрос из-за перегрузки или плановых работ. Это единственная ошибка 5xx, при которой пользователь может увидеть заголовок Retry-After, подсказывающий, когда стоит попробовать снова.
• 504 (Gateway Timeout). «Я тут посредник, и тот, от кого я ждал ответа, слишком долго думает». Ошибка похожа на 502, но в этом случае шлюз просто не дождался ответа от вышестоящего сервера в отведенное время.

Главная опасность этих ошибок не только в том, что пользователи не видят сайт. Поисковые системы тоже их видят.

Если боты Яндекса или Google при индексации регулярно натыкаются на 500-е ошибки, они могут снизить позиции сайта в выдаче или даже уменьшить частоту повторных визитов. Поэтому бороться с ними — задача не только техническая, но и SEO-шная.

500 Internal Server Error: главная головная боль

Эта ошибка — как чёрный ящик. Само сообщение не дает почти никакой информации, поэтому диагностика 500 всегда начинается с изучения логов.

Откуда берется:

1. Ошибки в скриптах сайта. Самая частая причина. Необработанное исключение в коде, синтаксическая ошибка, вызов несуществующей функции. Если сайт на PHP, то 500 — частый гость при фатальных ошибках.
2. Проблемы с файлом .htaccess (для Apache). Одна неверная директива или опечатка в этом файле — и весь сайт может лечь. Классический пример — неправильно составленное правило модерации (mod_rewrite). Это также частый момент, откуда исходит ошибка 500.
3. Неправильные права доступа. У файлов скриптов должны быть права 644, у папок — 755. Если они сбиты, веб-сервер может быть не в состоянии прочитать или выполнить нужный файл.
4. Превышение лимитов ресурсов. Слишком много запросов, нехватка памяти для выполнения скрипта, превышение времени выполнения (max_execution_time) — всё это может привести к 500.
5. Проблемы с подключением к базе данных. Если ваш код пытается выполнить запрос к БД, а сервер БД не отвечает или отвечает ошибкой, PHP-скрипт может упасть с 500.

Как диагностировать и исправить:

• Смотреть логи. Это первое и самое важное правило. Логи веб-сервера (Nginx или Apache) и логи PHP — ваши лучшие друзья. Именно там будет написано, что именно пошло не так.
• Проверить .htaccess. Если у вас Apache, временно переименуйте этот файл и проверьте, исчезла ли ошибка. Если да — значит, проблема в нем. Комментируйте строки в файле по одной, чтобы найти «битую» директиву.
• Включить отображение ошибок. Временно, для целей диагностики, можно включить вывод ошибок в самом скрипте, чтобы увидеть их на экране. Важно: никогда не оставляйте это включенным на рабочем сайте, так как это может раскрыть чувствительную информацию.
• Проверить права доступа. Убедитесь, что права на файлы и папки установлены корректно.
• Проверить лимиты PHP. Увеличьте memory_limit и max_execution_time в настройках PHP (например, через .htaccess или php.ini), если ошибка возникает на «тяжелых» скриптах.

502 Bad Gateway: сбой в коммуникации

Представьте: вы звоните в секретаршу и просите соединить вас с директором. Секретарша набирает номер, но вместо голоса директора слышит в трубке странный шум. Она не знает, что с этим делать, и сообщает вам: «Плохой шлюз». Вот это и есть 502.

Откуда берется:

1. Backend-сервер не работает. Например, Nginx не может соединиться с PHP-FPM, потому что PHP-FPM остановлен.
2. PHP-FPM перегружен. Слишком много входящих запросов, и демон не справляется, отвечая Nginx ошибкой или не отвечая вовсе.
3. Проблемы с настройками прокси. Неправильно указан upstream, неверные настройки таймаутов.
4. Слишком большой размер заголовков. Если ваш бэкенд отдает очень большие заголовки, а Nginx настроен на прием только маленьких, может возникнуть 502.

Как диагностировать и исправить:

• Проверить, запущены ли сервисы. Убедитесь, что бэкенд (PHP-FPM, Apache, Gunicorn и т.д.) работает и слушает нужный порт или сокет.
• Посмотреть логи бэкенда. Логи PHP-FPM или Apache часто содержат точную причину сбоя.
• Проверить настройки таймаутов. В конфигурации Nginx (proxy_read_timeout, fastcgi_read_timeout) можно увеличить время ожидания ответа от бэкенда. Это помогает, если скрипты работают долго.
• Проверить настройки буферов. Увеличьте размер буфера для заголовков и ответов (proxy_buffer_size, fastcgi_buffer_size).

503 Service Unavailable: сервер на пределе

Эта ошибка честно говорит: «Я бы с радостью тебя обслужил, но сейчас просто не могу». Это не всегда проблема, иногда это штатная ситуация.

Откуда берется:

1. Перегрузка сервера. Количество одновременных запросов превысило возможности сервера (не хватает оперативной памяти, процессорных ядер).
2. Исчерпание лимитов хостинга. На shared-хостинге у каждого пользователя есть квоты на использование ресурсов. Если ваш сайт их превысил, хостинг может начать отдавать 503.
3. Плановые технические работы. Администратор может сам перевести сайт в режим обслуживания.
4. DDoS-атака или резкий всплеск трафика. Это тоже формы перегрузки.

Как диагностировать и исправить:

• Определить, временный ли это сбой. Если ошибка появляется на короткое время и исчезает — возможно, это просто пик нагрузки.
• Проверить загрузку сервера. Если у вас есть доступ, посмотрите на загрузку CPU, использование оперативной памяти и дисковую активность.
• Оптимизировать код. «Тяжелые» скрипты, неэффективные запросы к базе данных — всё это создает нагрузку.
• Включить кэширование. Правильное кэширование может снизить нагрузку на сервер в разы.
• Рассмотреть апгрейд хостинга. Если вашему проекту стало тесно на текущем тарифе, возможно, пора переходить на VPS или выделенный сервер.

504 Gateway Timeout: ожидание затянулось

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

Откуда берется:

1. Долго выполняющийся скрипт. PHP-скрипт обрабатывает запрос 1-2 минуты, а Nginx по умолчанию ждет всего 60 секунд. Таймаут истекает — и пользователь видит 504.
2. Медленные запросы к базе данных. Сложный SELECT на несколько секунд может стать причиной таймаута, если бэкенд и Nginx не настроены соответствующим образом.
3. Зависший бэкенд. PHP-FPM повис и не отвечает на запросы Nginx.

Как диагностировать и исправить:

• Увеличить таймауты. В конфигурации Nginx увеличьте proxy_read_timeout, fastcgi_read_timeout. Это позволит долго работающим скриптам завершиться.
• Оптимизировать запросы. Найдите и ускорите медленные части приложения. Это поможет не только с ошибками, но и с общей скоростью работы.
• Проверить логи бэкенда. Если скрипты зависают, логи могут указать на конкретную причину.

Как быть, если ничего не помогло: план действий

Начните с логов. Всегда. Логи веб-сервера и приложения — это ваша карта.

Воспроизведите проблему. Попробуйте вызвать ошибку снова, используя curl для отправки HTTP-запроса из командной строки. Это покажет вам точный код и заголовки ответа.

Проверьте, не вносили ли вы недавно изменений. Не обновляли ли движок сайта? Не меняли ли настройки сервера? Часто проблема кроется в последнем изменении.

Отключите всё лишнее. Временно деактивируйте плагины, переименуйте .htaccess, переключитесь на стандартную тему. Если ошибка исчезнет — вы нашли виновника.

Обратитесь в поддержку хостинга. Если у вас нет доступа к управлению сервером или вы перепробовали всё — техническая поддержка хостинг-провайдера должна помочь, особенно если проблема на их стороне.

Краткий чек-лист для диагностики:

• 500 Internal Server Error: проверьте логи, права доступа, файл .htaccess, код скриптов.
• 502 Bad Gateway: проверьте, запущены ли бэкенд-сервисы (PHP-FPM), логи бэкенда, настройки прокси.
• 503 Service Unavailable: проверьте загрузку сервера, лимиты хостинга, нет ли DDoS-атаки или технических работ.
• 504 Gateway Timeout: увеличьте таймауты в настройках Nginx, оптимизируйте долгие запросы и скрипты.

Любая 5xx ошибка — это не просто досадная помеха, а сигнал о неполадке в серверной инфраструктуре или коде. Регулярно отслеживайте их появление (например, через Google Search Console), анализируйте причины и устраняйте их. Так вы сделаете сайт не только более надежным, но и сохраните его позиции в поиске.

Ошибки в .htaccess, ведущие к 5xx

Ниже я привел три распространённых примера из собственной практики, из-за которых сайт отдаёт ошибки 500, 502 или 503.

Бесконечный цикл редиректов (500 Internal Server Error):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.poznayu\.com [NC]
RewriteRule ^(.*)$ https://poznayu.com/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^poznayu\.com [NC]
RewriteRule ^(.*)$ https://www.poznayu.com/$1 [R=301,L]

Правила зацикливаются: первое правило убирает www., второе добавляет его обратно. Apache пытается обработать бесконечную цепочку и на определённом шаге прекращает выполнение, возвращая ошибку 500. Такой цикл легко создать, не заметив конфликт условий.

Неправильная директива php_value или php_flag (500):

php_value upload_max_filesize 2M
php_flag display_errors on

Эти директивы работают только при включённом модуле mod_php. Если сервер работает через PHP-FPM или FastCGI, Apache не может их обработать и падает с 500. Та же ошибка возникает при указании несуществующего параметра или синтаксической ошибке (например, пропущена кавычка).

Некорректный синтаксис в RewriteRule (500):

RewriteEngine On
RewriteRule ^article/([0-9]+)/?$ article.php?id=$1 [NC,L,FLAG]

Использование несуществующего флага FLAG (опечатка). Apache не понимает такую инструкцию и завершает обработку файла с ошибкой. Аналогично сработает лишняя запятая, незакрытая квадратная скобка или неэкранированный символ в регулярном выражении.

Ошибки в PHP при отправке заголовков

Ошибки в PHP редко вызывают 5xx напрямую, но при определённых условиях — вполне. Вот 5 характерных примеров из моей собственной практики.

Попытка отправить заголовок после вывода текста (500 или пустая страница):

echo "Привет, пользователь!";
header("Location: https://poznayu.com/new-page/");

Заголовки должны отправляться до любого вывода в браузер. PHP буферизует вывод, но если буферизация отключена (или данные уже отправлены), вызов header() после echo вызывает ошибку «Cannot modify header information». В зависимости от настроек сервера это может привести к 500 Internal Server Error или к тому, что страница просто перестанет загружаться.

Бесконечный редирект из-за неправильной логики в header():

if (strpos($_SERVER['REQUEST_URI'], 'step2') === false) {
header("Location: " . $_SERVER['REQUEST_URI'] . "?step2");
exit;
}

Код формирует новый URL, добавляя параметр, но если проверка не учитывает уже существующий параметр, скрипт может вызывать редирект снова и снова. Серверный цикл редиректов быстро превышает лимит (например, в Apache настраивается RedirectLimit) и обрывается с ошибкой 500 или 502. Пользователь видит «Too many redirects» или серверную ошибку.

Попытка установить слишком большой заголовок или с ошибкой в синтаксисе:

header("Set-Cookie: session=value; Max-Age=1000000000000000000000000000000");

Значение заголовка (например, время жизни куки) выходит за допустимые пределы. Веб-сервер или PHP не могут корректно сформировать ответ и завершают скрипт с фатальной ошибкой. Или, если заголовок содержит недопустимые символы (перевод строки внутри значения), сервер может отдать 500. В связке с Nginx + PHP-FPM такая ошибка часто превращается в 502 Bad Gateway, так как fastcgi не может прочитать ответ от PHP.

Ошибка подключения к базе данных без обработки исключений (500):

$pdo = new PDO('mysql:host=localhost;dbname=wrong_db', 'user', 'pass');
$pdo->query('SELECT * FROM users');

Если PDO не может подключиться из-за неверного имени базы данных, пароля или недоступности MySQL, он выбрасывает исключение PDOException. При стандартных настройках PHP это исключение не перехватывается, превращается в фатальную ошибку и приводит к 500 Internal Server Error. В логах появится запись «Uncaught PDOException». Особенно часто это встречается на сайтах, где параметры подключения хранятся в конфиге, а сам конфиг случайно повреждён или перезаписан.

Бесконечная рекурсия в функции (500):

function factorial($n) {
return $n * factorial($n - 1);
}
echo factorial(10);

В функции отсутствует условие выхода (if ($n <= 1) return 1;). Она вызывает саму себя бесконечно, пока PHP не достигнет лимита глубины рекурсии (по умолчанию 256). После этого скрипт завершается фатальной ошибкой «Maximum function nesting level reached». Веб-сервер возвращает 500 Internal Server Error. В логах ошибок PHP это сообщение будет явно указано. Такая ошибка часто возникает после рефакторинга кода, когда программист случайно удаляет базовый случай рекурсии.

Итан Картер

Я, Итан Картер – американский разработчик и технический автор с более чем 20-летним опытом в системном и прикладном программировании. Мой основной профиль — низкоуровневая разработка на Assembler: 22 года практики, включая глубокую работу с оптимизацией кода, архитектурой процессоров и производительностью критичных по скорости решений. Я защитил PhD dissertation по Assembler, а также более 18 лет работаю с ASP.NET, создавая корпоративные веб-системы, API и масштабируемые backend-решения.

Дополнительно я имею 9 лет опыта в C++ и C#, а также 7 лет практики программирования микроконтроллеров на Assembler. Благодаря моему сочетанию академической подготовки и прикладного инженерного опыта я могу писать статьи на стыке архитектуры ПО, низкоуровневой оптимизации и современной разработки, делая сложные технические темы понятными для профессиональной аудитории.