Как исправить 502 Bad Gateway и ошибки прокси на сайте

Ошибка 502 Bad Gateway — одна из тех неприятностей, которые сначала выглядят как «упал весь сайт», а по факту часто оказываются банальной проблемой между nginx, PHP-FPM, балансировщиком, Cloudflare или апстримом. Я у себя на проектах видел это десятки раз: от WordPress на PHP 8.1 до сложного Bitrix на PHP 8.2 с MySQL 8.0 и Redis. И почти всегда причина находилась не в одном месте, а где-то между сервером, кэшем и настройками прокси.

Что такое 502 Bad Gateway и почему она появляется

Если говорить грубо, 502 означает, что один сервер попытался получить ответ от другого, но получил мусор, таймаут или вообще ничего. Чаще всего это случается в схеме nginx → PHP-FPM, nginx → Apache, nginx → Node.js, либо когда между сайтом и пользователем стоит внешний прокси, например Cloudflare. На деле 502 — это не «ошибка сайта» в чистом виде, а сбой на границе между компонентами.

У меня был клиент на Laravel 10 с PHP 8.3, который регулярно ловил 502 именно в часы пик. Снаружи выглядело так, будто сервер «умирает», но в логах всё сводилось к тому, что PHP-FPM не успевал обрабатывать тяжёлые запросы, а nginx ждал меньше, чем нужно. После переноса части тяжёлых задач в очереди и настройки Redis для сайта проблема ушла. И это типичная история.

Есть несколько распространённых сценариев:

• PHP-FPM не запущен или упал.
• Неверный путь к сокету в nginx.
• Слишком маленькие таймауты прокси.
• Перегрузка CPU, RAM или диска.
• Проблема на стороне CDN, балансировщика или upstream-сервиса.
• Кривое обновление CMS, плагина или модуля.

Если у вас Bitrix, WordPress или Laravel, начинать нужно не с паники, а с логов. Иначе это гадание на кофейной гуще. На практике я всегда иду от простого к сложному: сначала проверяю доступность PHP-FPM, затем nginx error log, потом системные ресурсы и только после этого лезу в CMS.

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

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

На стороне сервера полезно проверить статус служб. Для Linux-сервера это стандартный набор. Если вы управляете VPS на Ubuntu 22.04, Debian 12 или AlmaLinux 9, команды будут почти одинаковые:

systemctl status nginx
systemctl status php8.2-fpm
systemctl status php8.3-fpm
systemctl status mysql
journalctl -u nginx -n 100 --no-pager
journalctl -u php8.2-fpm -n 100 --no-pager

Если PHP-FPM в статусе failed, это уже половина ответа. У меня был случай на WordPress-сайте с WooCommerce, где 502 появлялась только при оформлении заказа. Причина оказалась смешной: пул PHP-FPM был настроен на слишком малое число процессов, а в момент пиковой нагрузки очередь забивалась. После правки pm.max_children и включения OPcache проблема ушла, а PageSpeed на мобильных вырос с 68 до 89. Да, 502 иногда маскируется под «проблемы с производительностью».

Ещё один быстрый признак: если 502 возникает только за Cloudflare или другим CDN, а напрямую по IP сервер отвечает нормально, проблема почти наверняка в связке прокси, SSL или таймаутах. Тогда уже надо смотреть заголовки, keepalive, origin timeouts и правила на CDN. И да, проверьте, не включён ли агрессивный кеш на стороне внешнего прокси — это тоже бывает источником странных ошибок.

Основные причины в nginx, PHP-FPM и Apache

Самая частая причина 502 на сайтах с nginx — это неправильная связка с PHP-FPM. Иногда в конфиге указан не тот сокет. Иногда сокет существует, но права на него не позволяют nginx подключиться. Иногда PHP-FPM просто не отвечает вовремя, потому что упёрся в память или количество дочерних процессов. На серверах с PHP 8.1 и 8.2 это особенно заметно, если включён тяжёлый плагин, много cron-задач или плохо написанный кастомный модуль.

Вот типичный фрагмент nginx-конфига, который я проверяю первым делом:

server {
    listen 80;
    server_name example.ru www.example.ru;
    root /var/www/example.ru/public_html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 120;
    }
}

Если сокет в конфиге php8.2-fpm.sock, а у вас реально запущен php8.3-fpm, получите 502 без лишних церемоний. То же самое бывает после обновления PHP. Я однажды видел сервер, где после переезда с 8.1 на 8.2 забыли поправить путь в nginx. Сайт «лежал», а проблема решалась одной строкой. Однозначно стоит проверять конфиги после любого обновления, особенно если у вас обновление PHP на сервере было сделано в спешке.

Если сайт работает через Apache, либо nginx стоит как reverse proxy перед Apache, причины те же, но слой другой. Apache может падать из-за перегруза, конфликтов модулей или .htaccess-правил. У WordPress это бывает при слишком тяжёлом наборе плагинов, а у Bitrix — при кривых правилах кеширования, сессий и авторизации. И это не теория, а нормальная повседневная боль.

