Исправление HTTP-ошибок 500, 404, 403, 502 и 504 на 1С-Битрикс

Когда сайт на Битрикс начинает отдавать коды ошибок, владельцу важна не теория, а понятный путь от паники к работающему сайту. Ниже мы по-честному разбираем, как устроена диагностика каждого кода, почему быстрые костыли только откладывают проблему и где проходит граница между сбоем сайта и сбоем сервера. Это взгляд команды, которая поднимала и сплошные 500 перед запуском акции, и плавающие 502 в часы пиковой нагрузки, и массовые 404 после неудачного переезда.

Почему HTTP-ошибка — это всегда диалог сервера с клиентом

Любая страница на сайте — это ответ сервера на запрос браузера, и у ответа есть код. Код 200 значит, что страница успешно отдана. Всё остальное — сигнал о проблеме, и важно не путать, на чьей стороне она возникла. Коды группы 4xx говорят о проблеме запроса: 404 — адрес не найден, 403 — доступ запрещён. Коды группы 5xx говорят о сбое сервера: 500 — внутренняя ошибка приложения, 502 — шлюз получил негодный ответ от бэкенда, 504 — бэкенд не ответил за таймаут. Понимание этой логики — половина диагностики, потому что код сразу подсказывает, где копать: в коде сайта, в маршрутах, в правах или в связке веб-сервера.

Главная ловушка для владельца сайта — судить по тому, что видно на экране. Белый экран может быть и фатальной 500, и пустой страницей из-за подавленного вывода ошибок. Сообщение «502 Bad Gateway» от nginx выглядит одинаково и при упавшем воркере php-fpm, и при исчерпанном пуле процессов, хотя чинятся эти случаи по-разному. Поэтому мы никогда не лечим по картинке — только по логам, где записана реальная причина.

Как мы диагностируем код 500

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

Почему 404 — это чаще про маршруты, чем про контент

Когда страница отдаёт 404, владелец первым делом проверяет, на месте ли материал в админке. Обычно он на месте — а ошибка всё равно есть. Дело в том, что 404 на Битрикс почти всегда про маршрутизацию: сломанные правила ЧПУ, неверный mod_rewrite, редирект, ведущий в никуда, или несоответствие путей после переноса. Сайт получает адрес, не находит для него маршрут и честно отдаёт 404. Мы проверяем настройки ЧПУ, правила веб-сервера и таблицу редиректов, восстанавливаем корректную маршрутизацию и настраиваем 301-редиректы со старых адресов на новые. Особенно это критично после переезда: массовые 404 без редиректов выкидывают страницы из индекса и роняют трафик. Поэтому для 404 мы всегда думаем не только о посетителе, но и о поисковике — какой код он увидит и как это отразится на позициях.

Что на самом деле скрывается за 403 Forbidden

Ошибка 403 говорит, что ресурс существует, но доступ к нему закрыт. Причин немного, и все они конкретные: неверные права на файлы и папки или сбитый владелец после переноса, ограничивающие директивы в .htaccess или конфиге nginx, защита раздела паролем, блокировка по IP. Опасность 403 в том, что её легко «починить» слишком грубо — например, выставить всем файлам максимальные права и открыть доступ туда, где он должен быть закрыт. Мы так не делаем. Сначала определяем, какое именно правило закрывает доступ, и аккуратно открываем только то, что должно работать, не снимая нужную защиту административных и служебных разделов. Безопасность сайта при починке доступа для нас так же важна, как и сам факт открытия страницы.

Связка nginx и php-fpm: где живут 502 и 504

Коды 502 и 504 — самые недооценённые. Они появляются эпизодически, часто под нагрузкой, и владелец нередко списывает их на хостинг. Иногда так и есть, но чаще причина в самом сайте. На типовой схеме nginx принимает запрос и проксирует его на php-fpm — менеджер процессов PHP, который выполняет код Битрикс. Если воркер php-fpm падает по лимиту памяти или исчерпан пул процессов, nginx не получает ответа и отдаёт 502. Если процесс не успевает выполнить запрос за таймаут — приходит 504. Мы всегда смотрим обе стороны: лог nginx с записями об ошибках upstream и лог php-fpm с падениями воркеров. Затем работаем в двух направлениях — оптимизируем тяжёлые некешированные запросы, чтобы процессы освобождались быстрее, и настраиваем размер пула и лимиты под реальные ресурсы сервера. Это останавливает 502 не до следующего пика, а насовсем.

С 504 отдельная история. Соблазн просто поднять таймаут велик, но это решение для исключений — тяжёлой фоновой выгрузки или импорта. В остальных случаях долгий ответ — это симптом: запрос без индексов, выборка без кеша, зацикленный код или медленный внешний сервис. Мы находим конкретную операцию, которая упирается в таймаут, и оптимизируем её, а настройки таймаута трогаем осознанно и точечно. Если корень 502 и 504 в производительности всего сайта, имеет смысл смотреть шире — на оптимизацию скорости и нагрузки, и тогда мы предлагаем профильную услугу ускорение и оптимизация Битрикс, чтобы убрать причину тормозов системно.

Почему важен именно корректный код ответа, а не «открылась страница»

