Что означает 502 bad gateway nginx: Ошибка 502 Bad Gateway Nginx — что это значит и как исправить?

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

Иногда, путешествуя по просторам Интернет и зайдя на тот или иной сайт, Вы можете увидеть там не нужную информацию, а белый фон и на нём крупными буквами ошибка: 502 Bad Gateway. Что это значит? Ничего хорошего, на самом деле. Это сообщение выдаёт веб-сервер nginx при возникновении некоторых проблем в работе. Если Вы попытаетесь открыть другие страницы на этом же сайте по сохранённым ссылкам, то успехом это так же не увенчается. Что же делать? А это зависит от того — кем Вы являетесь для этого сайта. 

Если Вы простой посетитель, то решение одно — ждать пока администрация веб-ресурса починит сервис. Как долго? Сложно сказать. Если это крупный портал какой-нибудь компании, фирмы или гос.учереждения, то админ должен восстановить работу сайта в ближайшее время. Если же это личный блог какого-нибудь Васи Пупкина, то вполне вероятно что никто ничего чинить не будет, так как Вася про свой блог забыл и он ему не нужен.

а) Если Вам очень нужна находящаяся на страничке информация, то либо попробуйте найти контакты администрации и связаться с ней по почте или через регистратора или хостера, либо воспользуйтесь веб-кешем поисковиков, введя ссылку на сайт или страничку в поисковую строку поисковика и открыв сохранённую копию.
б) Очень часто ошибка Nginx 502 означает что интересующий веб-ресурс перегружен. Что делать? Опять же только ждать пока нагрузка уменьшится, периодически обновляя страничку в браузере.

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

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

Хуже, если Ваш сайт расположен на виртуальном (VPS) или выделенном (VDS) сервере. В этом случае, обычно, переложить проблему с больной головы на здоровую (читай: со своей на техподдержку хостера) не получится и придётся всё исправлять самостоятельно. Что делать?
Для начала, попробуйте перезапустить сервер nginx. На CentOS, например, это делается командой:

service nginx restart

Если он у Вас используется, как фронт-энд для сервера Apache (httpd), то последний мог вылететь или повиснуть — перезапустите и его:

service httpd restart

Не помогло — посмотрите текущую загрузку сервера с помощью команды:

top -c

Особенно обратите внимание на значение параметра load average:

Он должен быть примерно равен количеству ядер процессора, ну плюс/минус 2. Если значение load average больше 10, то стоит бить тревогу — что-то сильно грузит процессор сервера. Часто за этим стоит направленная атака DDOS. Выясняйте причину — скорее всего её устранение вернёт Ваш сайт к нормальной жизни.

502 bad gateway Nginx как исправить ошибку

502 bad gateway nginx — ошибка, которая выводится веб-сервером Nginx в случае если он не может дождаться ответа от какого-либо сервиса. Nginx сам по себе не может обрабатывать скрипты, поэтому чаще всего он является фронтэндом для другого сервиса. Это Apache или PHP-FPM в случае если обрабатываются PHP скрипты, также бэкендом может быть Unicorn UWSGI или что-то иное.

 

Поскольку Nginx обычно просто проксирует запросы сам только отдавая статику работа приложения зависит также от бэкенда.

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

 

Просматриваем файл и выясняем куда Nginx должен направлять запросы

less /etc/nginx/sites-enabled/SITENAME

 

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

Apache

/etc/init.d/apache2 restart

PHP-FPM

/etc/init.d/php-fpm restart

 

Если возникают ошибки стоит смотреть логи соответствующего сервиса и искать ошибку в конфигурации.

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

Простой перезапуск для этого случая решит вопрос

 

 

Бэкенд может быть вынесен на другую серверную машину — это также можно выяснить изучив конфиг Nginx. Процесс устранения ошибки будет отличаться только тем, что запускать службы потребуется предварительно подключившись к нужному серверу по SSH.

 

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

Ошибка 502 Bad Gateway nginx. Как исправить HTTP Error 502. Хостинг в деталях

Эта статья поможет разобраться, почему на сайтах время от времени появляется ошибка 502 Bad Gateway nginx (HTTP Error 502) и как эту проблему решить.

Если вы посетитель

Если вы не можете попасть на сайт из-за ошибки 502, сделать можно не так много:

• Перезагрузить страницу, сбросив кеш (Ctrl+Shift+R, Ctrl+F5 или Shift+F5). К сожалению, это помогает не так часто, как хотелось бы.
• Зайти попозже. Через минуту, через полчаса, ночью или рано утром. Скорее всего сервер перегружен. Исправить это вы не сможете, этим должен заняться администратор сайта. Если сайт для вас важный, и у вас есть время, напишите администратору письмо. Чем больше обращений, тем вероятнее, что на проблему обратят внимание и серьезно ей займутся.

Если вы администратор сайта

Если эта ошибка возникает, значит HTTP-запросы от посетителей к вашему сайту идут через так называемый «шлюз», программу-посредник. Например, если на хостинге перед веб-сервером Apache стоит веб-сервер nginx, то nginx будет шлюзом.

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

Если PHP работает в режиме FastCGI, то любой веб-сервер перед ним будет шлюзом.

Почему Apache не смог обработать запрос? Как это исправить?

Скорее всего, если сайт раньше работал, а теперь не открывается, дело не в ошибках конфигурации среды. Причина может быть в нехватке ресурсов сервера, и, следовательно, в невозможности обслужить всех клиентов. В частности, проблема может быть в нехватке оперативной памяти. Или вы можете упираться в какое-то ограничение, например, на количество процессов. Иногда Apache или ваше приложение могут периодически падать/перезапускаться, в эти моменты фронт-серверу тоже ничего не остаётся, кроме как отдавать ошибку 502. Такое может случиться и на VPS, и на shared-хостинге.

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

Возможен случай, когда ошибка 502 постоянная, возникла на этапе настройки сервера. Его сейчас подробно рассматривать не будем. Скорее всего, фронт-сервер и то, что находится за ним, не состыкованы. Или вообще Apache не запущен.

Если у вас VPS

Если PHP работает через FastCGI, то на сервере может не хватать php-cgi процессов в моменты, когда на сайте много посетителей, пришел прожорливый бот, кто-то скачивает ваш сайт целиком или идёт DoS-атака. Веб-серверу нужно бы запустить дополнительные процессы, но памяти под них уже нет. Значит, нужно добавить памяти либо оптимизировать расход доступной

• Запустите команду top. Посмотрите, есть ли свободная память и запущен ли Apache.
• Посмотрите логи Apache и nginx (ошибки 502 попадают в него). Есть паразитная активность? Если есть, баньте по ip, настраивайте Fail2ban, подключайте защиту от DdoS.
• Если получилось ограничить количество запросов к серверу, перезапустите Apache.
• Если в логах всё нормально, но мало свободной памяти, и есть возможность ее оперативно добавить, попробуйте это сделать. Сейчас у многих провайдеров это делается в биллинге буквально за пару минут.
• Если же команда top показывает, что свободная память есть, возможно, дело в установленных лимитах на количество php-cgi процессов. Нужно смотреть конфигурационные файлы Apache (httpd.conf), особенно секцию модуля, отвечающего за FastCGI (mod_fascgi или mod_fastcgid), и увеличивать лимиты.

Если дело в нехватке памяти, то в логах будут ошибки OOM (out of memory). Когда ОС очень нужна память, то ядро может попытаться освободить её при помощи механизма OOM killer, просто убивая активные процессы. Например, здесь пришлось пожертвовать Апачем:
Out of memory: kill process 1718 (apache2) score 56789 or a child
Killed process 22504 (apache2)