Проверка логов и обнаружение истинной причины

Без логов вы действуете вслепую. Я бы даже сказал жёстче: без логов любые советы превращаются в гадание. Смотрите прежде всего error.log nginx, логи PHP-FPM и системный журнал. Если есть MySQL, отдельно проверьте и его логи, потому что зависший запрос к базе тоже может привести к 502 через исчерпание таймаута.

Вот что я обычно смотрю на сервере:

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/php8.2-fpm.log
tail -n 100 /var/log/mysql/error.log
dmesg | tail -n 50

Строки вида upstream prematurely closed connection, connect() to unix:/run/php/php8.2-fpm.sock failed, recv() failed (104: Connection reset by peer) или no live upstreams дают очень конкретную подсказку. Например, prematurely closed connection часто означает, что PHP-скрипт завершился аварийно, упёрся в memory_limit или был убит по OOM.

На одном проекте на Bitrix я видел 502 из-за того, что MySQL 8.0 начал отваливаться по памяти в часы синхронизации с CRM. Сайт снаружи показывал ошибку прокси, а корень был в SQL-запросах и недостатке RAM. После оптимизации запросов, включения Redis и пересмотра пулов PHP-FPM инциденты прекратились. Для таких случаев мне часто помогает и оптимизация базы данных MySQL — особенно на MySQL 5.7 и 8.0, где разница в поведении кешей и планировщика запросов уже заметна.

Если у вас есть доступ к логам доступа nginx, полезно понять, какие URL вызывают сбой. Иногда 502 ловит только поиск, корзина, фильтр каталога или страница с интеграцией API. Тогда уже надо смотреть конкретный код, а не сервер в целом. У меня был кейс с модулем обмена в Bitrix: обычные страницы открывались нормально, а экспорт товаров в XML валил весь пул PHP-FPM. Решилось переносом тяжёлой операции в cron и очереди задач.

Как исправить 502 на уровне сервера

Когда причина уже найдена, я иду по самой вероятной цепочке. Первое — проверяю, запущены ли нужные сервисы. Второе — нет ли ошибки в socket/path. Третье — хватает ли ресурсов: RAM, swap, CPU и свободного места на диске. Да, банальный забитый диск тоже способен вызвать 502, особенно если сервис не может писать временные файлы или логи.

Если PHP-FPM регулярно падает, посмотрите пул. Вполне возможно, что pm.max_children слишком низкий, а memory_limit слишком маленький. Но и завышать параметры бездумно нельзя. На сервере с 2 ГБ RAM и PHP 8.2 я однажды видел конфиг, где хотели поднять pm.max_children до 50. Это гарантированный путь к OOM и новым падениям. Лучше рассчитать реалистично.

Пример более спокойной настройки для небольшого сайта:

[www]
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
request_terminate_timeout = 120s

Если вы используете nginx как reverse proxy, проверьте таймауты. Иногда внешний сервис отвечает не за 1-2 секунды, а за 15-30. Тогда fastcgi_read_timeout, proxy_read_timeout и proxy_connect_timeout нужно поднимать аккуратно, но без фанатизма. Для API, интеграций CRM и генерации отчётов это вообще обычная история. И вот здесь уже полезна настройка API-интеграций на сайте с нормальной архитектурой, а не «всё в один PHP-скрипт».

Если проблема на уровне Apache + .htaccess, проверьте бесконечные редиректы, циклы маршрутизации и конфликтующие правила. Особенно это касается WordPress после переноса домена, смены структуры URL или установки SSL. Иногда 502 возникает не напрямую из-за редиректа, а потому что цепочка запросов слишком длинная и backend не выдерживает нагрузку. Тут полезно посмотреть и как настраивать 301 и 302 редиректы без петель.

Если проблема в прокси, CDN или балансировщике

Здесь всё становится интереснее. Когда между пользователем и сайтом стоит Cloudflare, Nginx Proxy Manager, HAProxy, AWS ALB или другой балансировщик, 502 может приходить не от самого сайта, а от промежуточного слоя. И это уже другая диагностика. Нужно проверять соединение между proxy и origin, SSL-сертификаты, SNI, заголовки Host и реальные ответы backend-сервера.

На практике я часто вижу такие причины: origin не принимает подключение по HTTPS, сертификат просрочен, на сервере неправильный Host, либо CDN ожидает ответ быстрее, чем backend способен его дать. Если у вас есть внешний прокси, проверьте, не блокирует ли firewall внутренние IP, и не слишком ли строгие правила rate limiting. Кстати, если тема защиты интересует глубже, посмотрите настройку firewall и rate limiting для сайта.

Иногда надо править конфиг именно на уровне proxy. Пример для nginx в роли reverse proxy:

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_connect_timeout 30s;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;
    proxy_buffering on;
}

Если сайт за Cloudflare, а origin слушает только один порт или закрыт на стороне фаервола, 502 будет стабильной и неприятной. Тогда проверяйте, не изменился ли IP, не слетели ли правила в security group, не сломалась ли DNS-запись. И да, в таких историях полезно помнить, что инфраструктура — это часть сайта. Никакой «магии CMS» тут нет.

