Fix “502 Bad Gateway” error on NGINX server after upgrading PHP

How to fix annoying "502 Bad Gateway" errors

I check my servers for upgrades on a regular basis and when I noticed yesterday that PHP was upgraded to version 5.5.12, I backed up everything of course (backup guide) and decided to upgrade which can easily be done with sudo apt-get dist-upgrade. Unfortunately I’ve ran into quite an annoying issue which I had not encountered before, all pages returned “502 Bad Gateway” errors.

I’ve done this a numerous time and the upgrade went very smoothly. I was even asked if I wanted to keep local configuration files or not. I choose yes and the installation proceeded. After installation was completed php got restarted and I received a notice that the upgrade was successful. Unfortunately when I went to check my website I got annoying 502 Bad Gateway” errors on every single page.

badgateway

What does this error message mean? A gateway, is like an access point, a bridge that communicate one service with another, in this case the gateway can be a service/application (WordPress, running on PHP) that is working and recieving requests from NGINX web server. So there is a communication issue between PHP and NGINX.

Problem Solving 1: is PHP-FPM running?

As you can see I am also running the latest version of NGINX (1.6.0 as of May 10th 2014) which was updated a few days earlier. It was clearly an issue with PHP so I started to think of what could’ve gone wrong. The first thing that you should always do is check if PHP is even running. Perhaps something went wrong while restarting PHP. Use the following command to check whether PHP-FPM is running.

ps aux | grep php

ps aux will output all processes that are running, so we add | grep php to only output processes with php in the name. If you see PHP processes, then this is not the the issue. Otherwise try to stop/start/restart PHP.

sudo service php5-fpm stop
sudo service php5-fpm start
sudo service php5-fpm restart

If there are still no PHP-FPM processes running, you might try to remove PHP and reinstall it. If PHP-FPM is running correctly, skip this step and go to the following section.

sudo apt-get remove php5 php5-cgi php5-fpm
sudo apt-get install php5 php5-cgi php5-fpm
Problem Solving 2a: is PHP-FPM listening correctly?

A common issue is that the PHP-FPM service is not listening to the host/port which is configured in NGINX. Find the www.conf file on your server in the PHP folder. On Ubuntu this can be found here:

/etc/php5/fpm/pool.d/www.conf

Search for the listen parameter and make note of it:

; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses on a
;                            specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = 127.0.0.1:9000

As you can see this is set to 127.0.0.1:9000, but it is also commonly set to /var/run/php5-fpm.sock. In my config this was set to the latter and I found out that php5-fpm.sock was simply missing (removed during the upgrade), so I changed it to 127.0.0.1:9000.

Now find your NGINX server configuration file, usually located at /etc/nginx/sites-available, and open it. Look for something like this (location ~ \.php$):

location ~ \.php$ {
	try_files $uri =404;
	fastcgi_pass 127.0.0.1:9000;
	fastcgi_index index.php;
	include fastcgi_params;       
}

The parameter we are looking for is fastcgi_pass. This has to be the same value as in the listen parameter in the www.conf file. Change it accordingly. In my case I changed fastcgi_pass unix:/var/run/php5-fpm.sock; to fastcgi_pass 127.0.0.1:9000;.

Of course you may never forget to restart the NGINX and PHP5-FPM services! You would be surprised how many people forget this step. It is necessary to do this so that the updated configuration files are loaded.

sudo service php5-fpm restart
sudo service nginx restart
Problem Solving 2b: permanently fix the issue

While the above fix works perfectly, it is not ideal since we need to change parameters which were probably changed for a reason. It turns out that issues like this are very common due to file permissions and owner issues. That is way php-fpm.sock was missing. The bug report can be found here. Follow these steps to fix permissions and owner on Ubuntu.

So first of all, make sure that your virtual hosts NGINX files are using fastcgi_pass unix:/var/run/php5-fpm.sock; at the php configuration like this:

location ~ \.php$ {
	try_files $uri =404;
	fastcgi_pass unix:/var/run/php5-fpm.sock;
	fastcgi_index index.php;
	include fastcgi_params;       
}

Now edit the NGINX configuration file, found at /etc/nginx/nginx.conf and take note of the user (usually located on line 1). This can be www-data, nginx or something else you have set. I will call this “NGINXUSER”.

Now we will change the php-fpm configuration file, located at /etc/php5/fpm/pool.d/www.conf. Simply locate the listen parameter and change/add the appropriate values to match this (change NGINXUSER to the user you have noted down earlier):

listen = /var/run/php5-fpm.sock
listen.owner = NGINXUSER
listen.group = NGINXUSER

Restart PHP5-FPM and NGINX with the following commands and now you should be able to upgrade PHP without any issues.

sudo service php5-fpm restart
sudo service nginx restart
Problem Solving 3: Change NGINX config

Perhaps the buffer and timeout parameters are configured incorrectly for your server or they don’t suffice anymore. You can find the NGINX configuration file at /etc/nginx/nginx.conf. Try increasing the following parameters.
Increase buffer and timeouts inside http block:

http {
	...
	fastcgi_buffers 8 16k;
	fastcgi_buffer_size 32k;
	fastcgi_connect_timeout 300;
	fastcgi_send_timeout 300;
	fastcgi_read_timeout 300;
	...
}
Problem Solving 4: Disable APC

APC caching can cause 502 Bad Gateway issues under particular environments causing segmentation faults. I highly suggest using Memcache(d), but XCACHE is also a good alternative.

Conclusion

Getting unexpected are always very annoying and can really cause a lot of issues (decreased potential income, loss of visitors,…). Especially when you have no clue what could be causing the error. Hopefully this article helped you solve this issue.