Другой случай — когда, Apache периодически падает/перезапускается независимо от текущей нагрузки на сайт. В error.log может быть написано:

[core:notice] [pid 5795] AH00052: child pid 5858 exit signal Segmentation fault (11)
[mpm_prefork:notice] [pid 5795] AH00169: caught SIGTERM, shutting down

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

Как исправить ошибку 502 Bad Gateway в WordPress

Вы когда-нибудь видели очень раздражающую и разочаровывающую ошибку 502 на сайте WordPress? Да, я думаю, мы все столкнулись с проблемой. Знаете ли вы, что означает ошибка 502 «Bad Gateway»? Вы знаете, как решить проблему? В этом сообщении в блоге мы предоставим вам подробную информацию о ошибке «502 Bad Gateway» в WordPress и расскажем вам, как устранить ошибку «502 Bad Gateway» в WordPress. 

Что означает ошибка 502 Bad Gateway?

Ошибка 502 Bad Gateway – это код состояния HTTP, который означает, что один сервер в Интернете получил неверный ответ от другого сервера. Техническими словами 502 Bad Gateway означает, что сервер прокси (шлюза) не смог получить действительный или любой ответ от восходящего сервера.

В официальной документации W3.org указано, что коды состояния HTTP, начинающиеся с 5 (5xxx), относятся к ошибкам, возникающим при неправильной связи между несколькими серверами.

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

502 Bad Gateway – Разнообразие ошибок

Ошибка 502 Bad Gateway имеет несколько различных вариантов из-за различных интернет-браузеров и различных веб-серверов и операционных систем. Ниже приведены некоторые из самых популярных вариантов ошибки 502 Bad Gateway.

• “502 Bad Gateway”
• “Error 502”
• “HTTP Error 502 – Bad Gateway”
• “502 Proxy Error”
• “HTTP 502”
• “502 Service Temporarily Overloaded
• “502 Server Error: The server encountered a temporary error and could not complete your request”
• “502. That’s an error. The server encountered a temporary error and could not complete your request. Please try again in 30 seconds. That’s all we know.”
• Пустой белый экран

Как исправить ошибку 502 Bad Gateway (3 возможных решения)

Ошибка 502 Bad Gateway, как правило, связана с сетью или сервером. Но это также может быть проблемой на стороне клиента. Таким образом, мы будем устранять ошибки на сервере и на стороне клиента. Ниже приведены некоторые шаги для проверки и устранения проблем.

1. Проверьте свой сервер

Если вы видите ошибку, как показано на рисунке, скорее всего, ошибка находится на вашем веб-сервере.
Давайте проверим вашу конфигурацию веб-сервера, в этом случае на сервере работает Nginx. WordPress работает на PHP и MySQL. Итак, в nginx нам нужно проверить, как обрабатываются файлы PHP. Найдите “location ~ \.php$” в вашем блоке сервера nginx.

ssh @ your _ip -p7022

Согласно конфигурации nginx, как показано на рисунке, файлы PHP обрабатываются fastcgi, который выполняется на порте 9000.
Давайте проверим, что работает на порту

netstat -pltn | grep 9000

 

Если вы не видите результата после выдачи команды, значит процесс умер. Вот почему вы видите ошибочную ошибку шлюза 502.

В последних CentOS и Ubuntu вы можете вызвать следующую команду, чтобы увидеть, от чего должен запускаться процесс:

systemctl list-unit-files | grep fpm

Выполните эту команду для запуска службы:

systemctl start php7.0-fpm

 

Теперь перейдите в свой веб-браузер и проверьте свой сайт.

Если вы используете CloudFlare и видите ошибку 502 Bad Gateway, как показано на рисунке ниже, скорее всего, ваш веб-сервер не работает. Вы можете попробовать перезапустить apache или nginx, в зависимости от того, какой веб-сервер вы используете.

2. Очистите кеш.

Если первое решение было выполнено, но вы по-прежнему видите ошибку плохого шлюза 502, ваш веб-браузер все еще полагается на свой кеш. Мы должны сообщить браузеру загрузить последнюю версию с сайта. Мы можем сделать это, нажав Ctrl+F5 на клавиатуре (Windows/Linux) или кнопку Shift + Reload на панели инструментов (браузер Safari) или CMD+Shift+R (Chrome и Firefox для пользователей Mac).

3. Отключить CDN

Если вы используете CloudFlare, вы можете попробовать отключить CDN некоторое время.

4. Проверьте свои скрипты.

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

5. Проверка плагинов и тем

Устранение неполадок, вызвавших ошибку, очень просто. Даже если у нас нет доступа к нашему серверу WordPress, мы можем отключить все плагины сразу, переименовав каталог плагинов. Для этого подключитесь к серверу с помощью SSH. Обратите внимание, что вы также можете сделать это с помощью FTP-клиента, например FileZilla.

Вы можете включить плагины один за другим, выполните следующие действия. Перейдите в свой каталог wp-content, мы увидим, что нет каталога плагинов, мы уже переименовали его.

Давайте создадим каталог плагинов и переместите плагин. Это автоматически включит плагин.

Иногда устранение ошибок WordPress проще, чем мы могли бы подумать. Но в какой-то момент это может быть очень сложно решить.

 

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

502 Bad Gateway: Что означает и как исправить

Добрый день!

В 99% случаев ошибка 502 Bad Gateway говорит о том, что возникли проблемы на стороне сервера, который обслуживает веб-сайт.

502 Bad Gateway — ошибка протокола http, которую отдает обслуживающий сайт сервер (frontend) при невозможности получить контент от вспомогательных серверов (backend).

Автор считает, что эти материалы могут вам помочь:

Принтер не печатает с компьютера ставит в очередь — как исправить?

как исправить ошибку сервисов google play

Черный экран на видео, инструкция по исправлению

Репозитории Centos — все, что необходимо знать

Что делать пользователю при ошибке 502 Bad Gateway:

1. При возможности, сообщите администрации сайта о возникшей ошибке. Это можно сделать через Twitter, социальные сети или по электронной почте.
2. Зайдите на сайт позднее. В штате всех нормальных интернет-проектов есть дежурные администраторы, которые должны отследить эту ошибку и максимально быстро вернуть сайт в работоспособное состояние.
3. Если сайт не работает долгое время, попробуйте найти нужную информацию на другом сайте.

Что делать администратору сайта при ошибке 502 Bad Gateway:

Почти всегда ошибку 502 Bad Gateway отдает пользователю nginx. Это означает, что вы используете nginx в качестве frontend сервера и php-fpm или apache в качестве backend сервера. Ваш backend сервер отказал и ему необходимо вернуть работоспособность. Рекомендуемая последовательность действий для быстрейшего восстановления обслуживания:

1. Перезагрузите ваш Apache или php-fpm сервер (сделайте рестарт сервиса). Сервис мог подвиснуть, например, из-за большой нагрузки.
2. Проверьте работоспособность вспомогательных служб, таких как MySQL и Memcached. Редко, но они также могут стать причиной ошибки 502 Bad Gateway.
3. Если один из сервисов не стартует — проверьте свободное место на диске сервера командой df -h, если место кончилось — срочно освободите его и рестартуйте службы.
4. Проверьте нагрузку на сервер с помощью команды top, если она очень большая (показатель la больше 10) — перезагрузите сервер полностью с помощью команды reboot.

