服务器出现 nginx 502 Bad Gateway
生活随笔
收集整理的這篇文章主要介紹了
服务器出现 nginx 502 Bad Gateway
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
發(fā)生原因
1、PHP FastCGI進程數(shù)不夠用
當(dāng)網(wǎng)站并發(fā)訪問巨大時,php fastcgi的進程數(shù)不有一定的保障,因為cgi是單線程多進程工作的,也就是說cgi需要處理完一個頁面后再繼續(xù)下一個頁面。如果進程數(shù)不夠,當(dāng)訪問巨大的時候,cgi按排隊處理之前的請求,之后的請求只有被放棄。這個時候nginx就會不時的出現(xiàn)502錯誤。
2、PHP FastCGI的內(nèi)存不夠用
當(dāng)nginx返回靜態(tài)頁面時,這個問題一般不會出現(xiàn),因為nginx不需要php cgi的處理而直接返回靜態(tài)頁面。但是當(dāng)網(wǎng)頁需要處理大量的php復(fù)雜操作的時候,例如執(zhí)行api采集,或者采集頁面的時候,那對php的要求是相當(dāng)高的,如果配置給他的內(nèi)存太少,那很容易就會導(dǎo)致php崩潰。
1、首先判斷是不是php fastcgi進程數(shù)是否夠用。
netstat -anpo | grep "php-cgi" | wc -l
如果實際使用的“FastCGI進程數(shù)”接近預(yù)設(shè)的“FastCGI進程數(shù)”,那么,說明“FastCGI進程數(shù)”不夠用,需要增大。 但是要注意計算你的內(nèi)存是否足夠支撐更多的進程數(shù),如果物理機內(nèi)存并不足夠大,加大這個進程數(shù)是沒有用處的。
2、部分PHP程序的執(zhí)行時間超過了Nginx的等待時間,可以適當(dāng)增加nginx.conf配置文件中FastCGI的timeout時間,如下:
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......
php.ini中memory_limit設(shè)低了會出錯,修改了php.ini的memory_limit為64M,重啟nginx,發(fā)現(xiàn)好了,原來是PHP的內(nèi)存不足了。
如果以上方法依然不能解決問題,請嘗試優(yōu)化你的php程序,盡量的減少采集和數(shù)據(jù)庫操作,加快其反應(yīng)速度,有時候往往是因為自己的php程序反應(yīng)速度太慢造成的。
3:目前l(fā)nmp一鍵安裝包比較多的問題就是502 Bad Gateway,大部分情況下原因是在安裝php前,腳本中某些lib包可能沒有安裝上,造成php沒有編譯安裝成功。
解決方法:
可以嘗試根據(jù)lnmp一鍵安裝包中的腳本手動安裝一下,看看是什么錯誤導(dǎo)致的,在網(wǎng)上搜索一下,或者把錯誤信息發(fā)上來。我們給你分析一下錯誤原因。
4:
在php.ini里,eaccelerator配置項一定要放在Zend Optimizer配置之前,否則也可能引起502 Bad Gateway
第三種原因:
在安裝好使用過程中出現(xiàn)502問題,一般是因為默認php-cgi進程是5個,可能因為phpcgi進程不夠用而造成502,需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當(dāng)增加。(一般1個php-cgi占有20M內(nèi)存,請依照內(nèi)存來設(shè)定該值)
也有可能是max_requests值不夠用。
5:
php執(zhí)行超時,修改/usr/local/php/etc/php.ini 將max_execution_time 改為300
第五種原因:
磁盤空間不足,如mysql日志占用大量空間
6:
查看php-cgi進程是否在運行
可以通過# top 命令查看。
nginx反向代理解決辦法有點不同
將nginx的error log打開,發(fā)現(xiàn)”pstream sent too big header while reading response header from upstream”這樣的錯誤提示,查閱了一下資料,大意是nginx緩沖區(qū)有一個bug造成的,我們網(wǎng)站的頁面消耗占用緩沖區(qū)可能過大
apache返回的header 太大nginx處理不過來就導(dǎo)致了。
代碼如下 復(fù)制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
#charset koi8-r;
# access_log off;
location / {
#添加這3行 ,
proxy_buffer_size 64k;
proxy_buffers 32 32k;
proxy_busy_buffers_size 128k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
set $baiduspider '';
if ( $http_user_agent ~ Baiduspider) {
set $baiduspider Baidu;
}
............
如果是 nginx+PHPcgi 就該
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on
011/01/07 11:12:57 [error] 10770#0: *38585340 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.22.131.154, server: *.xywy.com, request: "GET /ysmp/index.php?did=124994 HTTP/1.0", upstream: "http://127.0.0.1:8080/ysmp/index.php?did=124994", host: "xywy.yn16.com"
后來原來那錯誤沒了出了新錯誤了
upstream timed out 超時?
代碼如下 復(fù)制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
client_max_body_size 300m;
client_body_buffer_size 128k;
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
#charset koi8-r;
# access_log off;
request_terminate_timeout
如果主要是在一些post或者數(shù)據(jù)庫操作的時候出現(xiàn)502這種情況,而不是在靜態(tài)頁面操作中常見,那么可以查看一下php-fpm.conf設(shè)置中的一項:
request_terminate_timeout
這個值是max_execution_time,就是fast-cgi的執(zhí)行腳本時間。
0s
0s為關(guān)閉,就是無限執(zhí)行下去。(當(dāng)時裝的時候沒仔細看就改了一個數(shù)字)問題解決了,執(zhí)行很長時間也不會出錯了。優(yōu)化fastcgi中,還可以改改這個值5s 看看效果。
1、PHP FastCGI進程數(shù)不夠用
當(dāng)網(wǎng)站并發(fā)訪問巨大時,php fastcgi的進程數(shù)不有一定的保障,因為cgi是單線程多進程工作的,也就是說cgi需要處理完一個頁面后再繼續(xù)下一個頁面。如果進程數(shù)不夠,當(dāng)訪問巨大的時候,cgi按排隊處理之前的請求,之后的請求只有被放棄。這個時候nginx就會不時的出現(xiàn)502錯誤。
2、PHP FastCGI的內(nèi)存不夠用
當(dāng)nginx返回靜態(tài)頁面時,這個問題一般不會出現(xiàn),因為nginx不需要php cgi的處理而直接返回靜態(tài)頁面。但是當(dāng)網(wǎng)頁需要處理大量的php復(fù)雜操作的時候,例如執(zhí)行api采集,或者采集頁面的時候,那對php的要求是相當(dāng)高的,如果配置給他的內(nèi)存太少,那很容易就會導(dǎo)致php崩潰。
1、首先判斷是不是php fastcgi進程數(shù)是否夠用。
netstat -anpo | grep "php-cgi" | wc -l
如果實際使用的“FastCGI進程數(shù)”接近預(yù)設(shè)的“FastCGI進程數(shù)”,那么,說明“FastCGI進程數(shù)”不夠用,需要增大。 但是要注意計算你的內(nèi)存是否足夠支撐更多的進程數(shù),如果物理機內(nèi)存并不足夠大,加大這個進程數(shù)是沒有用處的。
2、部分PHP程序的執(zhí)行時間超過了Nginx的等待時間,可以適當(dāng)增加nginx.conf配置文件中FastCGI的timeout時間,如下:
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......
php.ini中memory_limit設(shè)低了會出錯,修改了php.ini的memory_limit為64M,重啟nginx,發(fā)現(xiàn)好了,原來是PHP的內(nèi)存不足了。
如果以上方法依然不能解決問題,請嘗試優(yōu)化你的php程序,盡量的減少采集和數(shù)據(jù)庫操作,加快其反應(yīng)速度,有時候往往是因為自己的php程序反應(yīng)速度太慢造成的。
3:目前l(fā)nmp一鍵安裝包比較多的問題就是502 Bad Gateway,大部分情況下原因是在安裝php前,腳本中某些lib包可能沒有安裝上,造成php沒有編譯安裝成功。
解決方法:
可以嘗試根據(jù)lnmp一鍵安裝包中的腳本手動安裝一下,看看是什么錯誤導(dǎo)致的,在網(wǎng)上搜索一下,或者把錯誤信息發(fā)上來。我們給你分析一下錯誤原因。
4:
在php.ini里,eaccelerator配置項一定要放在Zend Optimizer配置之前,否則也可能引起502 Bad Gateway
第三種原因:
在安裝好使用過程中出現(xiàn)502問題,一般是因為默認php-cgi進程是5個,可能因為phpcgi進程不夠用而造成502,需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當(dāng)增加。(一般1個php-cgi占有20M內(nèi)存,請依照內(nèi)存來設(shè)定該值)
也有可能是max_requests值不夠用。
5:
php執(zhí)行超時,修改/usr/local/php/etc/php.ini 將max_execution_time 改為300
第五種原因:
磁盤空間不足,如mysql日志占用大量空間
6:
查看php-cgi進程是否在運行
可以通過# top 命令查看。
nginx反向代理解決辦法有點不同
將nginx的error log打開,發(fā)現(xiàn)”pstream sent too big header while reading response header from upstream”這樣的錯誤提示,查閱了一下資料,大意是nginx緩沖區(qū)有一個bug造成的,我們網(wǎng)站的頁面消耗占用緩沖區(qū)可能過大
apache返回的header 太大nginx處理不過來就導(dǎo)致了。
代碼如下 復(fù)制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
#charset koi8-r;
# access_log off;
location / {
#添加這3行 ,
proxy_buffer_size 64k;
proxy_buffers 32 32k;
proxy_busy_buffers_size 128k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
set $baiduspider '';
if ( $http_user_agent ~ Baiduspider) {
set $baiduspider Baidu;
}
............
如果是 nginx+PHPcgi 就該
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on
011/01/07 11:12:57 [error] 10770#0: *38585340 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.22.131.154, server: *.xywy.com, request: "GET /ysmp/index.php?did=124994 HTTP/1.0", upstream: "http://127.0.0.1:8080/ysmp/index.php?did=124994", host: "xywy.yn16.com"
后來原來那錯誤沒了出了新錯誤了
upstream timed out 超時?
代碼如下 復(fù)制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
client_max_body_size 300m;
client_body_buffer_size 128k;
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
#charset koi8-r;
# access_log off;
request_terminate_timeout
如果主要是在一些post或者數(shù)據(jù)庫操作的時候出現(xiàn)502這種情況,而不是在靜態(tài)頁面操作中常見,那么可以查看一下php-fpm.conf設(shè)置中的一項:
request_terminate_timeout
這個值是max_execution_time,就是fast-cgi的執(zhí)行腳本時間。
0s
0s為關(guān)閉,就是無限執(zhí)行下去。(當(dāng)時裝的時候沒仔細看就改了一個數(shù)字)問題解決了,執(zhí)行很長時間也不會出錯了。優(yōu)化fastcgi中,還可以改改這個值5s 看看效果。
轉(zhuǎn)載于:https://www.cnblogs.com/matengfei123/p/8656158.html
總結(jié)
以上是生活随笔為你收集整理的服务器出现 nginx 502 Bad Gateway的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: L1-046. 整除光棍(模拟除法)
- 下一篇: [kuangbin] M - Find