Особенности для Bitrix, WordPress и Laravel

Для WordPress частая причина 502 — тяжелые плагины, внешний импорт, кривые хуки и нехватка памяти. У меня был сайт на WordPress 6.5 и PHP 8.2, где ошибка возникала только после обновления плагина кэширования. Оказалось, он конфликтовал с object cache и Redis. После отключения проблемного модуля и пересборки кеша сайт ожил. Если у вас WordPress, держите под рукой материал по ускорению WordPress — там хорошо видно, как связаны скорость и стабильность.

Для Bitrix причина часто лежит в тяжёлых компонентах, кешировании, агентских задачах и интеграциях. На проектах с каталогом, фильтрами и обменом с 1С 502 обычно появляется не на главной, а там, где есть сложная логика. Я часто иду через настройку кеширования в Битрикс, проверяю агентскую нагрузку и смотрю, не забит ли cron. На больших магазинах ещё помогает перенос фоновых задач в очередь и нормальная настройка Redis.

Для Laravel причины обычно связаны с очередями, long-running requests, ошибками в API-обмене и неправильным deployment. Если вы деплоите через Docker, supervisor или systemd, убедитесь, что воркеры не падают после обновления. Плюс проверьте кеш конфигурации и route cache. И честно говоря, Laravel-проекты очень часто «падают» не из-за самого фреймворка, а из-за плохой инфраструктуры вокруг него.

Ещё одна типичная история — слишком маленький max_execution_time или memory limit. На php 8.1/8.2/8.3 это особенно чувствуется, если код и так работает на грани. Да, увеличить лимиты иногда помогает. Но если страница генерируется 20 секунд, это не лечение, а отсрочка проблемы. Лучше разобраться в узком месте: SQL, внешние API, изображение, очереди, кэш.

Как не допустить повторения 502 в будущем

Когда 502 уже починили, главное — не повторить ту же историю через неделю. Я обычно настраиваю несколько уровней защиты: мониторинг, логирование, резервные копии, staging и безопасные обновления. Это скучно, но именно скучные вещи спасают от простоя. Особенно если у вас интернет-магазин, заявки и интеграция с CRM.

Первое — мониторинг. Идеально, если у вас есть проверка доступности, алерты по SMTP/Telegram и анализ ошибок в логах. Второе — бэкапы. Третье — staging-среда, куда сначала прилетают обновления CMS, плагинов и модулей. Я бы ещё добавил регулярную проверку PHP-версии. Если сайт живёт на PHP 7.4, это уже не просто старьё, а источник рисков. На практике переход на PHP 8.2 или 8.3 часто улучшает и скорость, и стабильность, если код адекватный. Но перед обновлением лучше читать про безопасные обновления сайта.

Также однозначно стоит настроить нормальную схему отката. Если после обновления модуля сайт начал отдавать 502, вы должны уметь быстро вернуться на предыдущую версию. Иначе простой растягивается на часы. Для этого пригодятся версионирование и откат обновлений и адекватные бэкапы. Тут я без лишней дипломатии скажу: сайт без резервной стратегии — это плохая идея.

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

Пошаговый чек-лист исправления 502

Чтобы не бегать по кругу, я обычно иду по такому порядку. Это не единственно верный путь, но на моей практике он закрывает большинство кейсов за 15-40 минут, а не за полдня.

1. Проверить, один ли URL даёт ошибку или весь сайт.
2. Открыть nginx error log и PHP-FPM log.
3. Проверить статус nginx, php-fpm, mysql, redis.
4. Сверить путь к сокету и версию PHP.
5. Проверить загрузку CPU, RAM, swap и диска.
6. Посмотреть таймауты proxy/fastcgi.
7. Проверить конфликты плагинов, модулей, редиректов и кеша.
8. Если есть CDN — проверить origin, SSL и firewall.
9. Перезапустить службы после правок.
10. Сделать нагрузочную проверку и посмотреть, повторяется ли сбой.

Если после всех проверок ошибка осталась, не затягивайте. В таких ситуациях я уже подключаю более глубокую диагностику: профилирование PHP, анализ slow log MySQL, просмотр stack trace и тестирование на staging. Иногда полезно временно отключить кеш, лишние плагины или сложные интеграции, чтобы изолировать источник. Это не красиво, зато работает.

И ещё момент. Очень часто 502 маскируется под «случайную проблему хостинга», а в реальности это технический долг проекта. Старые плагины, переполненные логи, неактуальная версия PHP, грязный .htaccess, десятки фоновых задач и отсутствие мониторинга. Такое надо не латать, а приводить в порядок. Тут уже помогает полноценная доработка сайта и, если проект большой, нормальная техническая ревизия.

Если хотите, можно начать не с хаотичных правок, а с системной диагностики: от логов до архитектуры. На больших и средних проектах это быстрее, чем «потыкать настройки» и надеяться на чудо. И да, чудо обычно не случается. А вот аккуратная проверка сервера, CMS и прокси — да.