502 bad gateway apache


Почему на веб-серверах возникает ошибка 502 bad gateway и как ее исправить?

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

502 bad gateway - что это за ошибка? Ошибка 502 Bad Gateway может проявляться по-разному. К примеру, 502 – Service Temporarily Overloaded или HTTP Error 502 Bad Gateway.

Ошибка 502 bad gateway - что это значит?

Ошибка 502 bad gateway говорит о том, что обратный прокси-сервер (допустим, Apache) для сервера источника (например, nginx) получает некорректный ответ от исходного веб-сервера.

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

  1. Перегруженность сервера. Веб-сервер может падать из-за нехватки ресурсов (например, оперативной памяти), вызываемой избытком выполняемых процессов или агрессивными действиями пользователей;
  2. Частая перезагрузка веб-сервера. Такое случается при ошибках конфигурации, сбоях в модулях, любых атаках, избытке выполняемых процессов и приложений. В результате пользователь видит временную 502 ошибку;
  3. Плохой код сайта. Сайты с устаревшими приложениями или корявым кодом влияют на правильное функционирование сервера и ведут к периодическому возникновению 502 ошибки;
  4. Ошибки сети. Прочие ошибки конфигурации сети (проблемы с DNS, маршрутизация, блокировка файерволом, используемым на сервере, проблемы у провайдера) также становятся причиной появления 502 ошибки сервера;
  5. Время ожидания серверного программного обеспечения. 502 ошибка неизбежна при снижении скорости выполнения запросов в nginx, когда средство кэширования (например, Varnish Cache) уходит в таймаут. Сюда же относятся и медленные запросы.

Как исправить ошибку 502 bad gateway на веб-сервере nginx

Сначала необходимо определить первопричину возникновения данной ошибки. Мы изучили серверные логи во время перезагрузок, и нашли там ошибки seg fault.

Затем мы покопались в конфигурации сервера, и увидели, что там отсутствовал модуль mod_rpaf. Именно это и вызывало падение сервера:

root@server [~]# ls -l /usr/local/apache/modules/mod_rpaf-2.0.so /bin/ls: cannot access /usr/local/apache/modules/mod_rpaf-2.0.so: No such file or directory

Rpaf – это модуль Reverse proxy add forward, разработанный для серверов Apache. Он нужен в том случае, если вы задаете Nginx фронденд-сервером и хотите получить реальный IP серверных запросов.

Данный модуль не работал под Apache-2.4, поэтому мы немного его подправили. После перекомпиляции и перезагрузки Apache ошибки сегментации прекратились.

Мы последили за сервером еще пару часов и убедились в том, что перезагрузки прекратились, а серверные ошибки исчезли.

Вот несколько советов, как исправить ошибку 502 bad gateway:

  • Следите за тем, чтобы файлы сайта (плагины и темы) своевременно обновлялись и не устаревали;
  • Оптимизируйте и исправляйте медленные MySQL-запросы;
  • Проводите аудит серверного программного обеспечения и вовремя обновляйте модули;
  • Избегайте проблем с маршрутизацией и отслеживайте любые перегрузки/атаки на сервер.

Пожалуйста, оставляйте ваши комментарии по текущей теме материала. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!

Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, дизлайки, отклики, лайки, подписки огромное вам спасибо!

ОСОльга Сайфудиноваавтор статьи «HOW TO FIX «502 SERVER ERROR – BAD GATEWAY» IN WEB SERVERS»

ОШИБКА 502 "BAD GATEWAY" КАК ЕЕ ИСПРАВИТЬ? - База знаний

Ошибка 502 на виртуальном хостинге "Bad Gateway"

Ошибка 502 возникает когда Apache работает в связке с Nginx. Запрос от пользователя прошел через NGINX к Apache но тот в свою очередь вернул нулевой результат прокси-серверу NGINX.

