Что значат коды ошибок сервера: 404, 500, 502, 503

Код ответа — это трёхзначное число, которым сервер отвечает браузеру на каждый запрос, и по первой цифре сразу видно, кто виноват. Коды группы 4xx означают, что проблема в самом запросе или в правах доступа: страницы нет, пароль не подошёл, файл закрыт. Коды группы 5xx означают, что запрос был нормальный, а сломался сервер или приложение на нём. Это первое разделение экономит часы: при 404 бесполезно перезапускать сайт, а при 502 бесполезно править ссылки. Разбираться удобнее там, где есть доступ к логам, — на VPS для сайтов, а не на шаред-тарифе. Шаред-хостинг — это общий тариф, где на одном сервере живут сотни чужих сайтов, и консоли с логами вам там не дают.

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

Что такое код ответа и почему их разделили на пять групп

Каждый раз, когда браузер запрашивает страницу, сервер отвечает служебной строкой вида HTTP/1.1 200 OK. Первое, что в ней важно, — число. Оно не описывает проблему детально, но точно указывает класс ситуации, а класс определяется первой цифрой.

Групп пять, и они не равны по частоте. Коды 1xx владелец сайта почти никогда не видит: это технические промежуточные ответы. Коды 2xx — нормальная работа, их видно только в логах. Реально разбираться приходится с тремя группами: 3xx, 4xx и 5xx.

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

Как увидеть код ответа своими глазами, а не гадать по белой странице

Браузер часто прячет число за красивой заглушкой: показывает «Ошибка соединения» или пустой экран. Чтобы получить настоящий ответ, нужен запрос без оформления. Самый быстрый способ — утилита curl, она есть в любом дистрибутиве Linux и в macOS, а в Windows входит в состав системы с версии 10.

Первая команда запрашивает только заголовки, без тела страницы. Ключ -I означает «покажи заголовки», в первой же строке ответа будет искомое число.

curl -I https://example.com/

Вторая команда полезнее для диагностики: она молча скачивает страницу в никуда и печатает только код и время ответа в секундах. Ключ -o /dev/null выбрасывает содержимое, -s убирает индикатор загрузки, -w задаёт формат вывода.

curl -o /dev/null -s -w "%{http_code} %{time_total}n" https://example.com/

Если в ответ приходит 504 30.012, вы сразу знаете две вещи: код и то, что сервер думал ровно 30 секунд. Ровная цифра — признак таймаута, то есть ограничения по времени; 30 секунд обычно означает лимит выполнения PHP-скрипта. Для массовой картины смотрят access-лог — файл, куда веб-сервер пишет строку про каждый запрос. Команда ниже берёт девятое поле строки (это и есть код ответа) и считает повторы.

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Двенадцать кодов, которые покрывают почти все реальные случаи

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

В таблице ниже колонка «Куда смотреть» — не рекомендация на всякий случай, а буквально первый файл или настройка, которую открывают в этой ситуации. Более подробный разбор отдельных номеров есть в нашем справочнике HTTP-кодов.

301, 302 и 304: перенаправления, которые ошибками не являются

Группа 3xx пугает новичков зря. Это не поломка, а указание браузеру сходить по другому адресу или взять страницу из своего кэша. Проблемы начинаются только тогда, когда редиректов слишком много или они закольцованы.

Код 301 — постоянный переезд. Поисковые системы переносят на новый адрес накопленные сигналы, поэтому 301 ставят при смене домена, переходе на HTTPS или при склейке адреса со слэшем и без. Код 302 — временный переезд: сигналы остаются на старом адресе, и это правильный выбор для акций, технических страниц и A/B-тестов.

Код 304 отвечает на условный запрос и означает «с прошлого раза ничего не поменялось, бери из кэша». Тело страницы при этом не передаётся, поэтому ответ весит десятки байт вместо сотен килобайт. Много 304 в логе — хороший признак, а не повод для тревоги.

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