22 Comments.

  1. RavanH

    After upgrading PHP5-FPM to 5.4.28 (dotdeb) on a Debian Wheezy server, I ran into this dreaded bad gateway. Thanks so much for writing these problem solving steps!

    It turns out in my case — as suggested by your step 2b — uncommenting the existing lines
    listen.owner = www-data
    listen.group = www-data
    in /etc/php5/fpm/pool.d/www.conf (and restarting the PHP service) did the trick.

    Apparently, this new PHP version uses root as default user/group instead of www-data!

  2. Mahn

    Thanks! adding (uncommenting, in fact) listen.owner and listen.group in the pool configuration solved my issues upgrading to PHP 5.5.12 and nginx 1.6.0.

    Just wanted to let you know your post helped somebody somewhere in the world :)

  3. Andre Pereira

    “Problem Solving 3” worked for me. Thank you!

  4. It worked like a charm, it’s just that my directory is different since it is assigned to an user, then I had to chmod that .sock file.

    but everything fine after that

  5. leon

    That problem had me tied up for hours, i had my sites running perfectly before i rebuilt the linode, then it was bad gateway errors, page not found etc. The users and the group where for some reason commented out in the /etc/php5/fpm/pool.d/www.conf file. Great info. Thanks

  6. Erik Svendsen

    Thank you so much! I’v been through a bunch of examples doing the same things over and over again but it was the:
    “listen.owner = NGINXUSER
    listen.group = NGINXUSER”
    section that was wrong and I didn’t see this anywhere else.

  7. Problem solved with your Problem Solving 2a.
    Thank you very much!

  8. I am running magento on nginx and i got this issue while configuring my development server. My issue was that i was having a wrong listen entry. After i set it to 127.0.0.1:9002 and then set this same value in nginx config file for fastcgi_pass, and it worked like a charm.

    Thanks for a nice article.

  9. Ucu Suryadi

    Hi!
    I have a moodle, wordpress and other cms running on campus server. The weird thing is I only get this 502 only on moodle page (/cource/view.php) the others if fine.
    Here is my error log:
    2015/01/10 12:14:38 [error] 20176#0: *21604 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx, server: mysite.ac.id, request: “GET /course/view.php?id=4 HTTP/1.1”, upstream: “fastcgi://unix:/tmp/php5-fpm.sock:”, host: “mysite.ac.id”, referrer: “http://mysite.ac.id/my/”
    I’ve tries your step mention above but still nothing.
    Thank you very much

  10. Tiny Tony

    I am having the same problem Ucu. I have been at it for hours and cannot figure out why it’s giving me an error. It only happens when I try to preview a theme I recently uploaded.

    [error] 5242#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xx.xxx.xx.xx, server: xx.xx.xx.xxx, request: “GET /wp-admin/customize.php?theme=specular HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php5-fpm.sock:”

  11. Solution 2.a worked for me.
    Thank you very much!

  12. Aysad Kozanoglu

    if you are using nginx php-fastcgi and you got “502 Bad Gateway” error
    than you have to look at your virtual host configuration on nginx config file. you have to set or correct the fastcgi_pass.
    the fastcgi_pass is the variable to set the socket connection between nginx and php cgi
    another point of issue is that the binary starter script could missed the following entries(important) open with: nano /usr/bin/php-fastcgi

    SOCKET=/var/run/php-fastcgi/php-fastcgi.socket
    PIDFILE=/var/run/php-fastcgi/php-fastcgi.pid

    the complete content of starter script /usr/bin/php-fastcgi:

    #!/bin/bash

    FASTCGI_USER=www-data
    FASTCGI_GROUP=www-data
    SOCKET=/var/run/php-fastcgi/php-fastcgi.socket
    PIDFILE=/var/run/php-fastcgi/php-fastcgi.pid
    CHILDREN=6
    PHP5=/usr/bin/php5-cgi

    /usr/bin/spawn-fcgi -s $SOCKET -P $PIDFILE -C $CHILDREN -u $FASTCGI_USER -g $FASTCGI_GROUP -f $PHP5

  13. Thank you so much! It worked absolutely perfectly. This step must have been missing from the tutorial I was following.

    Thanks! :)

  14. alice

    thanks! problem 2a fixed my stubborn 502 error as well!

  15. Innocent HARELIMANA

    Thanks a lot!

    Adding
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;

    did the trick!

    Would you please elaborate a bit about this?

    Regards,

  16. Chitta

    Trick1 solved my problem. Thank you so much.

  17. My

    Thanks for help!
    It’s work for me!

  18. Bright

    Thank you it makes my day!!!!!

  19. Gabriel Reguly

    Thanks!

  20. drjnet

    I had the same issue after moving to nginx+php-fpm. I fixed most errors by increasing the timeouts however a couple remained on large reports.

    Turned out it was this setting in my nginx virtual host conf file:
    php_admin_value[memory_limit] = 128M

    However to find this out i also had to ensure the user the web server was running as had access to write to /var/log/php-fpm. So i added the web user to the php-fpm group and then i was able to see the error logs which led me to the memory problem.

    [21-Mar-2016 09:12:32 Europe/London] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 262144 bytes) in /var/www/mydomain.com/website/public_html/protected/models/ReportDeliveryTimeAll.php on line 87

  21. This did it for me: sudo pkill php5-fpm; sudo service php5-fpm start

  22. Wow, thank you for this post! My server has been running for months without a problem, then I got irregular 502 Bad Gateway errors, the site going down for few minutes, then running up again, dozens of times a day. It was the APC caching issue. I switched to memcached and things are running smoothly now.

Leave a Comment.