Частая ошибка — считать задачу решённой, как только страница начала открываться в браузере. Но для поисковых систем важен код ответа, который не всегда виден на глаз. Бывает, что страница 404 настроена так, что отдаёт код 200 — и поисковик индексирует пустышки. Бывает, что рабочая страница из-за сбоя кеша периодически отдаёт 500 — и выпадает из индекса. Поэтому после любой починки мы проверяем фактический код ответа: рабочие страницы должны отдавать 200, постоянные переезды — 301, реально удалённые страницы — 404. Эта проверка отделяет настоящее исправление от косметики и защищает позиции сайта в поиске.

Где граница между разовой ошибкой и системной проблемой

Не каждый код ошибки требует большого проекта. Единичная 500 на одной странице, 403 на разделе после смены прав, пара битых ЧПУ — это понятные разовые задачи, которые мы закрываем быстро и недорого. Но если ошибки сыплются сериями, плавают под нагрузкой или возвращаются после каждой починки, значит, у проблемы системный корень: неустойчивая архитектура, тяжёлый некешированный код, конфликтующие правки ядра. В таких случаях разовый фикс лишь оттянет следующую аварию. Мы честно говорим, когда достаточно точечного исправления, а когда нужен комплексный разбор причин — и подбираем глубину работ под реальную картину, а не продаём большой проект там, где хватит часа работы. Если же сбои выходят за рамки HTTP-кодов и затрагивают работу самих модулей и компонентов, это уже более широкая задача исправления ошибок Битрикс.

Как мы страхуем сайт от повторных аварий

Устранить текущую ошибку — это половина дела. Вторая половина — сделать так, чтобы она не вернулась. Поэтому исправления мы делаем без прямых правок ядра, через события и собственные модули: такие фиксы переживают обновления Битрикс и не создают новых конфликтов. После работ присылаем отчёт с описанием причины и решением, чтобы у вас осталась ясная картина. А для сайтов, где простой стоит дорого, предлагаем мониторинг кодов ответа: система ловит появление 500, 502 или 504 раньше, чем их заметят клиенты, и мы успеваем поднять сайт до того, как авария ударит по выручке.

Типичные сценарии, с которыми к нам приходят

За годы работы складывается набор повторяющихся историй, и по первым же признакам мы примерно понимаем, где искать. Сценарий первый — сплошная 500 сразу после обновления модуля или ядра: накатили апдейт, и весь сайт лёг белым экраном. Почти всегда виновата несовместимая кастомная правка, и решается это разбором лога и переносом логики в события. Сценарий второй — массовые 404 наутро после переезда на новый хостинг: материалы на месте, но адреса не открываются, потому что не перенеслись правила ЧПУ и редиректы. Сценарий третий — внезапная 403 на разделе после смены прав или восстановления из бэкапа: сбился владелец файлов или добавилось лишнее правило в .htaccess. Сценарий четвёртый — плавающие 502 и 504, которые появляются строго в часы пик и исчезают ночью: классический признак исчерпания пула php-fpm и тяжёлых запросов без кеша. Узнавая сценарий, мы экономим вам время на диагностике, но всё равно подтверждаем гипотезу логами, а не верим ей на слово.

Отдельная категория — ошибки, которые проявляются только у части посетителей или только на отдельных устройствах. Например, 403 для конкретной страны из-за правила блокировки по IP, или 504 только при оформлении большого заказа, который запускает тяжёлую выгрузку. Такие плавающие ошибки сложнее воспроизвести, поэтому мы выясняем точные условия: какой адрес, какое действие, какой браузер, какое время суток. Чем точнее описаны условия, тем быстрее мы локализуем сбой и тем меньше времени уходит на дорогую диагностику вслепую.

Как мы работаем с логами, а не с догадками

Лог — это главный источник правды при любой HTTP-ошибке, и мы умеем читать каждый из них в связке. Лог ошибок PHP показывает фатальные сбои и точную строку падения для 500. Лог Битрикс хранит исключения и предупреждения уровня приложения. Журнал доступа и ошибок nginx фиксирует коды ответа, обращения к upstream и причины 502 и 504. Лог php-fpm пишет падения и медленные запросы воркеров. Лог медленных запросов базы данных подсказывает, какая выборка упирается в таймаут и вызывает 504. Мы не смотрим логи по отдельности — мы сопоставляем их по времени и запросу, чтобы увидеть всю цепочку: какой запрос пришёл, на каком участке он замедлился или сломался и каким кодом ответа закончился. Именно эта сквозная картина отличает осознанную починку от перебора случайных правок.

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

Что делать прямо сейчас, если сайт отдаёт ошибку

Если перед вами уже горит код 500 или 502, главное — не править прод вслепую и не множить хаос. Зафиксируйте, какие именно страницы и при каких действиях отдают ошибку, не удаляйте логи и по возможности не накатывайте новые правки. Дальше напишите нам: мы подключаемся по аварии от 30 минут, начинаем с резервной копии и диагностики по логам, а не с догадок. Бесплатная диагностика покажет, какой код, по какой причине и где именно ломается, сколько стоит починка и можно ли поднять сайт в день обращения. В большинстве случаев — можно, и сервер снова начинает отдавать честный код 200 вместо кода ошибки.