curl -sIL https://example.com/staraya-stranica | grep -E "HTTP/|location"

400, 401, 403, 404 и 429: сервер жив, но запрос ему не нравится

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

Код 400 приходит, когда запрос повреждён: слишком длинный URL, разросшиеся cookie, кривые заголовки от промежуточного оборудования. Обычно лечится очисткой cookie домена. Код 401 говорит, что ресурс закрыт и нужен пароль или токен — типичная история для админки за базовой авторизацией и для запросов к API без ключа.

Код 403 — самый неоднозначный. Сервер понял запрос, нашёл ресурс, но не отдаёт. Причин три: неверные права на файлы, явное запрещающее правило в конфигурации и срабатывание фильтра безопасности. Для сайта нормальные права — 644 на файлы и 755 на каталоги: владелец читает и пишет, все остальные, включая веб-сервер, только читают. После ручной загрузки по FTP часто оказывается 600 — это значит «доступ только владельцу», и веб-сервер перестаёт читать файл.

Код 404 означает, что по адресу ничего нет. У статического сайта это опечатка в ссылке, у CMS — почти всегда сломанные правила ЧПУ (человекопонятных адресов вида /catalog/noutbuki/). Причина обычно одна из двух: файл .htaccess удалён или в конфигурации nginx нет директивы try_files, которая передаёт неизвестные адреса скрипту CMS. Код 429 стоит особняком: сервер отвечает «слишком много запросов» и просит подождать. Его выставляет либо лимитер веб-сервера, либо защита от перебора, и в логе рядом всегда виден один адрес с сотнями обращений в минуту.

500, 502, 503 и 504: четыре ошибки сервера, которые видят чаще всего

Пятая группа — единственная, где виноват сервер. Ошибки сервера 500, 502, 503 и 504 различаются не тяжестью, а тем, на каком участке цепочки оборвалась работа. Это различие сразу подсказывает, какой лог открывать.

Код 500 — внутренняя ошибка приложения. Веб-сервер запустил PHP, тот выполнялся и упал: синтаксическая ошибка после правки файла, обращение к несуществующей функции, отказ подключения к базе данных, исчерпание лимита памяти. Белая страница появляется потому, что вывод ошибок на продакшене отключён, и текст уходит в лог. Как временно включить показ сообщений, расписано в отдельной инструкции про вывод ошибок PHP.

Код 502 означает, что веб-сервер обратился к бэкенду и получил в ответ невнятицу или обрыв соединения. Бэкенд — это программа, которая собирает страницу: обычно PHP-FPM, служба, выполняющая PHP-код по запросам веб-сервера. Чаще всего падает именно её процесс, реже — приложение на Node.js или Python, которое перестало слушать свой порт. Код 503 говорит о недоступности сервиса: он либо остановлен, либо намеренно закрыт на обслуживание, либо очередь запросов переполнена.

Код 504 — таймаут: бэкенд отвечать начал, но не уложился в отведённое время. Стандартное значение fastcgi_read_timeout в nginx — 60 секунд, и упереться в него легко на тяжёлом импорте товаров или неоптимизированном запросе к базе.

Чем 502 отличается от 504 и почему путать их дорого

Эти два кода дают одинаково белую страницу, но лечатся противоположными способами, поэтому различие стоит разобрать отдельно. Между посетителем и приложением стоит связка: nginx принимает соединение и передаёт запрос дальше — процессу PHP-FPM или другому приложению. В этой схеме nginx выступает как обратный прокси, а то, что стоит за ним, называют апстримом.

При 502 апстрим ответил, но ответ непригоден: соединение закрылось на середине, процесс умер по нехватке памяти, сокет исчез после обновления пакета. Ключевая примета — ошибка приходит быстро, за доли секунды. В nginx в error.log при этом появляется строка со словами connect() failed или recv() failed while reading response header from upstream.

