Что значит 502 bad gateway Nginx
Начинающие веб-мастера и системные администраторы временами сталкиваются с ошибкой 502 bad gateway nginx. Nginx — это не просто один из лучших веб-серверов, в то же время, он проектировался как отличный прокси. Логически можно предположить, что эта ошибка возникает, когда что-то не так со шлюзом.
И необязательно чтобы вы использовали Nginx в качестве прокси для доступа к сети. Нет, для работы большинства сайтов требуется генерация динамического контента, например, на php. Поэтому Nginx часто выступает в прокси для Apache или php-fpm. В этой статье мы рассмотрим что означает 502 bad gateway Nginx, как исправить ее.
Что означает 502 bad gateway Nginx
Как и следует из названия, эта ошибка значит, что Nginx попытался связаться со шлюзом и у него ничего не вышло. Например, запросы от пользователей принимает Nginx, поскольку он работает быстро и потребляет мало ресурсов, а за генерацию контента отвечает php-fpm. Если сервис php-fpm во время обработки запроса получил какую-либо ошибку и не вернул результата, или же он вообще отключен и Nginx не может получить к нему доступ мы получим такую ошибку.
Вот основные причины:
- Nginx используется в качестве прокси для Apache или php-fpm, но эти сервисы не запущены;
- Nginx используется качестве прокси для php-fpm, но параметры доступа к сокету неверно настроены;
- Неверно настроены значения размера буфера и таймаута для php-fpm в nginx.conf;
- Ошибки в конфигурации Nginx.
Как исправить ошибку 502 bad gateway Nginx
1. Анализ логов и перезапуск
Чтобы исправить ошибку нужно выяснить что случилось со шлюзом. Лучший способ сделать это — посмотреть логи Nginx, там обязательно должно быть что-то написано и намного подробнее, чем в выводе браузера:
tail -f /var/log/nginx/error.log
Это уже должно дать вам некоторые подсказки что делать дальше. Еще в первую очередь не помешает проверить файл конфигурации Nginx на ошибки:
Допустим, у нас в качестве шлюза для генерации динамического содержимого используется php-fpm. Тогда нужно проверить запущен ли вообще этот сервис:
ps aux | grep php
Если все процессы уже запущены, попробуйте перезапустить их с помощью systemd:
sudo systemctl restart php-fpm
Если процесс остановлен, то его нужно запустить:
sudo systemctl start php-fpm
Это самая распространенная причина, вызывающая ошибку 502 Bad Gateway и обычно после перезапуска сервиса все будет работать, вам осталось выяснить только почему он завершился. В этом вам может помочь просмотр лога php-fpm:
sudo tail -f /var/log/php7.0-fpm.log
Но если такой рецепт не помог, и ошибка 502 bad gateway nginx нужно идти дальше. Внимательно пересмотрите лог, возможно, там уже есть ответ.
2. Доступность php-fpm и владелец
Также эта ошибка может возникать при проблемах доступа к файлу сокета php-fpm, например, когда этот файл называется по другому или для него выставлены неверные права. Сначала убедитесь, что в конфигурационном файле /etc/nginx/nginx.conf указан правильный адрес файла сокета php-fpm:
Файл /var/run/php7.0-fpm.sock должен действительно существовать в файловой системе. Дальше нужно убедиться, что у сокета правильный владелец, это должен быть тот же пользователь, от имени которого запускается Nginx, группа тоже должна соответствовать. Откройте файл /etc/php7.0/fpm/pool.d/www.conf и найдите строчки user и group. Они должны иметь такое же значение, как строчка user в конфиге nginx.conf:
listen = /var/run/php7.0-fpm.sock listen.owner = www-data listen.group = www-data
После того как выставите правильные параметры, перезапустите сервисы:
sudo service php5-fpm restart $ sudo service nginx restart
3. Время отклика и размер буфера
Возможно, размер буфера и время ожидания ответа от fastcgi настроены неверно и программа просто не успевает обработать большой запрос. Попробуйте увеличить такие параметры в /etc/nginx/nginx.conf. Если таких строк не существует, добавьте их в блок http, как здесь:
sudo vi /etc/nginx/nginx.conf
Выводы
В этой статье мы рассмотрели 502 bad gateway nginx что это значит и как исправить эту ошибку. Как видите, может быть достаточно много причин ее возникновения, но решить все достаточно просто если внимательно посмотреть логи и понять в чем там действительно проблема. Надеюсь, информация была полезной для вас.
A common PHP upstream configuration generating problems
With that kind of configuration the domain name resolution for “php” is done only once when Nginx is started or reloaded. So any problem with php-fpm going down for instance, will need a restart or reload for Nginx. It’s not a very resilient configuration.
Let’s say we are running PHP-FPM in a docker container and our container is restarted by the orchestrator, or we deploy a new version of our stack not including any Nginx changes we will need to restart or reload Nginx too or we will have a lot of 502 Bad Gateway errors. To avoid this we need to use dynamic domain name resolution .
Dynamic domain name resolution configuration for Nginx
Resources
No more upstream configuration needed .
And the application configuration file becomes:
/etc/nginx/sites-enabled/app.conf
- 127.0.0.11 is the internal docker DNS address name.
- valid=10s because we want to re‑resolve names every 10 seconds.
- ipv6=off because we do not want to use IPv6.
- fastcgi_pass $backendfpm; would be the same for proxy_pass.
When you use a variable to specify the domain name in the proxy_pass directive, NGINX re‑resolves the domain name when its TTL expires. You must include the resolver directive to explicitly specify the name server (NGINX does not refer to /etc/resolv.conf as in the first two methods). By including the valid parameter to the resolver directive, you can tell NGINX to ignore the TTL and re‑resolve names at a specified frequency instead. Here we tell NGINX to re‑resolve names every 10 seconds.
This method eliminates two drawbacks of the first method, in that the NGINX startup or reload operation doesn’t fail when the domain name can’t be resolved, and we can control how often NGINX re‑resolves the name.
Docker Swarm and Kubernetes
It’s a common problem with docker Swarm and Kubernetes as everything is containerized and a lot of networking stuffs comes into game.
Как исправить ошибку 502 Bad Gateway на Nginx
В этом руководстве мы покажем вам, как исправить 502 ошибки неверного шлюза на веб-сервере Nginx. Если вы запускаете веб-сервер Nginx, вы, возможно, уже столкнулись с досадной ошибкой 502 плохого шлюза. Это довольно распространенная ошибка, скорее всего, вызванная настройками буфера PHP или FastCGI и тайм-аутов. Из этого туториала Вы узнаете, как исправить плохой шлюз Nginx 502 на веб-сервере Nginx. В этом сообщении показано, как решить эту проблему, а также параметры конфигурации, чтобы предотвратить ее повторное появление при перезагрузке.
В этой статье предполагается, что у вас есть хотя бы базовые знания Linux, вы знаете, как использовать оболочку, и, что наиболее важно, вы размещаете свой сайт на собственном VPS. Установка довольно проста и предполагает, что вы работаете с учетной записью root, в противном случае вам может потребоваться добавить ‘ sudo ‘ к командам для получения привилегий root. Я покажу вам пошаговое решение ошибки 502 неверного шлюза на веб-сервере Nginx.
Исправить ошибку 502 Bad Gateway на Nginx
Шаг 1. Сначала проверьте журнал данных веб-сервера Nginx.
Просто веселое видео для отвлечения и расслабления в течение 2 минут
Вы можете более подробно увидеть, что конкретно влечет за собой ошибка, перейдя в файл журнала ошибок вашего веб-сервера. Вся информация об ошибках и диагностическая информация хранится в этом файле, что делает его ценным ресурсом для проверки, когда вам нужны дополнительные сведения о конкретной ошибке. Вы можете найти этот файл в Nginx, перейдя в . /var/ log / nginx / error . log
Шаг 2. Решите 502 проблемы со шлюзом.
- Метод 1. Изменения в Nginx Config.
Выполните следующую команду, чтобы отредактировать Nginx conf:
После этого перезапустите службу Nginx, чтобы вступили в силу:
- Метод 2. Измените PHP-FPM для прослушивания сокета Unix или сокета TCP.
После этого перезапустите PHP-FPM, чтобы изменить эффект:
Если вы настраиваете php-fpm для прослушивания сокета Unix, вы также должны проверить, что у файла сокета есть правильный владелец и разрешения.
- Метод 3. Отключить APC.
Кэширование APC может вызвать проблемы 502 Bad Gateway в определенных средах, вызывая ошибки сегментации. Я настоятельно рекомендую использовать Memcache (d), но XCache также является хорошей альтернативой.
Поздравляю! Вы успешно решили 502 проблемы со шлюзом. Благодарим за использование этого руководства для исправления 502 проблем со шлюзом в системе Linux. Для получения дополнительной помощи или полезной информации мы рекомендуем вам посетить официальный сайт Nginx .
nginx 502 bad gateway
I get a 502 Bad Gateway with nginx when using spawn fcgi to spawn php5-cgi.
I use this to span an instance on server start using the following line in rc.local
presumably I’m getting the error because the spawn-fcgi / php5-cgi dies and there is nothing listening there anymore to parse php.
I get nothing in the logs that I can see anywhere, I’m out of ideas (and new to this setup with nginx)
14 Answers 14
I executed my localhost and the page displayed the 502 bad gateway message. This helped me:
- Edit /etc/php5/fpm/pool.d/www.conf
- Change listen = /var/run/php5-fpm.sock to listen = 127.0.0.1:9000
- Ensure the location is set properly in nginx.conf.
- Run sudo service php5-fpm restart
Maybe it will help you.
The 502 error appears because nginx cannot hand off to php5-cgi. You can try reconfiguring php5-cgi to use unix sockets as opposed to tcp .. then adjust the server config to point to the socket instead of the tcp .
Go to /etc/php5/fpm/pool.d/www.conf and if you are using sockets or this line is uncommented
Set couple of other values too:-
Don’t forget to restart php-fpm and nginx. Make sure you are using the same nginx owner and group name.
You have to match the settings for PHP-FPM and Nginx to communicate over sockets or TCP.
So go to /etc/php5/fpm/pool.d/www.conf and look for this line:
Then go to /etc/nginx/nginx.conf
Match those values and you should be all set.
If running a linux server, make sure that your IPTABLES configuration is correct.
Execute sudo iptables -L -n , you will recieve a listing of your open ports. If there is not an Iptables Rule to open the port serving the fcgi script you will receive a 502 error. The Iptables Rule which opens the correct port must be listed before any rule which categorically rejects all packets (i.e. a rule of the form «REJECT ALL — 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable or similar)
On my configuration, to properly open the port, I had to execute this command (assume my fcgi server is running at port 4567):
WARNING: This will open port 4567 to the whole world.
So it might be better to do something like this:
Doing this removed the 502 error for me.
When I did sudo /etc/init.d/php-fpm start I got the following error:
I guess /etc/php-fpm.d/www.conf needs to know the user that the webserver is running as and assumes it’s apache when, for nginx, it’s actually nginx, and needs to be changed.
You can make nginx ignore client aborts using:
I had the same problem while setting up an Ubuntu server. Turns out I was having the problem due to incorrect permissions on socket file.
If you are having the problem due to a permission problem, you can uncomment the following lines from: /etc/php5/fpm/pool.d/www.conf
Alternatively, although I wouldn’t recommend, you can give read and write permissions to all groups by using the following command.
Try disabling the xcache or apc modules. Seems to cause a problem with some versions are saving objects to a session variable.
Hope this tip will save someone else’s life. In my case the problem was that I ran out of memory, but only slightly, was hard to think about it. Wasted 3hrs on that. I recommend running:
. along with running problematic requests on the server to see if your memory doesn’t run out. And if it does like in my case, you need to create a swap file (unless you already have one).
I have followed this tutorial to create swap file on Ubuntu Server 14.04 and it worked just fine: http://www.cyberciti.biz/faq/ubuntu-linux-create-add-swap-file/
If you’re on Ubuntu, and all of the above has failed you, AppArmor is most likely to blame.
Long story short:
See everything working nicely. then
I still had problems with Nginx not being able to read error.log, even though it had all the permissions possible, including in Apparomor. I’m guessing it’s got something to do with the order of the entries, or some interaction with Passenger or PHP-Fpm. I’ve run out of time to troubleshoot this and have gone back to Apache for now. (Apache performs much better too FYI.)
AppArmor just lets Nginx do whatever it wants if you just remove the profile:
Shockingly, but hardly surprising, a lot of posts on fixing Nginx errors resorts to completely disabling SELinux or removing AppArmor. That’s a bad idea because you lose protection from a whole lot of software. Just removing the Nginx profile is a better way to troubleshoot your config files. Once you know that the problem isn’t in your Nginx config files, you can take the time to create a proper AppArmor profile.
Without an AppArmor profile, especially if you run something like Passenger too, I give your server about a month to get backdoored.