502 Bad Gateway错误非常常见&＃xff0c;此错误代码的确切原因取决于您的特定堆栈。
由于前端Web服务器和后端应用程序处理程序之间的通信中断&＃xff0c;通常会出现错误的网关错误。大多数情况下&＃xff0c;潜在原因可归因于过度延迟或极短的超时窗口。
在其他情况下&＃xff0c;错误的网关错误表明配置错误的Web应用程序处理程序 - Web服务器理解请求并将其传递给适当的处理程序&＃xff0c;但在切换期间出现了问题。
诊断502错误网关错误的原因主要取决于您正在使用的应用程序服务器&＃xff0c;我们在下面列出了PHP-FPM的解决方案。
PHP-FPM未运行
检查PHP-FPM状态的最快方法是使用ps和grep。如果您的输出类似于下面的文字&＃xff0c;你可以肯定PHP-FPM正在运行
root&＃64;nginx0:/var/log/nginx# ps aux | grep php
root 29191 0.0 1.7 133628 18108 ? Ss 20:41 0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
www-data 29193 0.0 0.5 133628 5956 ? S 20:41 0:00 php-fpm: pool www
www-data 29194 0.0 0.5 133628 5956 ? S 20:41 0:00 php-fpm: pool www
如果没有&＃xff0c;请尝试启动PHP-FPM
PHP-FPM无法启动
如果PHP-FPM无法成功启动&＃xff0c;请在Web服务器上请求PHP页面以导致记录错误。然后&＃xff0c;尾部NGINX的错误日志&＃xff1a;
www-data&＃64;nginx0:/var/log/nginx$ tail /var/log/nginx/error.log
2016/09/19 20:39:30 [crit] 28751#28751: *9 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.0.2.101, server: example.com, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.0.2.255"
2016/09/19 20:39:50 [crit] 28751#28751: *9 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.0.2.101, server: example.com, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.0.2.255"
2016/09/20 16:39:44 [crit] 28751#28751: *33 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.0.2.101, server: example.com, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.0.2.255"
上述错误指向请求处理套接字的问题。NGINX正在寻找一个位于/var/run/php5-fpm.sock但无法找到它的UNIX套接字; 将这些错误与syslog中发现的错误&＃xff08;PHP-FPM的默认日志位置&＃xff09;相关联&＃xff0c;很明显PHP-FPM无法启动&＃xff0c;这几乎肯定是一个配置问题。
www-data&＃64;nginx0:/var/log/nginx$ tail /var/log/syslog
Sep 20 16:39:10 nginx0 kernel: [77167.468712] init: php5-fpm main process (3551) terminated with status 78
Sep 20 16:39:11 nginx0 kernel: [77167.468727] init: php5-fpm main process ended, respawning
请注意terminated with status 78。要确定错误代码78代表什么&＃xff0c;我们可以在以下方面grep该错误代码/usr/include/sysexits.h&＃xff1a;
www-data&＃64;nginx0:/var/log/nginx$ cat /usr/include/sysexits.h | grep 78
#define EX_CONFIG 78 /* configuration error */
我们的怀疑得到了证实;错误实际上是由于PHP-FPM的配置错误。
解决PHP-FPM配置问题
配置问题可能是手指发胖或真正的配置冲突造成的。
要解决由配置错误导致的错误&＃xff0c;请首先确保运行php-fpm的用户可以写入套接字目录。接下来&＃xff0c;验证是否使用适当的用户权限创建了套接字。
特别是&＃xff0c;检查您的工作池配置&＃xff08;in /etc/php5/fpm/pool.d/*.conf&＃xff09;并验证&＃xff1a;
- 套接字路径
- 流程所有者/组
- listen.owner / listen.group
user &＃61; www-data
group &＃61; www-datlisten &＃61; /var/run/php5-fpm.socklisten.owner &＃61; www-data
listen.group &＃61; www-data
注意上面配置文件中的拼写错误&＃xff1a;group &＃61; www-dat应该读取group &＃61; www-data。修复此错误并重新启动PHP-FPM守护程序可以解决此问题
NGINX无法与PHP-FPM通信
如果PHP-FPM和您的应用程序都正常工作&＃xff0c;则问题可能在于NGINX的配置。在启用站点的目录中&＃xff0c;打开导致问题的站点配置&＃xff08;/etc/nginx/sites-enabled/default默认情况下&＃xff09;&＃xff0c;并验证该fastcgi_pass指令是否与listenPHP-FPM工作池配置中的socket&＃xff08;&＃xff09;匹配。
[...]location ~ .php$ {try_files $uri &＃61;404;fastcgi_pass unix:/var/run/php5-fpm.sock;fastcgi_index index.php;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_nam$include fastcgi_params;}
如果您进行了任何更改&＃xff0c;请确保重新启动NGINX。
NGINX正在超时
如果后端应用程序服务器已启动并正在运行&＃xff0c;则问题的原因可能在于所服务的应用程序。具体而言&＃xff0c;未及时响应NGINX的应用程序将导致502&＃xff0c;因为NGINX不能再等待响应。
根据应用程序应该执行的操作&＃xff0c;可能需要较长的执行时间&＃xff08;> 30秒&＃xff09;。在这种情况下&＃xff0c;如下所述增加最大执行时间和NGINX超时窗口将是最佳解决方案。
但是&＃xff0c;如果应用程序和数据集的上下文中的执行周期很长&＃xff0c;那么您可以从分析和优化相关应用程序中受益。
此修复需要进行两项更改&＃xff1a;首先&＃xff0c;打开PHP-FPM的配置文件&＃xff08;/etc/php5/fpm/php.ini&＃xff09;&＃xff0c;然后找到以下行&＃xff1a;max_execution_time &＃61; 30
增加max_execution_time你的预期应用程序执行时间&＃xff08;以秒为单位&＃xff09;。为了以防万一&＃xff0c;添加额外时间的缓冲区可能是谨慎的。
接下来&＃xff0c;在您的NGINX config&＃xff08;/etc/nginx/nginx.conf&＃xff09;中&＃xff0c;在http块中添加以下内容以增加超时窗口&＃xff0c;缓冲区和缓冲区大小&＃xff1a;
http {
...fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
}
最后&＃xff0c;一旦进行了更改并保存&＃xff0c;请重新加载NGINX和PHP-FPM&＃xff1a;
PHP-FPM正在超时
在某些情况下&＃xff0c;增加PHP-FPM的超时窗口可能只能为更深层次的底层问题提供临时解决方案。根据应用程序的性质&＃xff0c;您可以对其进行概要分析和优化&＃xff0c;以缩短执行时间&＃xff0c;完全避免超时问题。例如&＃xff0c;您的应用程序可能会在数据库查询上花费过多的时间阻塞&＃xff0c;这取决于您的平台&＃xff0c;可能会计入最大分配的执行时间。从PHP文档&＃xff1a;“在确定脚本运行的最长时间时&＃xff0c;不包括在执行脚本之外发生的任何活动&＃xff0c;例如使用system&＃xff08;&＃xff09;的系统调用&＃xff0c;流操作&＃xff0c;数据库查询等。 。在测量时间真实的Windows上&＃xff0c;情况并非如此。“
如果您的NGINX超时足够高&＃xff0c;您可以通过set_time_limit()从应用程序中调用该函数来暂时延长PHP的执行时间限制&＃xff0c;但如果您不断进入执行上限&＃xff0c;则可以使用长期解决方案&＃xff08;如分析或增加PHP-FPM的超时&＃xff09;更合适。
200 OK
问题是在您的应用程序中&＃xff0c;PHP-FPM还是NGINX对您的最终用户无关紧要。因此&＃xff0c;在您解决了当前问题的同时&＃xff0c;监控基础架构和应用程序的性能和运行状况仍是一个持续关注的问题。
使用Datadog&＃xff0c;您可以从整个基础架构中收集&＃xff0c;可视化&＃xff0c;警报和处理性能和运行状况指标。通过全粒度保留15个月&＃xff0c;您可以将过去的性能与最近的趋势进行比较&＃xff0c;预测流量和负载&＃xff0c;并在事情偏离预期时发出警报。
京公网安备 11010802041100号