Ошибка 502 Bad Gateway: что это значит и как ее исправить

Что такое ошибка 502 — Bad Gateway

Файлы сайта в интернете находятся на физическом оборудовании. Чтобы получить и отобразить их, браузер делает запрос к этому «железу». Если файлы не переданы, возникают ошибки 5хх: например, 500, 503, 504 (500–512).

Клиент видит уведомление «Error 502». Иногда оно может сопровождаться дополнительным пояснением «Bad Gateway» («плохой шлюз»). В зависимости от конкретной ситуации появляются:

• 502 Service Temporarily Overloaded;
• 502 Bad Gateway Nginx;
• Bad 502 Gateway;
• 502 Server Error: The server encountered a temporary error and could not complete your request и прочие. 

Что означает «плохой шлюз»? Один сервер не смог получить корректный ответ от другого. Из-за этого запрос не обработан, возникла ошибка. 

В отдельных случаях — например, при использовании ARR (Application Request Routing) на Windows Server — рядом с 502 могут появляться дополнительные цифры. Они помогают понять, что конкретно случилось и где искать источники неполадок:

• 502.3 The Operation Time Out — превышено время ожидания;
• 502.3 The Connection with Server was terminated Abnormally — в середине потока отключено соединение между ARR и серверным компьютером;
• 502.3 The Server Return An Invalid or unrecognized response — недопустимый ответ;
• 502.4 No appropriate server could be found to route the request — не удалось найти соответствующий хост для маршрутизации запроса.

Ниже разберем, почему возникают неполадки и что с ними можно сделать.

Причины возникновения ошибки

«Плохой шлюз» — неполадка, которая возникла на бэкенде. В спецификации RFC 7231 (раздел 6.6.3: 502 Bad Gateway) Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content находится описание: сервер, выступая в качестве шлюза или прокси, получил неверный ответ от другого сервера, к которому обращался для выполнения запроса. 

Основные «виновники» 502: 

• прокси;
• DNS;
• хостинг-серверы.

Перегрузка сервера

Сервер не успевает обрабатывать запросы, потому что вычислительных ресурсов недостаточно. Это может случиться, если:

• увеличилось количество посетителей. Запустили рекламную кампанию (блогеры, контекст, таргетинг), резко выросло количество пользователей, ресурсов не хватает. Все начинает тормозить, а на определенном этапе появляется ошибка; 
• плохо оптимизирован код. Используются «тяжелые скрипты», из-за которых даже при небольшом количестве пользователей серьезно увеличивается нагрузка на ресурс;
• проводится DDoS-атака (Distributed Denial of Service). Имитация увеличения числа пользователей может стать причиной выхода системы из строя. Чтобы фильтровать трафик и защищать ресурс от DDoS, стоит использовать специальные инструменты — например, Anti-DDoS Qrator (Qrator Labs: Anti-DDoS). Сервис перенаправляет запросы к веб-сервисам через облако Qrator. Оно анализирует и фильтрует трафик, уменьшает количество ботов, обеспечивает стабильность работы по протоколам HTTP и HTTPS, защищает от DDoS-атак на уровнях L2, L3 и L4.

Проблемы DNS (Domain Name System)

DNS — протокол передачи данных по сети. 

Domain Name System — это «справочник интернета», который можно сравнить с телефонной книгой. Если вы знаете имя и фамилию человека, в книге можно найти номер телефона (и наоборот). DNS работает похожим образом. 

Пользователь вводит в адресную строку «имя»: например, https://gitverse.ru/. DNS «соединяет» с нужным ресурсом и превращает 178.248.237.106 в gitverse.ru. Для этого у Domain Name System есть собственная «телефонная книга», в которой IP-адрес сайта связан с доменным именем.

Протокол DNS используется для доступа к облачным ресурсам. Но неправильная конфигурация Domain Name System приводит к тому, что запросы направляются не на те адреса. В результате появляется 502. Для управления доменными именами в рамках VPC используют специальные инструменты — например, Domain Name Service (DNS) от Cloud.ru.

Проблемы с сетью

Сетевые устройства и маршрутизаторы часто вызывают 502. В частности, это касается блокировки брандмауэром или перегрузок устройств.

Ошибка на стороне сервера

Ошибка 502 у пользователя появляется по нескольким причинам:

• сбои конфигурации — сервер сбоит, отклоняет запросы или пропускает их;
• обновления и конфликты — свежая версия ПО приводит к тому, что часть функций не работает.

Способы устранения ошибки

Как правило, с «плохими шлюзами» работают системные администраторы и владельцы веб-ресурсов. 

Что делать, если вы пользователь

Рядовой пользователь вряд ли сможет устранить 502. Но определенные шаги можно попробовать предпринять: 

• перезагрузить страницу;
• проверить подключение к интернету;
• очистить кэш и куки браузера;
• сбросить DNS-кэш (Win + R —> cmd.exe —> ipconfig /flushdns для Windows, Ctrl + Alt + T —> sudo /etc/init.d/nscd restart на Linux, Command + Space —> sudo killall -HUP mDNSResponder для MacOS).