При 504 апстрим жив и работает, просто медленно. Примета обратная: страница висит ровно столько, сколько указано в таймауте, и только потом отдаёт ошибку. В логе будет upstream timed out. Увеличение таймаута до 120 секунд здесь маскирует симптом, а не лечит: правильнее найти медленный запрос к базе или тяжёлую операцию в коде.

Проверка занимает одну команду. Она показывает, живы ли процессы PHP-FPM и когда сервис последний раз перезапускался; версию в имени сервиса подставьте свою.

systemctl status php8.2-fpm --no-pager

Пошаговая диагностика пятисотой ошибки по порядку

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

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

1. Уточните код через curl -I — браузер мог показать заглушку от кэша или от промежуточного сервиса.
2. Проверьте свободное место: df -h. Заполненный на 100% раздел даёт и 500, и 502, и сбои базы одновременно.
3. Посмотрите память: free -m. Если свободно меньше 100 МБ, процессы убивает механизм OOM — часть ядра Linux, которая при нехватке памяти завершает самый прожорливый процесс.
4. Откройте последние строки лога веб-сервера: tail -n 50 /var/log/nginx/error.log.
5. Проверьте состояние бэкенда: systemctl status php8.2-fpm и systemctl status mysql.
6. Проверьте синтаксис конфигурации командой nginx -t — она скажет точный файл и номер строки.
7. Только теперь смотрите лог приложения и вспоминайте, что меняли последним.

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

Где лежат логи и что в них искать

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

Пути отличаются в зависимости от дистрибутива и веб-сервера. Ниже собраны самые распространённые расположения для Ubuntu и Debian. Команда tail -f показывает строки в реальном времени: запускаете её, обновляете страницу в браузере и видите, что именно записывается в момент ошибки.

Отдельно стоит настроить оповещение, чтобы узнавать про 500-е раньше посетителей: базовая проверка раз в 60 секунд закрывает вопрос. Как это собрать без лишних сложностей, разобрано в гайде про мониторинг сервера.

Почему 503 и 429 чаще всего упираются в ресурсы

Коды 503 и 429 — это не поломка кода, а сигнал о перегрузке. Сервер физически не успевает обработать поток запросов и начинает отказывать, чтобы не лечь полностью. Причины делятся на две: реальный рост посещаемости и паразитный трафик от ботов.

Первый индикатор — средняя нагрузка. Показатель load average — это средняя длина очереди задач, ждущих процессор. Команда uptime выводит его тремя числами: за 1, 5 и 15 минут. Ориентир простой — цифра не должна регулярно превышать количество ядер. Для сервера с 2 ядрами значение 2.0 уже граница, а 6.0 означает, что очередь растёт втрое быстрее, чем сервер её разбирает.

Второй индикатор — память. Когда оперативная память кончается, система начинает использовать swap — запасную область на диске, куда выгружается то, что не поместилось в память, — и время ответа вырастает в десятки раз. Для сайта на WordPress с парой плагинов минимум — 1 ГБ, для интернет-магазина на 1С-Битрикс комфортный порог начинается от 4 ГБ.

Если в access-логе видно, что сотни запросов в секунду идут с нескольких адресов на один тяжёлый URL, это уже не посетители. Разбираться с такой нагрузкой конфигурацией веб-сервера можно, но при постоянном давлении дешевле подключить фильтрацию: варианты собраны в разделе защита от DDoS для сайта.

На каком сервере ошибки чинятся быстрее

Разница между хостингами в этой теме сводится к одному: есть ли у вас доступ к логам и к перезапуску сервисов. На виртуальном хостинге лог приложения обычно доступен, а error.log веб-сервера и статус PHP-FPM — нет, и при 502 остаётся писать в поддержку и ждать. На своём сервере тот же разбор занимает пять минут.

Второй фактор — ресурсы. Половина ошибок 500 и 503 на дешёвых тарифах вызвана не кодом, а нехваткой памяти. Ниже — четыре самых доступных площадки из 44 в нашем каталоге; цены указаны за месяц при минимальной конфигурации.