Если у вас остались вопросы или нужны уточнения — пожалуйста, задайте вопрос или оставьте комментарий.

Я всегда рад помочь вам!

Ошибка 502 bad gateway — что это значит, как исправить?

Рано или поздно каждый пользователь всемирной сети сталкивается с различными ошибками на сайтах. Друг скидывает ссылку на какую-нибудь понравившуюся вещь, мы ее открываем на следующий день, а там вместо витрины отображается плашка, информирующая об ошибке? Что же делать? Сегодня мы рассмотрим ошибку 502 bad gateway и что это значит.

СОДЕРЖАНИЕ СТАТЬИ:

Техническое пояснение

Ошибка 502 bad gateway сообщает пользователю о том, что со стороны клиентского браузера прошел запрос на сервер, но последний его обработал не так как положено или вовсе удалил из очереди. В некоторых ситуациях сервер может запутаться в приоритетности запросов, и так же прекратить обработку. Оборудование «спрятанное» за шлюзом, после ошибки в обработке запроса отправляет данные для компиляции на стороне пользователя.

В чем проблема?

Причин появления 502 Bad Gateway достаточно много и практически почти все сбои прямо или косвенно указывают на неисправность в серверном оборудовании – как на причину недоступности страницы. Что означает пресловутое Bad gateway?  Дословно – плохой шлюз.

Вариантов очень много — это и превышение рабочей нагрузки на оборудование, и DDoS-атаки, срубающие все на своем пути. К слову о последних — если в data-центре падают обычно несколько десятков сайтов из-за рабочей нагруженности, то в случае целенаправленной атаки валится с глубокий нокаут все оборудование и ресурсы.

Существует несколько готовых решений для повышения устойчивости оборудования от атак и вместе с тем — это не все по карману. Нередко 502 error отображается и в случае нарушений работы DNS, неправильной настройки Apache и в силу других причин (коих не один десяток можно отыскать — те же прокси нередко вносят свой вклад во временный перевод всего комплекса из категории стабильно работающего оборудования в очень дорогостоящий металлолом (выражаясь фигурально)) на небольшой срок (пока ведется восстановление).

Автор рекомендует:

---

502 Bad Gateway с точки зрения сервера

Само собой, крупная атака влияет на работоспособность оборудования или ресурсов на нем. Таким образом, хостеру приходится восстанавливать прежний порядок — а значит – злоумышленники, использующие DDoS, не могут поставить крест на всех данных. Как исправить ситуацию?  Все не так плохо — данные могут быть восстановлены, если сделан бекап, вот только он не всегда снимается особенно в маленьких компаниях.

Опять-таки освоить это удается не всем — особенное новичкам, пришедшим в компанию прямо с диплома. В этой ситуации  можно внедрить RAID — массив. Если говорить очень отдаленно — подобный массив сочетает в себе несколько серверных HDD , объединяя их в 1 раздел. Сохранность информации тут обеспечивается тем, что данные с 1-го диска сразу дублируются еще 2-я, к примеру.

В маленьких конторах (тут речь в частности о СНГ и РФ) немало трудностей с квалификацией сотрудников. Консервативный подход в  воспитании будущих специалистов IT-сферы как минимум не принесет пользы. Выпустившийся студент, вряд ли разберется в уровнях RAID и их отличиях, а уж настроить все не сможет и подавно (если это не выпускник МГТУ им. Н. Э. Баумана или просто талантливый самоучка).

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

Сбои в работе возникают и из-за скриптов, работающих на PHP. Суть в том, что по факту выполнения, код не передается, из-за чего и начинаются проблемы. Применение не сайте большого количества сторонних процессов так же может вызвать 502 Bad gateway nginx.

---

Устранение причин (сервер)

Первым делом проводится глубокий анализ распределения данных. Не лишним будет и подкорректировать оперативную память в большую сторону. Далее придется отрегулировать лимит на количество параллельно обрабатываемых данных. Если конфигурация ошибочна — оборудование обязательно начнет «падать» первым делом именно в эту сторону. Как решить эту проблему?  Конечно, обращаемся к специалисту – человеку неопытному лучше не лезть в оборудование.

После того, как вышеописанные задачи выполнены — начинаем сокращать количество внешних сетевых запросов, после чего — стоит установить предельный тайминг обработки и загрузки ресурса. Тут то и станет понятно — что происходит на самом деле. Кроме того, притормаживание скорее всего сведется к минимуму.

---

Устранение причин (пользователь)

Как устраняется 502 Bad gateway на сервере мы теперь знаем (хоть и очень упрощенно). По эту сторону экрана нам не грозит DDOS-атака и прочие «радости жизни» современного дата-центра. Стойки работают, защита от DDOS-атак куплена, всё оптимизировали до изнеможения — кажется всё. Но не тут-то было, владельцы сайтов бомбят техподдержку хоста, а рядовые пользователи бомбят владельца сайта. Ну не работает и все тут.

Скорее всего, звонящие попали в тот самый процент исключений, когда «502 Bad gateway» появляется из-за несовместимости плагинов и надстроек в браузере. Для начала следует очистить cookie. Как это сделать —  узнаем дальше на примере обозревателя Яндекс. Алгоритм действий в разных браузерах аналогичен. К слову, на работоспособность может еще, и повлиять наличие VPN или Proxy сторонних программ.

• Переходим в «Настройки»

• Взору открывается следующая картина:

• Пролистываем страницу до раздела «Личные данные» в дополнительных настройках и нажимаем кнопку «Очистить историю загрузки»

Появляется окно следующего вида:

Здесь очень важно отметить галочкой пункты как на картинке. И никак иначе — случайно зазевавшись и поставив галочку на пункте «Сохранённые пароли» вы сотрете все данные авторизации из браузера, если резервной копии файла не было — придется потрудиться, вспоминая многочисленные пароли, адреса e-mail и аккаунты в соц. сетях.

---

Браузер Opera

Здесь всё так же — переходим в «Инструменты» и нажимаем на кнопку «Личные данные»

Готово!

---

Виртуальный хостинг