Причины возникновения и способы устранения ошибки 502:

  • Дочерний процесс Apache не смог обработать поступивший к нему запрос и завершился досрочно. Зачастую это связано с ошибкой в скрипте сайта или нехваткой памяти для выполнения процесса. Начните свой поиск error 502, в таком случае с логов ошибок сайта. Вполне возможно там будет информация, которая привела к возникновению этой ошибки. Но зачастую лог не содержит ничего полезного по этой проблеме, поскольку процесс Apache завершился досрочно. Если это так, разбейте свой скрипт на участки, и выполняйте их поочередно. Это должно помочь найти 502 error. В другом случае, вы можете самостоятельно завершить работу зависших обработчиков и перезапустить их, подробнее см. Завершение работы процессов. 
  • Процесс Apache завершился по таймауту и не вернул в поток вывода никаких данных. Обычно это связано с длительным выполнением скрипта, либо зацикливанием в нем. Чтоб не получать 502 bad gateway, когда скрипт выполняется длительное время, лучше его запускать из консоли, а в случае если скрипт запускается регулярно, поставить его на CRON. 
  • Скрипты сайта превышают ограничения, накладываемые на них условиями нашего хостинга, и автоматически завершаются. Для устранения ошибки достаточно провести оптимизацию ваших скриптов. 
  • При использовании CMS Bitrix ошибка может возникать из-за некорректного названия директории для хранения кэшированных файлов. Проблема решается переименованием данной директории. 
  • Ошибка при включенном APC (Alternative PHP Cache). Проблема решается отключением APC при помощи добавления в файл .htaccess вашего сайта следующей строки: php_flag apc.cache_by_default Off 
  • Технический сбой на сервере. Проблема максимально быстро диагностируется нашими специалистами и оперативно устраняется.

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

Если 502 ошибка возникает регулярно, напишите заявку в службу поддержки. В заявке укажите:

  • Точное московское время наблюдения проблемы.
  • Название сайта, на котором была замечена проблема.
  • Если ошибка отображается не сразу, а после определённых действий (добавление изображения, отправка формы с сайта, импорт файлов), подробно опишите порядок действий, по которому мы сможем воспроизвести проблему.
  • Если для воспроизведения проблемы необходимо авторизоваться в административной части сайта, предоставьте логин и пароль для доступа.

Ошибка 502 на VPS

Чаще всего на VPS используется связка: Nginx + бэкенд-сервер (Apache, PHP-FPM, Gunicorn, NodeJS). Ошибка 502 возникает в случае, если Nginx не может получить ответ от этих сервисов. 

Наиболее частые причины возникновения 502 ошибки: 

  • Какой-то из сервисов выключен. Необходимо перезапустить веб-сервер Apache, PHP-FPM либо другой сервис, с которым работает Nginx.
  • Между Nginx и бэкенд-сервером некорректно настроена связь. Например, Nginx производит обращение к порту 8080, а веб-сервер Apache «слушает» на 8081. В этом случае необходимо скорректировать настройки веб-сервера. 

Если вам не удалось самостоятельно устранить ошибку 502, обратитесь в техподдержку.

Справочный центр | Как исправить ошибку «502 Bad Gateway»


Ошибка 502 возникает, когда запросы от посетителей до сайта идут не напрямую на Apache-сервер, а через дополнительный шлюз nginx. Apache получает запрос, но не смог его обработать и передал сообщение об ошибке. 

Рассмотрим подробнее причины появления ошибки 502:

  • Снижение скорости выполнения запросов в nginx.
  • Перегруженность сервера из-за нехватки ресурсов — оперативной памяти, места на диске.
  • Использование устаревших CMS и плагинов.
  • Плохой код сайта.
  • Ошибки конфигурации сети — проблемы с DNS, маршрутизация, блокировка файрволом, используемым на сервере, проблемы у провайдера.

Для избежания возникновения ошибки:

  • Оптимизируйте и исправляйте медленные MySQL-запросы;
  • Обновляйте CMS и плагины.
  • Избегайте проблем с маршрутизацией и отслеживайте перезагрузки и атаки на сервер.
  • Отключите скрипты мониторинга и отслеживания посетителей на сайте, потому что каждое действие посетителей выполняет запрос к базе данных.

Проверьте, в каких таблицах находится больше всего записей. Для этого перейдите в панель управления вашей услуги.

Откройте панель управления вашей услугой:

В меню слева разверните блок Инструменты (1) и выберите phpMyAdmin (2)

