Ошибка 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. Конечно, в сложных системах это может быть связанно с сетью, фаерволом и другими технологическими деталями конкретных систем.