Отображение 502 Bad Gateway в силу специфической архитектурой для виртуализации явно указывает на проблемы со стороны хостинга. Эта проблема именуется оверселлинг (на 1 м сервере располагается огромное количество аккаунтов клиентов, и в определенные моменты общей загруженности (пик) аппаратные ресурсы уже исчерпаны. Тут понадобится перераспределение базы аккаунтов и общая оптимизация рабочего процесса — чего на ходу (во время DDoS) не сделать.

Вот мы и рассмотрели ошибку 502 bad gateway  и что это значит , а также способ устранения ее.

Ошибка 502 bad gateway — Узнай что это значит Как исправить

 

Здравствуйте уважаемые друзья и гости блога! Продолжаю свою эпопею по возможным ошибкам на стороне сервера, которые возникают, так невзначай и начинают пугать своим присутствием окружающих веб-мастеров и просто проходящих мимо посетителей сайтов. На этот раз мой выбор пал на такой баг, как ошибка 502 bad gateway или если по русски — недопустимый шлюз!

Что же это за ошибка 502 такая, откуда она возникает и как ее исправить? Вот этими вопросами мы с вами сегодня и займемся!

Ошибка 502 что это?

Ошибка 502 Bad Gateway или как я уже выше говорил — недопустимый шлюз ознаменована тем, что ваш запрос посланный на сервер пришел туда, но по разного рода причинам не смог быть обработан там. Запрос попавший на сервер, где расположен сайт по которому Вы юзаете и выдающий ошибку 502, может быть расположен за шлюзом и может быть ошибка кроется в том, что у сервера не хватает мощности обработать все поступившие к нему запросы, которые выстроились в очередь. Вот он и глючит, выдавая ошибку 502, которая в свою очередь отправляется вам в браузер вместо вашего запроса.

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

Ошибка 502 — Причины ее появления

Самой важной причиной появления ошибки 502 Bad Gateway и на мой взгляд основной, является недостаточная мощность ресурсов на сервере, где располагается сайт, который выдает ошибку 502. Из-за нехватки ресурсов, сервер начинает тормозить, много думать и в конце концов выдает 502 ошибку.

Ресурсы сервера — это оперативная память, которая бывает, что не очень рационально используется на хостинге или ее очень мало для тех операций, которые происходят и сервер их просто не в силах обработать. Чтобы выявить эту проблему, необходимо узнать нагрузку на потребляемые ресурсы у диспетчера сервера и затем уже определить все затрачиваемые ресурсы. При выяснении этих проблем, Вы сможете узнать вышли ли Вы за рамки выделенного вам тарифного плана на своем хостинге или нет. Если вышли, то и ошибка 502 именно из-за этого и возникает.

Значит вам нужно изменить свой тарифный план на хостинге, посоветовавшись с вашим хостером через поддержку, а если выяснится, что это максимум, что хостер может вам предложить, то бегите от него быстрее на другой, более мощный хостинг, например МакХост. Этот хостинг уже испытан временем и множеством веб-мастеров, которые очень им довольны, включая и меня. Не очень скромно, но это именно так!

Это еще не все причины по которым может возникать ошибка 502 Bad Gateway — недопустимый шлюз. Сейчас мы с вами еще рассмотрим возможные причины ее появления.

Кроме основной причины, описанной мной выше, есть еще типичные причины возникновения данной ошибки …

Типичные причины появления ошибки 502

Давайте выясним типичные причины нехватки ресурсов на сервере, которые приводят к тому, что появляется ошибка 502:

• Очень большое количество посетителей на вашем сайте одновременно.  И если ваш сервер не рассчитан на такое количество одновременных посетителей, использующих автоматизированные системы на нем (например поисковую автоматизированную систему на сайте), то это и есть причина появления 502 ошибки. Еще может быть причиной плагин, который использует много ресурсов для обработки данных с сервера.
• Следующая причина возникновения ошибки 502 — хакерская атака на сайт. следствием чего будет очень высокая нагрузка на сервер, что также выдает — ошибка 502  Bad Gateway.
• Также эта ошибка может возникать из-за неправильной конфигурации сервера или несовместимых программных и аппаратных решений на сервере (выяснить через техподдержку!).
• Загрузка на сервер больших и тяжелых файлов, с которыми он просто не в силах справиться из-за неустойчивого соединения или не хватки, опять же той самой, пресловутой мощности.
• Если ошибка 502 возникает на ровном месте, практически спонтанно, то это скорее всего, что ваш хостер разместил огромное количество аккаунтов клиентов. И это в свою очередь привело к оверселлингу — нехватка ресурсов сервера в пиковые моменты из-за большой нагрузки на него лишними аккаунтами, не рассчитанными на нагрузку данного сервера (косяк хостера!).
• Когда сайт использует внешнее подключение различных скриптов и т.д., то когда возникают проблемы у вашего источника подключения, соответственно эти проблемы и возникнут на вашем сайте, что приведет к появлению бага — ошибка 502 Bad Gateway.

С причинами разобрались, теперь нам нужно узнать самое важное …

Ошибка 502 Bad Gateway — Как исправить?

Как и в возникновении причин ошибки 502, так и в ее устранении должен быть порядок! Поэтому я все расположил по пунктам:

• Первое, что вам нужно сделать при возникновении данной ошибки — это проанализировать ваш сервер. Узнайте нагрузку на него в текущий момент возникновения ошибки 502 или любых других ошибок (ошибка 301, ошибка 503). И при выяснении причины — высокая нагрузка на сервер из-за нехватки оперативной памяти, незамедлительно увеличьте ее, так как это самая важная составляющая работоспособности вашего сервера (посоветуйтесь с поддержкой хостинга!).
• При систематическом возникновении бага — ошибка 502, выясните правильность настроек лимитов на количество php-cgi процессов и их корректность на вашем сервере, опять же советуйтесь в своей поддержке хостинга!
• Если ваш сайт расположен на виртуальном хостинге и из-за этого есть причина думать, что возможно появление оверселлинга, смотрите выше в тексте, то подумайте о переносе своего сайта на более удобный и мощный хостинг, например МакХост. Только долго не думайте!
• Когда ошибка 502 возникает из-за высокого количества запросов к внешним ресурсам сети, постарайтесь снизить их количество и установите ограничение на время их ответа и загрузки, что в свое время значительно поможет вам отслеживать «тормоза» загрузки, так же поможет выявить проблему и автоматически ее обработать.

На этом все, что я вам хотел сегодня поведать про баг — ошибка 502  Bad Gateway и о том, как исправить данную ошибку.

Спасибо за внимание! И всем вам удачи и процветания!

Вы будете первым, кто поставит оценку!

Как решить 502 проблемы со шлюзом?

Обновлено 4 октября 2018 г.

Что означает 502 Bad Gateway ?

A 502 Bad Gateway указывает, что пограничный сервер (сервер, действующий как прокси) не смог получить действительный или какой-либо ответ от исходного сервера (также называемого восходящим сервером). Это может происходить по нескольким причинам, которые мы обсудим в следующем разделе. Если один из пограничных серверов KeyCDN получит ответ 502 Bad Gateway от вашего исходного сервера, KeyCDN вернет страницу 500 Origin Not Reachable .Чтобы лучше понять, как KeyCDN обрабатывает определенные коды ошибок, посетите нашу страницу с кодами ошибок CDN.

Каковы причины ответов 502 Bad Gateway ?

Есть три основных виновника, которые вызывают 502 Bad Gateway ответов. К ним относятся:

1. Доменное имя не разрешается: Доменное имя не разрешается на правильный IP или не разрешается ни на один IP. Важно отметить, что изменения DNS могут занять одно и то же время, пока они не станут полностью распространенными и активными в глобальном масштабе.Это зависит от TTL или времени жизни, определенного для каждой записи.
2. Исходный сервер не работает: Сервер недоступен, потому что он не работает или нет подключения к данному серверу.
3. Межсетевой экран блокирует запрос: Межсетевой экран блокирует связь между пограничными серверами и исходным сервером. Это также может быть вызвано плагинами безопасности вашей CMS. Некоторые системы защиты и смягчения DDoS-атак могут быть слишком активными и начать блокировать запросы с наших серверов доставки контента.

Как вы можете увидеть ошибку 502 Bad Gateway

В зависимости от вашего веб-сервера вы можете увидеть другую ошибку 502 .

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

• 502 Плохой шлюз
• Ошибка HTTP 502 — Плохой шлюз
• 502 Служба временно перегружена
• Ошибка 502
• 502 Ошибка прокси
• HTTP 502
• 502 Плохой шлюз NGINX

Вы можете более подробно увидеть, что конкретно влечет за собой ошибка, перейдя в файл журнала ошибок вашего веб-сервера.Вся информация об ошибках и диагностическая информация хранится в этом файле, что делает его ценным ресурсом для проверки, когда вам нужны более подробные сведения о конкретной ошибке. Вы можете найти этот файл в Apache, перейдя по адресу /var/log/apache2/error.log , а в Nginx — по адресу /var/log/nginx/error.log .

Как исправить ошибки 502 как веб-разработчик

Как веб-разработчик или владелец веб-сайта, вы можете столкнуться с ошибкой 502 Bad Gateway на исходном сервере по нескольким причинам.Таким образом, вам может потребоваться попробовать различные методы для решения проблемы. См. Список предложений ниже:

• Проверьте правильность разрешения вашего FQDN (полного доменного имени) с помощью нашего инструмента проверки DNS.
• Убедитесь, что ваш сервер доступен, используя тест ping или traceroute.
• Проверьте журналы брандмауэра, если вы видите необычные падения.
• Если вы являетесь пользователем Cloudflare, попробуйте отключить его, так как как только вы достигнете определенного предела, Cloudflare вернет вашим посетителям ошибку 502 Bad Gateway .

Как устранить ошибки 502 в качестве посетителя

Если вы посещаете веб-сайт и сталкиваетесь с ошибкой 502 Bad Gateway , то есть несколько вещей, которые вы можете попытаться решить. Хотя за основную проблему почти всегда отвечает веб-разработчик, посетители могут попробовать следующее:

• Выполните полное обновление в браузере. На Mac это делается нажатием Cmd + Shift + R .
• Очистите кеш браузера и удалите файлы cookie.Ваш браузер может удерживать определенные файлы, которые были сохранены после того, как вы посетили веб-сайт с ошибкой 502 .
• Перезагрузите компьютер / сетевое оборудование.
• Измените DNS-серверы. Если вы никогда не меняли их в прошлом, вероятно, у вас все еще есть серверы по умолчанию, назначенные вам вашим интернет-провайдером, попробуйте использовать открытые DNS-серверы, такие как общедоступный DNS Google.

.

NGINX 502 Bad Gateway: Gunicorn

Этот пост является частью серии по устранению неполадок, связанных с ошибками Bad Gateway NGINX 502. Если вы не используете Gunicorn, ознакомьтесь с другой нашей статьей об устранении неполадок NGINX 502 с PHP-FPM в качестве бэкэнда.

Gunicorn — популярный сервер приложений для приложений Python. Он использует интерфейс шлюза веб-сервера (WSGI), который определяет, как веб-сервер взаимодействует с приложением Python и делает запросы к нему. В производственной среде Gunicorn часто развертывается за веб-сервером NGINX.NGINX проксирует веб-запросы и передает их рабочим процессам Gunicorn, которые запускают приложение.

NGINX вернет ошибку 502 Bad Gateway, если он не может успешно передать запрос Gunicorn или если Gunicorn не отвечает. В этом посте мы рассмотрим некоторые распространенные причины ошибки 502 в стеке NGINX / Gunicorn и дадим рекомендации о том, где можно найти информацию, необходимую для устранения этих ошибок.

Изучите метрики, журналы и трассировки ошибок NGINX 502 Bad Gateway с помощью Datadog.

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

Если NGINX не может связаться с Gunicorn по любой из этих причин, он ответит ошибкой 502, отмечая это. в журнале доступа ( /var/log/nginx/access.log ), как показано в этом примере:

Копировать

  127.0.0.1 - - [08 / Янв / 2020: 18: 13: 50 +0000] "GET / HTTP / 1.1" 502 157 "-" "curl / 7.58.0"  

Журнал доступа NGINX не объясняет причину ошибки 502, но вы можете просмотреть его журнал ошибок ( / var / log / Nginx / ошибка.log ), чтобы узнать больше. Например, вот соответствующая запись в журнале ошибок NGINX, которая показывает, что причиной ошибки 502 является то, что сокет не существует, возможно, потому, что Gunicorn не запущен. (В следующем разделе мы рассмотрим, как обнаружить и исправить эту проблему.)

Скопируйте

  2020/01/08 18:13:50 [критический] 1078 # 1078: * 189 connect () в unix : /home/ubuntu/myproject/myproject.sock не удалось (2: нет такого файла или каталога) при подключении к восходящему потоку, клиент: 127.0.0.1, сервер: localhost, запрос: «GET / HTTP / 1.1», восходящий поток: «http: // unix: /home/ubuntu/myproject/myproject.sock: /», хост: «localhost»  

Gunicorn не работает

Если Gunicorn не запущен, NGINX вернет ошибку 502 для любого запроса, предназначенного для доступа к приложению Python. Если вы видите 502-е, сначала проверьте, работает ли Gunicorn. Например, на хосте Linux вы можете использовать команду ps , подобную этой, для поиска запущенных процессов Gunicorn:

На хосте, где Gunicorn обслуживает приложение Flask с именем myproject , вывод команды ps Команда будет выглядеть так:

Копировать

  ubuntu 3717 0.3 2.3 65104 23572 баллов / 0 С 15:45 0:00 gunicorn: master [myproject: app]
ubuntu 3720 0.0 2.0 78084 20576 pts / 0 S 15:45 0:00 gunicorn: worker [myproject: app]  

Если в выводе команды ps не отображаются основные или рабочие процессы Gunicorn, см. документацию для руководства по запуску вашего демона Gunicorn.

В производственной среде вам следует рассмотреть возможность использования systemd для запуска вашего приложения Python в качестве службы. Это может сделать ваше приложение более надежным и масштабируемым, поскольку демон Gunicorn автоматически начнет обслуживать ваше приложение Python при запуске вашего сервера или при запуске нового экземпляра.

После того, как ваш проект Gunicorn настроен как служба, вы можете использовать следующую команду, чтобы убедиться, что он запускается автоматически, когда ваш хост подключается:

Копировать

  sudo systemctl enable myproject.service  

Затем вы можете использовать list-unit-files команда для просмотра информации о вашей службе:

Copy

  sudo systemctl list-unit-files | grep myproject  

На сервере Linux, на котором установлен Gunicorn (даже если он не запущен), вывод этой команды будет:

Копировать

  myproject.служба включена  

Чтобы просмотреть информацию о вашей службе Gunicorn, используйте эту команду:

Копировать

  sudo systemctl is-active myproject  

Эта команда должна вернуть активных . Если этого не произошло, вы можете запустить службу с помощью:

Копировать

  sudo service myproject start  

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

Копировать

  sudo systemctl status myproject.service  

NGINX не может получить доступ к сокету

При запуске Gunicorn создает один или несколько сокетов TCP или Unix для связи с веб-сервером NGINX. Gunicorn использует эти сокеты для прослушивания запросов от NGINX.

Чтобы определить, была ли ошибка 502 вызвана неправильной конфигурацией сокета, убедитесь, что Gunicorn и NGINX настроены на использование одного и того же сокета. По умолчанию Gunicorn создает сокет TCP, расположенный по адресу 127.0.0.1:8000. Вы можете изменить это значение по умолчанию, используя переключатель Gunicorn --bind , чтобы указать другое местоположение — другой сокет TCP, сокет Unix или дескриптор файла.Показанная здесь команда запускает Gunicorn на локальном хосте, используя порт 4999. (Приложения Flask обычно работают на порту 5000, но это также порт, используемый агентом Datadog по умолчанию, поэтому мы скорректируем наши примеры, чтобы избежать конфликтов.)

Скопируйте

  gunicorn --bind 127.0.0.1:4999 myproject: app  

Если ваш проект Gunicorn работает как служба systemd, его файл модуля (например, /etc/systemd/system/myproject.service ) будет содержат строку ExecStart , в которой вы можете указать информацию о привязке, аналогично приведенной выше команде.Это показано в примере файла единицы измерения ниже:

Копировать

  [Unit]
Description = Описание проекта My Gunicorn
После того, как = network.target

[Обслуживание]
Пользователь = убунту
Группа = Nginx
WorkingDirectory = / дом / убунту / MyProject
ExecStart = / usr / bin / gunicorn --bind 127.0.0.1:4999 myproject: app

[Установить]
WantedBy = multi-user.target  

В качестве альтернативы ваше значение привязки может быть в файле конфигурации Gunicorn. См. Документацию Gunicorn для получения дополнительной информации.

Затем проверьте свой nginx.conf , чтобы убедиться, что соответствующий блок местоположения указывает ту же информацию о сокете, которую использует Gunicorn. В приведенном ниже примере содержится директива include , которая предлагает NGINX включать информацию прокси в заголовки своих запросов, и директиву proxy_pass , которая указывает тот же TCP-сокет, который указан в параметрах Gunicorn --bind , показанных выше.

Копия

  местонахождение / {
  включить proxy_params;
  proxy_pass http: // 127.0.0.1: 4999;
}  

Если Gunicorn прослушивает сокет Unix, параметр proxy_pass будет иметь значение в форме /path/to/socket.sock , как показано ниже:

Копировать

  proxy_pass unix: /home/ubuntu/myproject/myproject.sock;  

Как и в случае с сокетом TCP, вы можете предотвратить ошибку 502, убедившись, что путь к этому сокету совпадает с тем, который указан в конфигурации NGINX.

Сокеты Unix зависят от разрешений файловой системы Unix.Если вы используете сокет Unix, убедитесь, что его разрешения разрешают доступ для чтения и записи группе, работающей с NGINX. (Вы можете использовать флаг Gunicorn umask для обозначения разрешений сокета.) Если разрешения на сокет неверны, NGINX зарегистрирует ошибку 502 в своем журнале доступа и сообщение, подобное показанному ниже в журнале ошибок:

Копировать

  2020/03/02 20:31:26 [критический] 18749 # 18749: * 8551 connect () в unix: /home/ubuntu/myproject/myproject.sock не удалось (13: разрешение отказано) при подключении к вверх по течению, клиент: 127.0.0.1, сервер: localhost, запрос: «GET / HTTP / 1.1», восходящий поток: «http: // unix: /home/ubuntu/myproject/myproject.sock: /», хост: «localhost»  

Gunicorn истекает время ожидания

Если ваше приложение слишком долго отвечает, ваши пользователи столкнутся с ошибкой тайм-аута. По умолчанию время ожидания Gunicorn составляет 30 секунд, и вы можете изменить его в файле конфигурации, в командной строке или в файле модуля systemd. Если время ожидания Gunicorn меньше, чем время ожидания NGINX (по умолчанию 60 секунд), NGINX ответит ошибкой 502.Журнал ошибок NGINX, показанный ниже, показывает, что восходящий процесс, которым является Gunicorn, закрыл соединение перед отправкой правильного ответа. Другими словами, это журнал ошибок, который мы видим по истечении времени ожидания Gunicorn:

Копия

  2020/03/02 20:38:51 [ошибка] 30533 # 30533: * 17 восходящее соединение преждевременно закрыто при чтении заголовка ответа из восходящий поток, клиент: 127.0.0.1, сервер: localhost, запрос: «GET / HTTP / 1.1», восходящий поток: «http://127.0.0.1:4999/», хост: «localhost»  

Ваш журнал Gunicorn также может иметь соответствующую запись.(Gunicorn регистрирует stdout по умолчанию; информацию о настройке Gunicorn для входа в файл см. В документации.) Строка журнала ниже представляет собой пример из журнала Gunicorn, указывающий, что приложение слишком долго реагировало, и Gunicorn был убит рабочий поток:

Скопируйте

  [2020-03-02 18:15:05 +0000] [3417] [КРИТИЧЕСКИЙ] ВРЕМЯ АУТА РАБОТНИКА (pid: 3438)  

Вы можете увеличить значение тайм-аута Gunicorn, добавив --timeout флаг для команды Gunicorn, которую вы используете для запуска приложения - будь то в директиве ExecStart в вашем файле модуля, в сценарии запуска или с помощью командной строки, как показано ниже:

Копировать

  gunicorn --timeout 60 myproject: app  

Увеличение времени ожидания Gunicorn может вызвать другую проблему: время ожидания NGINX может истечь до получения ответа от Gunicorn.По умолчанию таймаут NGINX составляет 60 секунд; если вы увеличили тайм-аут Gunicorn выше 60 секунд, NGINX вернет ошибку 504 Gateway Timeout, если Gunicorn не ответит вовремя. Вы можете предотвратить это, также увеличив время ожидания NGINX. В приведенном ниже примере мы увеличили время ожидания до 90 секунд, добавив элемент fastcgi_read_timeout в блок http в файле /etc/nginx/nginx.conf :

Копировать

  http {
...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32 КБ;
    fastcgi_connect_timeout 90 с;
    fastcgi_send_timeout 90 с;
    fastcgi_read_timeout 90 с;
    proxy_read_timeout 90 с;
}  

Перезагрузите конфигурацию NGINX, чтобы применить это изменение:

Затем, чтобы определить, почему истекло время ожидания Gunicorn, вы можете собрать журналы и данные мониторинга производительности приложений (APM), которые могут выявить причины задержки внутри и вне вашего приложения.

Для устранения ошибок 502 вы можете собирать журналы с помощью службы управления журналами. Ведение журнала NGINX активно по умолчанию, и вы можете настроить местоположение, формат и уровень ведения журнала.

По умолчанию Gunicorn регистрирует информационные сообщения об активности сервера, включая запуск, завершение работы и состояние рабочих процессов Gunicorn. Вы можете добавить пользовательское ведение журнала в код приложения Python для сбора журналов, соответствующих любым заметным событиям, которые вы хотите отслеживать. Таким образом, когда вы видите ошибку 502 в журнале доступа NGINX, вы также можете ссылаться на журнал ошибок NGINX и журналы вашего приложения Python.Вы можете получить еще большую наглядность, собирая журналы от соответствующих технологий, таких как кэширующие серверы и базы данных, для корреляции с любыми журналами ошибок NGINX 502. Объединение этих журналов на единой платформе дает вам видимость всего вашего веб-стека, сокращая время, затрачиваемое на устранение неполадок, и сокращая MTTR.

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

Кроме того, визуализации APM в Datadog показывают частоту ошибок вашего приложения, объем запросов и задержку, предоставляя вам ценный контекст при исследовании проблем производительности, таких как ошибка 502.

Datadog Tracing Python поддерживает множество платформ Python, поэтому легко начать трассировку приложений, не внося никаких изменений в код.См. Документацию Datadog для получения информации о сборе данных APM из ваших приложений Python.

Чем быстрее вы сможете диагностировать и устранить ошибку 502 в вашем приложении, тем лучше. Datadog позволяет анализировать метрики, трассировки, журналы и данные о производительности сети по всей вашей инфраструктуре. Если вы уже являетесь клиентом Datadog, вы можете начать мониторинг NGINX, Gunicorn и других 400 других технологий. Если у вас еще нет учетной записи Datadog, подпишитесь на 14-дневную бесплатную пробную версию и начните работу за считанные минуты.

.

NGINX 502 Bad Gateway: PHP-FPM

Этот пост является частью серии по устранению неполадок, связанных с ошибками плохого шлюза NGINX 502. Если вы не используете PHP-FPM, ознакомьтесь с другой нашей статьей об устранении неполадок NGINX 502 с использованием Gunicorn в качестве бэкэнда.

Менеджер процессов PHP-FastCGI (PHP-FPM) - это демон для обработки запросов веб-сервера для приложений PHP. В производственной среде PHP-FPM часто развертывается за веб-сервером NGINX. NGINX проксирует веб-запросы и передает их рабочим процессам PHP-FPM, которые выполняют приложение PHP.

NGINX вернет ошибку 502 Bad Gateway, если не может успешно передать запрос в PHP-FPM или если PHP-FPM не отвечает. В этом посте мы рассмотрим некоторые распространенные причины ошибки 502 в стеке NGINX / PHP-FPM и дадим рекомендации относительно того, где можно найти информацию, которая поможет вам устранить эти ошибки.

Изучите метрики, журналы и трассировки ошибок NGINX 502 Bad Gateway с помощью Datadog.

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

Если NGINX не может связаться с PHP-FPM по любой из этих причин, он ответит ошибкой 502, отмечая это в своем журнале доступа ( / var / log / nginx / access.log ), как показано в этом примере:

Копировать

  127.0.0.1 - - [31 / Янв / 2020: 18: 30: 55 +0000] "GET / HTTP / 1.1" 502 182 "-" "curl / 7.58.0 " 

Журнал доступа NGINX не объясняет причину ошибки 502, но вы можете просмотреть его журнал ошибок ( /var/log/nginx/error.log ), чтобы узнать больше. Например, вот соответствующая запись в журнале ошибок NGINX, которая показывает, что причина ошибки 502 в том, что сокет не существует, возможно, потому, что PHP-FPM не запущен.(В следующем разделе мы рассмотрим, как обнаружить и исправить эту проблему.)

Копировать

  31.01.2020 18:30:55 [критический] 13617 # 13617: * 557 connect () to unix : /run/php/php7.2-fpm.sock не удалось (2: нет такого файла или каталога) при подключении к восходящему потоку, клиент: 127.0.0.1, сервер: localhost, запрос: «GET / HTTP / 1.1», восходящий поток: "fastcgi: // unix: /run/php/php7.2-fpm.sock:", host: "localhost"  

PHP-FPM не работает

Если PHP-FPM не запущен, NGINX будет возвращает ошибку 502 для любого запроса, предназначенного для достижения приложения PHP.Если вы видите сообщение 502, сначала проверьте, работает ли PHP-FPM. Например, на хосте Linux вы можете использовать команду ps , подобную этой, для поиска запущенных процессов PHP-FPM:

PHP-FPM организует свои рабочие процессы в группы, называемые пулами . В приведенном ниже примере выходных данных показано, что главный процесс PHP-FPM запущен, а также два рабочих процесса в пуле по умолчанию (с именем www ):

Копировать

  root 29852 0,0 2,2 435484 22396? Ssl 16:27 0:00 php-fpm: главный процесс (/ etc / php / 7.2 / FPM / PHP-fpm.conf)
www-data 29873 0,0 1,5 438112 15220? Sl 16:27 0:00 php-fpm: бассейн www
www-data 29874 0,0 1,6 438112 16976? Sl 16:27 0:00 php-fpm: pool www  

Если в выходных данных команды ps не отображаются какие-либо процессы master или pool PHP-FPM, вам необходимо запустить PHP-FPM для разрешения 502 ошибки.

В производственной среде вам следует рассмотреть возможность использования systemd для запуска PHP-FPM в качестве службы. Это может сделать ваше PHP-приложение более надежным и масштабируемым, так как демон PHP-FPM автоматически начнет обслуживать ваше PHP-приложение при запуске вашего сервера или при запуске нового экземпляра.PHP-FPM включен в исходный код PHP, поэтому вы можете добавить PHP-FPM в качестве службы systemd при настройке PHP.

После того, как ваш проект PHP-FPM настроен как служба, вы можете использовать следующую команду, чтобы убедиться, что он запускается автоматически при запуске вашего сервера:

Копировать

  sudo systemctl enable php7.2-fpm.service  

Затем вы можете использовать команду list-unit-files для просмотра информации о вашей службе:

Копировать

  sudo systemctl list-unit-files | grep -E 'php [^ fpm] * fpm'  

На PHP 7.2, на котором установлен PHP-FPM (даже если он не запущен), вывод этой команды будет:

Копировать

  php7.2-fpm.service enabled  

Чтобы просмотреть информацию о вашем PHP-FPM service, используйте эту команду:

Copy

  sudo systemctl is-active php7.2-fpm.service  

Эта команда должна вернуть активных . Если это не так, вы можете запустить службу с помощью:

Копировать

  sudo service php7.2-fpm start  

NGINX не может получить доступ к сокету

При запуске PHP-FPM он создает один или несколько сокетов TCP или Unix для связи с веб-сервером NGINX. Рабочие процессы PHP-FPM используют эти сокеты для прослушивания запросов от NGINX.

Чтобы определить, была ли ошибка 502 вызвана неправильной конфигурацией сокета, убедитесь, что PHP-FPM и NGINX настроены на использование одного и того же сокета. PHP-FPM использует отдельный файл конфигурации для каждого пула рабочих процессов; эти файлы расположены по адресу / etc / php / 7.2 / фпм / pool.d / . Каждый сокет пула определен в директиве listen в файле конфигурации пула. Например, указанная ниже директива прослушивания настраивает пул с именем mypool для использования сокета Unix, расположенного по адресу /run/php/mypool.sock :

Копировать

  listen = /run/php/mypool.sock  

Если NGINX не может получить доступ к сокету для определенного пула, вы можете определить, какой рабочий пул вовлечен в проблему, проверив, какой сокет назван в записи журнала ошибок NGINX.Например, если PHP-FPM не удалось запустить рабочий пул mypool , NGINX вернет 502, а его запись в журнале ошибок будет включать:

Скопировать

  connect () в unix: / run / php / mypool. sock failed (2: Нет такого файла или каталога)  

Проверьте файл nginx.conf , чтобы убедиться, что в соответствующем блоке location указан тот же сокет. Пример ниже содержит директиву include , которая загружает некоторую общую информацию о конфигурации для PHP-FPM, и директиву fastcgi_pass , которая указывает тот же сокет Unix, названный в mypool.conf выше.

Копия

  местонахождение / {
    включить сниппеты / fastcgi-php.conf;
    fastcgi_pass unix: /run/php/mypool.sock;
}  

Сокеты Unix подчиняются разрешениям файловой системы Unix. Файл конфигурации пула PHP-FPM определяет режим и владельца сокета, как показано здесь:

Копировать

  listen.owner = www-data
listen.group = www-data
listen.mode = 0660  

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

Копировать

  2020/02/20 17:12:03 [ cris] 3059 # 3059: * 4 connect () to unix: /run/php/mypool.sock не удалось (13: разрешение отклонено) при подключении к восходящему потоку, клиент: 127.0.0.1, сервер: localhost, запрос: "GET / HTTP /1.1 ", восходящий поток:" fastcgi: // unix: /run/php/mypool.sock: ", host:" localhost " 

Обратите внимание, что значения по умолчанию прослушивают.Владелец и listen.group соответствует владельцу и группе по умолчанию, в которой запущен NGINX, а listen.mode по умолчанию - 0660. Используя эти значения по умолчанию, NGINX должен иметь доступ к сокету.

Если PHP-FPM прослушивает сокет TCP, директива listen конфигурации пула будет иметь значение в форме адреса : порт , как показано ниже:

Как и в случае сокета Unix, вы можете предотвратить 502, подтвердив, что расположение этого сокета совпадает с указанным в конфигурации NGINX.

PHP-FPM истекает время ожидания

Если ваше приложение слишком долго отвечает, ваши пользователи столкнутся с ошибкой тайм-аута. Если таймаут PHP-FPM, который установлен в директиве request_terminate_timeout конфигурации пула (и по умолчанию равен 20 секундам), меньше таймаута NGINX (который по умолчанию составляет 60 секунд), NGINX ответит с ошибкой 502. Журнал ошибок NGINX, показанный ниже, показывает, что его восходящий процесс, которым является PHP-FPM, закрыл соединение перед отправкой действительного ответа.Другими словами, это журнал ошибок, который мы видим, когда время ожидания PHP-FPM истекает:

Копировать

  2020/02/20 17:17:12 [ошибка] 3059 # 3059: * 29 сбой recv () (104: Сброс соединения одноранговым узлом) при чтении заголовка ответа из восходящего потока, клиент: 127.0.0.1, сервер: localhost, запрос: «GET / HTTP / 1.1», восходящий поток: «fastcgi: // unix: /run/php/mypool.sock: ", host:" localhost " 

В этом случае журнал PHP-FPM (который по умолчанию находится в /var/log/php7.2-fpm.log ) показывает соответствующее сообщение, которое предоставляет дополнительную информацию:

Копия

  [20-фев-2020 17:17:12] ПРЕДУПРЕЖДЕНИЕ: [pool mypool] child 2120, script '/ var / www / html / index.php '(запрос: "GET /index.php") время ожидания выполнения истекло (25,755070 сек), завершение  

Вы можете увеличить значение времени ожидания PHP-FPM, отредактировав файл конфигурации пула, но это может вызвать другую проблему: NGINX может со временем до получения ответа от PHP-FPM. По умолчанию таймаут NGINX составляет 60 секунд; если вы увеличили тайм-аут PHP-FPM выше 60 секунд, NGINX вернет ошибку 504 Gateway Timeout, если ваше приложение PHP не ответит вовремя. Вы можете предотвратить это, также увеличив время ожидания NGINX.В приведенном ниже примере мы увеличили значение тайм-аута до 90 секунд, добавив элемент fastcgi_read_timeout в блок http файла /etc/nginx/nginx.conf :

Копировать

  http {
...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32 КБ;
    fastcgi_connect_timeout 90;
    fastcgi_send_timeout 90;
    fastcgi_read_timeout 90;
}  

Перезагрузите конфигурацию NGINX, чтобы применить это изменение:

Затем, чтобы определить, почему истекло время ожидания PHP-FPM, вы можете собрать журналы и данные мониторинга производительности приложений (APM), которые могут выявить причины задержки внутри и вне вашего приложения.

Для устранения ошибок приложений вы можете собрать журналы и отправить их в службу управления журналами. Помимо журналов NGINX, которые мы рассмотрели выше, PHP может регистрировать ошибки и другие события, которые могут быть вам полезны. См. Наше руководство по ведению журнала PHP для получения дополнительной информации.

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

Log Analytics Datadog показывает журналы из нескольких служб, сгруппированные по статусу.

APM может помочь вам определить узкие места и решить проблемы, например ошибки 502, которые влияют на производительность вашего приложения. На снимке экрана ниже показаны данные APM NGINX, визуализированные в Datadog. Это представление суммирует объем запросов, частоту ошибок и задержку для службы на основе NGINX и помогает исследовать проблемы производительности, такие как ошибка 502.

Чем быстрее вы сможете диагностировать и устранить ошибку 502 в вашем приложении, тем лучше.Datadog позволяет анализировать метрики, трассировки, журналы и данные о производительности сети по всей вашей инфраструктуре. Если вы уже являетесь клиентом Datadog, вы можете начать мониторинг NGINX, PHP-FPM и других 400 других технологий. Если у вас еще нет учетной записи Datadog, подпишитесь на 14-дневную бесплатную пробную версию и начните работу за считанные минуты.

.

[РЕШЕНИЯ] 502 Ошибка неверного шлюза на Nginx

Если вы запускаете веб-сервер Nginx, вы, возможно, уже столкнулись с досадной ошибкой 502 неверного шлюза. Это довольно распространенная ошибка, скорее всего, вызванная настройками буфера PHP или FastCGI и тайм-аутов. Из этого туториала Вы узнаете, как исправить плохой шлюз nginx 502 на веб-сервере nginx. В этом сообщении показано, как решить эту проблему, а также параметры конфигурации, чтобы предотвратить ее повторное появление при перезагрузке.

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

Метод 1. Изменения в Nginx Config

 #nano /etc/nginx/nginx.conf
 
http {
    ...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32 КБ;
    ...
} 

Метод 2. изменить PHP-FPM на прослушивание через сокет unix или TCP.

 #nano /etc/php-fpm.d/www.conf
 
слушайте = /var/run/php5-fpm.sock
 
Для того, чтобы:
 
listen = 127.0.0.1:9000 

Если вы настраиваете php-fpm для прослушивания сокета Unix, вы также должны проверить, что файл сокета имеет правильного владельца и права.

 chmod 0660 /var/run/php5-fpm.sock
chown www-data: www-data /var/run/php5-fpm.sock 

Метод 3. Отключение APC

Кэширование APC может вызвать проблемы 502 Bad Gateway в определенных средах, вызывая ошибки сегментации. Я настоятельно рекомендую использовать Memcache (d), но XCache также является хорошей альтернативой.

После обновления php-fpm мои сайты на базе PHP возвращали ошибку «502 Bad Gateway». Это может произойти, когда пакет php5-fpm перенастраивает себя для прослушивания через другой сокет.Вот как вы можете это решить.

Убедитесь, что php-fpm работает с ps aux | grep php - если вы не видите никаких процессов php-fpm на выходе, возможно, вам придется переустановить php-fpm. Если php-fpm работает нормально, пропустите этот первый шаг.

  sudo apt-get remove php5 php5-cgi php5-fpm
sudo apt-get install php5 php5-cgi php5-fpm
  

Обратите внимание на то, что порядок, в котором вы устанавливаете пакеты, важен. Раньше я обнаруживал, что их установка в неправильном порядке приводит к неправильной настройке пакетов.

Затем заставьте php-fpm прослушивать правильный хост / порт. В /etc/php5/fpm/pool.d/www.conf измените значение listen , чтобы оно соответствовало местоположению fastcgi_pass в вашей конфигурации Nginx. Например, я изменил свой с:

  listen = /var/run/php5-fpm.sock
  

Кому:

Если вы настраиваете php-fpm для прослушивания сокета Unix, вы также должны проверить, что у файла сокета есть правильный владелец и разрешения. Хотя я бы не рекомендовал это делать, вы можете просто дать всем права на чтение и запись с помощью sudo chmod go + rw / var / run / php5-fpm.носок .

Перезапустите php-fpm с помощью sudo service php5-fpm restart , и все должно снова работать нормально.

Читайте также:

[РЕШЕНИЯ] 500 ОШИБКА ВНУТРЕННЕГО СЕРВЕРА PHP

[РЕШЕНИЯ] 504 ВРЕМЯ ОТКЛЮЧЕНИЯ ШЛЮЗА NGINX

Источник:

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

.

No related posts.