Very confusing. Why not edit your answer to be correct, (Go to /etc...) and then afterwards comment about how there is a less secure way that only works till reboot (Go to /var/..).
– SamGoodyJun 24 '14 at 11:39

I found that I had to change listen.mode to 0660 in /etc/php5/fpm/pool.d/www.conf.

Sample from www.conf:

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions.
; Default Values: user and group are set as the running user
; mode is set to 0660
;listen.owner = www-data
;listen.group = www-data
;listen.mode = 0660

Edit: Per @Chris Burgess, I've changed this to the more secure method.

If listen.acl_groups is set, listen.owner and listen.group are ignored. I set listen.acl_groups =, then the 502/permissions problem went away. Found it after uncommenting the listen. lines as above, the 502 problem persisted and systemctl status php-fpm showed the warning WARNING: [pool www] ACL set, listen.owner = 'nobody' is ignored.
– a.outAug 30 '18 at 14:12

For what it's worth, on my Ubuntu 12.04 system, the user and group are www-data.
– BradJul 27 '14 at 21:44

For me in CentOS, it worked to set the user as "nobody" and the group as "nginx". Probably not a major improvement, but I'd prefer to give as limited of permissions as possible.
– KzqaiOct 21 '16 at 1:28

Consideration must also be given to your individual FPM pools, if any.

I couldn't figure out why none of these answers was working for me today. This had been a set-and-forget scenario for me, where I had forgotten that listen.user and listen.group were duplicated on a per-pool basis.

If you used pools for different user accounts like I did, where each user account owns their FPM processes and sockets, setting only the default listen.owner and listen.group configuration options to 'nginx' will simply not work. And obviously, letting 'nginx' own them all is not acceptable either.

I just got this error again today as I updated my machine (with updates for PHP) running Ubuntu 14.04. The distribution config file /etc/php5/fpm/pool.d/www.conf is fine and doesn't require any changes currently.

The strange thing was that I have 2 sites running that utilize PHP-FPM on this machine one was running fine and the other (a Tiny Tiny RSS installation) gave me a 502, where both have been running fine before.

I compared both configuration files and found that fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; was missing for the affected site.

Both configuration files now contain the following block and are running fine again:

Update

It should be noted that Ubuntu ships two fastcgi related parameter files and also a configuration snippet which is available since Vivid and also in the PPA version. The solution was updated accordingly.

After upgrading from Ubuntu 14.04 lts to Ubuntu 16.04 lts I found a yet another reason for this error that I haven't seen before.

During the upgrading process I had somehow lost my php5-fpm executable altogether. All the config files were intact and it took me a while to realize that service php5-fpm start didn't really start a process, as it did not show any errors.

My moment of awakening was when I noticed that there were no socket file in /var/run/php5-fpm.sock, as there should be, nor did netstat -an show processes listening on the port that I tried as an alternative while trying to solve this problem. Since the file /usr/sbin/php5-fpm was also non-existing, I was finally on the right track.

In order to solve this problem I upgraded php from version 5.5 to 7.0.apt-get install php-fpm did the trick as a side effect. After that and installing other necessary packages everything was back to normal.

This upgrading solution may have problems of its own, however. Since php has evolved quite a bit, it's possible that the software will break in unimaginable ways. So, even though I did go down that path, you may want to keep the version you're fond of just for a while longer.

You should never opt to reduce the security of a system to get something working, rather use one of the many options in the other answers to solve your issue. Do not disable selinux without extremely good reason to do so!
– SlyDaveMay 31 '18 at 15:06