Авторизуйтесь на платформе.

Перейдите в просмотр таблиц и проверьте, какие из них содержат большое количество записей. Для этого выберите пользователя (1), отфильтруйте показ файлов по размеру файлов (2) и перейдите в просмотр структуры наибольших файлов (3).

Изучите столбец EVENT_NAME. Если какая-то из таблиц не содержит ценной информации, а только логи, статистику или кэш, то очистите или удалите её.

Ошибка HTTP 502 Bad Gateway

Эта ошибка имеет гораздо более простые причины, чем http 504. Она так же встречается в системах, где nginx играет роль proxy-сервера (не важно, fastcgi или http backend используется).

Nginx возвращает статус ответа HTTP-протокола 502 ровно в одном случае - он не смог достучатся до backend-сервера.

Первое, что нужно сделать - это проверить, работает ли наш backend-сервер (apache, php-fpm, unicorn, nodejs). Вот пример для php-fpm под управлением debian 8:

 root@host# /etc/init.d/php5-fpm status ● php5-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php5-fpm.service; enabled; vendor preset: enabled) Active: inactive (dead) since Mon 2017-01-23 10:20:12 UTC; 41ms ago Process: 8011 ExecStart=/usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf (code=exited, status=0/SUCCESS) Process: 8005 ExecStartPre=/usr/lib/php5/php5-fpm-checkconf (code=exited, status=0/SUCCESS) Main PID: 8011 (code=exited, status=0/SUCCESS) Status: "Ready to handle connections"

Мы видим, что FPM упал и его нужно поднять:

 root@host# /etc/init.d/php5-fpm start

Причины падения могут быть разные, обычно это закончившаяся память. Увидеть это можно в выводе dmesg:

 root@host# dmesg ... [2358564.917301] Out of memory: Kill process 13462 (php5-fpm) score 22 or sacrifice child [2358564.917307] Killed process 13462 (php5-fpm) total-vm:2654948kB, anon-rss:92448kB, file-rss:19408kB

Сразу хочу сказать, что в PHP часто утекает память и в настройках PHP-FPM обязательно нужно указывать max_requests

 max_requests = 500

А что, если FPM не упал?

Да, такая ситуация тоже возможна. Обычно она случается, когда количество одновременных запросов превышает 

pm.max_children или process.max. Узнать о наступлении такой ситуации можно из лога php-fpm, а исправить увеличением количества процессов (естественно, если ресурсов для этого достаточно).

Разовые 502

Иногда встречается "разовое" появление ошибок 502 при reload или restart php-fpm, apache, unicorn и других backend-серверов. Обычно это говорит о не совсем корректной схеме деплоя (выкладке нового кода). В таком случае нужно пересматривать именно её.

HTTP 502 и nodejs

Наиболее часто эта ошибка встречается при использовании websockets. Дело в том, что для их работы требуется специальная настройка nginx: http://nginx.org/ru/docs/http/websocket.html

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

В виду того, что очень часто javascript-код "течет" и забивает всю память, рекомендуется использовать 

 Restart=always

При настройке сервиса в systemd. К сожалению, проблемы утечек памяти лежат целиком на совести разработчиков, а также очень сложны сами по себе, поэтому перезапуск "упавших" процессов и резервирование становится нормой в мире nodejs.

HTTP 502 и unicorn

Долгий запуск демона unicorn приводит к нескольким минутам ожидания и получению ошибок 502 и 504. При деплое рекомендуется использовать не "жесткую перезагрузку" unicorn, а сигнал USR2 для подмены старых рабочих процессов новыми налету.

HTTP 502 и localhost

Бывает так, что бакенд слушает исключительно ipv4 адрес 127.0.0.1, а localhost ведет на ipv6 адрес, на котором ничего нет. В таком случае рекомендуется жестко прописывать адреса - либо 127.0.0.1 для ipv4, либо соответствующий адрес для ipv6.

Итог

502-ой статус ответа говорит об однозначной невозможности открыть соединение к backend. Конечно, в сложных системах это может быть связанно с сетью, фаерволом и другими технологическими деталями конкретных систем.

Error: 504 Gateway Time-out (502 Bad Gateway)