这篇文章主要介绍了将PHP从5.3.28升级到5.3.29时Nginx出现502错误,需要的朋友可以参考下
今天将PHP从5.3.28升级到5.3.29，发现网站打不开了，提示”502 bad gateway”，访问静态资源可以，但访问任何PHP文件都会502。
其实之前也发现这个问题，只是一直没找到解决办法，所以我一直将PHP保持在5.3.28版本。
按照我以前的脾气，我什么软件都得要最新的稳定版，但PHP之类的软件是例外，因为版本高了，会导致很多程序不兼容，相对来说5.3兼容性算是最好的版本之一，当然5.2也可以。
强迫症实在受不了，官方说5.3.29是5.3的最后一个版本，最后一个版本出现这种问题又一直没解决让我很难受。
网上搜索了一下，没人出现我这种问题，所有的编译过程，配置过程，都是照旧，之前从5.3.25一直到5.3.28都是用的我写的同一个升级脚本，按道理同一个子版本系列，一样的编译和配置过程，不应该出现问题的。
为何5.3.25一直到5.3.28都没问题，到了5.3.29就没问题了呢?
今天终于把问题的根源找到了，我也是醉了……
由于我不想占用额外的端口，所以Nginx和PHP-FPM之间一直使用的Unix socket，而且据说这种方式效率也高一些。
PHP升级到5.3.29以后，出现502错误，而且是一打开网页就报错了，不像是由于PHP执行超时导致的Nginx提示502,更像是PHP-FPM异常终止了，或者是Ngxin根本没有连接上fastcgi。
使用PHP-FPM的日志也是郁闷，我明明开启了日志，还设置了日志路径，但还是没有生成日志。
好吧，根据前面的思路推测出来的原因找问题：
1.PHP-FPM一开始工作就异常终止了;
2.Ngxin根本没有连接上fastcgi。
第一种可能直接就排除了，因为出现502错误的时候，后台的PHP-FPM进程并没有退出，还存活得好好的。
那么很可能是第二种可能了，我把Nginx和PHP-FPM的配置文件修改了一下，改成了传统的“地址:端口”的形式
PHP-FPM配置文件中：
listen = 127.0.0.1:1234
Nginx配置文件中：
fastcgi_pass 127.0.0.1:1234
重启服务，网站竟然顺利打开了。
看来就是Nginx没有连接上PHP-FPM了，那么问题出在哪里呢?难道5.3.29去掉了Unix socket的连接方式?我觉得不大可能，查阅更新日志，也没有看到有关的项目啊。
我将Nginx和PHP-FPM的配置文件改回去。
PHP-FPM配置文件中：
listen = /tmp/php-cgi.sock
Nginx配置文件中：
fastcgi_pass unix:/tmp/php-cgi.sock;
重启服务，立马又502了。
首先想到了检查权限，反正是测试，所以我二话不说直接把那个PHP-FPM的sock文件权限改为777。
chmod 777 /tmp/php-cgi.sock
直接打开网页，能打开!
好吧，就是权限问题了，重启服务，查看php-cgi.sock 的权限
-rwx------. 1 root root 663 9月 18 00:16 php-cgi.sock
这。。。原因已经很明了了，怪不得Nginx连不上PHP-FPM，php-cgi.sock的权限竟然是700，
但问题来了，为什么同样的编译和配置过程，5.3.28之前的版本就没问题呢?我查看另一台没有升级5.3.29的服务器：
srw-rw-rw- 1 root root 0 9月 16 21:11 php-cgi.sock
发现其权限是666，这……无法理解了……为什么5.3.28的默认权限配置是666，到了5.3.29就变成700了呢?
查阅PHP文档，找到解决办法
将PHP-FPM里的配置文件加入，前两项是指定php-cgi.sock的拥有者和用户组，后一项是指定文件权限。
listen.owner = www
listen.group = www
listen.mode = 0666
重启服务，问题解决。
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