Данные проверены 04.09.2026.

Брать самый дешёвый тариф под боевой сайт не стоит: на 512 МБ памяти современная CMS живёт до первого всплеска посещаемости, а дальше начинается череда 502-х. Разумный минимум для сайта с базой — 2 ГБ памяти и 2 ядра, и такие конфигурации начинаются примерно от 300 ₽ в месяц.

Частые ошибки при разборе кодов

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

Второй источник потерь — правки наугад. Меняют настройку, обновляют страницу, не помогло, меняют следующую, и через полчаса конфигурация отличается от рабочей десятком строк, а исходная причина так и не найдена. Перед любой правкой сохраняйте копию файла и меняйте по одному параметру за раз.

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

• Читают код из браузера, а не из curl: заглушка кэша показывает старую ошибку.
• При 502 перезапускают nginx, хотя падает PHP-FPM, и через минуту ошибка возвращается.
• Поднимают таймаут до 300 секунд вместо поиска медленного запроса к базе.
• Ставят права 777 при 403, открывая файлы на запись всем подряд.
• Ищут 404 в коде, забыв, что после переноса сайта не восстановлен .htaccess.
• Смотрят логи за сегодня, когда ошибка была ночью и уже провалилась в архив.

Частые вопросы

Чем 500 отличается от 502? При 500 приложение запустилось и упало внутри себя, ошибка будет в логе PHP или CMS. При 502 приложение не ответило вовремя или ответило мусором, и ошибку пишет уже веб-сервер в свой error.log. Первый случай чинит разработчик, второй — администратор.

Ошибка 503 появляется каждый день в одно и то же время. Почему? Почти всегда это плановая задача: резервное копирование, индексация, импорт прайса. Задача съедает процессор и память, очередь запросов переполняется, сервер отвечает 503. Посмотрите расписание cron и перенесите тяжёлые операции на ночь.

Google показывает 404 на страницах, которые открываются. Что не так? Скорее всего, страница отдаёт правильное содержимое, но с кодом 404 в заголовке — такое бывает при поломанных правилах маршрутизации. Проверьте адрес через curl -I: браузер покажет текст, а команда покажет реальный код.

Можно ли отдавать 200 вместо 404 на несуществующих страницах? Нет. Поисковые системы будут считать такие адреса рабочими и индексировать пустые страницы. Для удалённого раздела корректно ответить 404, а при переезде — поставить 301 на новый адрес.

Что означает 429 и сколько ждать? Это лимит на число запросов. Если код пришёл от вашего сервера, лимит стоит в конфигурации веб-сервера или в защите от перебора. Если от чужого API — в заголовке ответа обычно указано время ожидания в секундах, чаще всего от 30 до 60.

Насколько опасно много 304 в логе? Не опасно, наоборот. Код 304 означает, что браузер взял файл из кэша и сервер не тратил трафик на повторную передачу. Тревожный признак — не 304, а рост доли 5xx выше 1% от всех запросов.

Ошибка появилась после обновления PHP с 7.4 на 8.2. Куда смотреть? В лог приложения: часть старых плагинов и библиотек несовместима с новой версией и падает с фатальной ошибкой, что даёт 500. Быстрое решение — вернуть прежнюю версию PHP для этого сайта, а потом обновлять плагины по одному.

Итог

Разбор ошибки укладывается в три вопроса: какой код на самом деле пришёл, к какой группе он относится и что говорит соответствующий лог. Коды 3xx — не ошибка, 4xx — вопрос к запросу и правам, 5xx — к серверу и приложению. Проверка через curl, затем df -h и free -m, затем error.log — этот порядок закрывает большинство случаев за несколько минут.

Быстро всё это делается только там, где у вас есть консоль и полный доступ к логам. Подходящие конфигурации с 2 ГБ памяти и выше собраны в разделе VPS для сайтов — там видны цены всех 44 площадок каталога и можно отфильтровать варианты по памяти, дискам и локации.