Что делать, если вы администратор сайта

Первым делом нужно проверить системные лог-файлы. Обычно логи сохраняются в специальных каталогах:

• /var/log/nginx/error.log — для Nginx;
• /var/log/apache2/error.log — для Apache;
• /var/log/mysql/error.log — для MySQL;
• logcfg.xml — для 1С;
• /var/log/php7.4-fpm.log — для PHP-FPM;
• debug.log — для WordPress.

Основные команды:

• sudo journalctl -xe — проверить журнал syslog (системные логи);
• tail -f /var/log/nginx/error.log — проверить лог-файлы Nginx;
• docker logs <container_id_or_name> — получить логи Docker-контейнера;
• kubectl logs <pod_name> -c <container_name> --namespace=<namespace> — проверить логи в Kubernetes. 

Для анализа и мониторинга ресурсов используют разные утилиты — top, htop, atop, vmstat. Расширенный мониторинг предоставляют инструменты Prometheus, Grafana. Кроссплатформенный ИТ-мониторинг и сервисы телеметрии предоставляет Platform V Monitor. 

В примере ниже с помощью лог-файлов atop можно увидеть, что на серверном компьютере закончилась оперативная память. Из-за этого были остановлены процессы MySQL или Apache. До того, как ОП закончилась, ее активно использовали php-скрипты сайта. В данном случае логи показывают, что проблема в сайтах и скриптах на них: они потребляют слишком много ресурсов.

В чем может быть дело? Частые причины — установленные плагины WordPress, неправильный код, DDoS-атака, повышение нагрузки из-за наплыва пользователей.

Проверить настройки сервера 

Если «виновник» — origin web server (к примеру, веб-хостинг), пользователям возвращается ошибка 502.Чтобы устранить неполадки, нужно проверить нагрузку на железо, сбои в сети, заблокированные приложения и службы. 

Стоит уточнить  проблемы со сжатием. К примеру, исходный сервер обслуживает сжатый контент в кодировке gzip, но не обновляет заголовок content-length. Или пытается обработать некорректный сжатый контент в формате gzip. Чтобы устранить ошибку, можно попробовать отключить сжатие (compression).

Сообщение с 502 error могут вызвать и другие сервисы — к примеру, CDN (content delivery network).

Проверить завершение процесса 

Одна из самых частых ситуаций — процесс, к которому обращаемся при запросе, завершился (перестал работать и быть доступным).

К примеру, это может быть php-fpm — шлюз для генерации динамического содержимого. Чтобы устранить неполадку, нужно (на примере Nginx):

1. Проверить, запущен ли сервис — команда ps aux | grep php.
2. Перезапустить процессы — sudo systemctl restart php-fpm.
3. Запустить остановленный процесс — sudo systemctl start php-fpm.

Среди основных факторов — отсутствие прав доступа, удаление, переименование и перемещение файла, остановка вручную.

Изменить время отклика и размер буфера

Из-за того, что время ожидания ответа и размер буфера FastCGI настроены неправильно, система не может обработать большой (тяжелый) запрос. В таком случае стоит изменить файл конфигурации.

location ~ \.php$ {

    fastcgi_pass unix:/var/run/php7.0-fpm.sock;

    include fastcgi_params;

    # Настройка времени ожидания

    fastcgi_read_timeout 600s; # Время ожидания чтения ответа от FastCGI (10 минут)

    fastcgi_send_timeout 600s; # Время ожидания отправки запроса FastCGI

    # Настройки буферов

    fastcgi_buffers 16 32k; # Количество и размер буферов для ответа

    fastcgi_buffer_size 64k; # Размер первого буфера

    fastcgi_busy_buffers_size 128k; # Общий размер занятых буферов

    fastcgi_temp_file_write_size 256k; # Размер временного файла для записи

}

Проверить наличие файлов и адрес файла сокета для PHP-FPM

В конфигурации (например, /etc/nginx/nginx.conf) нужно проверить, существует ли файл сокета PHP-FPM и где он находится. Параметр fastcgi_pass указывает, где искать PHP-FPM:

location ~ \.php$ {

       fastcgi_pass unix:/var/run/php7.0-fpm.sock;

       include fastcgi_params;

   }

Далее можно:

1. Проверить существование файла — команда ls -l /var/run/php7.0-fpm.sock. Если он есть, вы увидите логи. Если не существует — ошибку.
2. Уточнить версию PHP — /var/run/php/php7.4-fpm.sock. Версия должна совпадать с установленной на железе. Если стоит PHP 7.4, то и файл должен содержать php7.4-fpm.sock.
3. Перезапустить службы — sudo systemctl restart nginx или sudo systemctl restart php7.4-fpm.

Выводы 

502 — сообщение о том, что есть неполадки на стороне:

• прокси;
• DNS;
• хостинг-серверов.

Уведомление может быть коротким («Error 502») или содержать дополнительную информацию («Bad Gateway: Registered endpoint failed to handle the request, Temporary Error», «502 Service Temporarily Overloaded», «502 — Web server received an invalid response while acting as a gateway or proxy server».