快捷導(dǎo)航

PHP 502bad gateway原因及解決方案

更新時間：2020年11月13日 11:16:00 作者：Leone-

這篇文章主要介紹了PHP 502bad gateway原因及解決方案,文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下

nginx+php 出現(xiàn)502 bad gateway，一般這都不是nginx的問題，而是由于 fastcgi或者php的問題導(dǎo)致的，常見的有以下幾種。

1. php.ini 的memory_limit 過?。ㄈ绻袀€別php程序進(jìn)程需要占用極大內(nèi)存時這個必須注意）

2. php-fpm.conf 中max_children或者max_requests 設(shè)置不合理（設(shè)置過小會因為沒有足夠的cgi進(jìn)程處理請求，設(shè)置過大會出現(xiàn)一會兒有響應(yīng)正常，一會兒等很久才有響應(yīng)的情況，一般情況下children 按照內(nèi)存計算，比如說1G設(shè)置64，2G128。這個根據(jù)實際情況自行調(diào)整。另外查看當(dāng)前的PHP FastCGI進(jìn)程數(shù)是否夠用的命令為：netstat -anpo |grep “php-cgi” | wc -l 如果實際使用的“FastCGI進(jìn)程數(shù)”接近預(yù)設(shè)的“FastCGI進(jìn)程數(shù)”，那么，說明“FastCGI進(jìn)程數(shù)”不夠用，需要增大。）

3. 查看nginx錯誤日志，發(fā)現(xiàn) pstream sent too big header while reading response headerfrom upstream ，則檢查client head buffer，fastcgi buffer size是否過小，可設(shè)置為32K。

4. php 程序執(zhí)行時間過長而超時，檢查nginx和fastcgi中各種timeout設(shè)置。（nginx 中的 fastcgi_connect_timeout 300;fastcgi_send_timeout 300 ：fastcgi_read_timeout300; keepalive_timeout ； php-fpm中的request_terminate_timeout，php.ini中的max_execution_time）

5. php-fpm 有一個參數(shù) max_requests ，該參數(shù)指明了每個children最多處理多少個請求后便會被關(guān)閉。在大量處理請求下，如果該值設(shè)置過小會導(dǎo)致 children頻繁的自殺和建立而浪費大量時間，若所有的children差不多都在這個時候自殺，則重建前將沒有children響應(yīng)請求，于是出現(xiàn)502 ?？梢詫⒃撝翟O(shè)置大一些或者是0[無限]。

以上差不多是比較常見的502的問題原因以及解決辦法，其實解決問題的最好的方式還是自己去看nginx和fastcgi的errorlog。

最后借用網(wǎng)上的萬金油說法做個總結(jié)： php-cgi進(jìn)程數(shù)不夠用、php執(zhí)行時間長、或者是php-cgi進(jìn)程死掉，都會出現(xiàn)502錯誤。

502 錯誤是所有用 nginx 跑 php 的運維人員不愿意看見的

nginx 出現(xiàn) 502 有很多原因，但大部分原因可以歸結(jié)為資源數(shù)量不夠用 , 也就是說后端 php-fpm 處理有問題， nginx 將正確的客戶端請求發(fā)給了后端的 php-fpm 進(jìn)程，但是因為 php-fpm 進(jìn)程的問題導(dǎo)致不能正確解析 php 代碼，最終返回給了客戶端 502 錯誤。

服務(wù)器出現(xiàn) 502 的原因是連接超時我們向服務(wù)器發(fā)送請求由于服務(wù)器當(dāng)前鏈接太多，導(dǎo)致服務(wù)器方面無法給于正常的響應(yīng) , 產(chǎn)生此類報錯

因此如果你服務(wù)器并發(fā)量非常大，那只能先增加機(jī)器，然后按以下方式優(yōu)化會取得更好效果 ; 但如果你并發(fā)不大卻出現(xiàn) 502 ，一般都可以歸結(jié)為配置問題，腳本超時問題。

1.php-fpm 進(jìn)程數(shù)不夠用

使用 netstat -napo |grep "php-fpm" | wc -l 查看一下當(dāng)前 fastcgi 進(jìn)程個數(shù)，如果個數(shù)接近 conf 里配置的上限，就需要調(diào)高進(jìn)程數(shù)。

但也不能無休止調(diào)高，可以根據(jù)服務(wù)器內(nèi)存情況，可以把 php-fpm 子進(jìn)程數(shù)調(diào)到 100 或以上，在 4G 內(nèi)存的服務(wù)器上 200 就可以。

2. 調(diào)高調(diào)高 linux 內(nèi)核打開文件數(shù)量

可以使用這些命令 ( 必須是 root 帳號 )

echo 'ulimit -HSn 65536'>> /etc/profile

echo 'ulimit -HSn 65536'>> /etc/rc.local

source /etc/profile

3. 腳本執(zhí)行時間超時

如果腳本因為某種原因長時間等待不返回，導(dǎo)致新來的請求不能得到處理，可以適當(dāng)調(diào)小如下配置。

nginx.conf 里面主要是如下

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

php-fpm.conf 里如要是如下

request_terminate_timeout =10s

4. 緩存設(shè)置比較小

修改或增加配置到 nginx.conf

proxy_buffer_size 64k;
proxy_buffers 512k;
proxy_busy_buffers_size 128k;

5. recv()failed (104: Connection reset by peer) while reading response header fromupstream

可能的原因機(jī)房網(wǎng)絡(luò)丟包或者機(jī)房有硬件防火墻禁止訪問該域名

但最重要的是程序里要設(shè)置好超時，不要使用 php-fpm 的 request_terminate_timeout ，

最好設(shè)成 request_terminate_timeout=0;

因為這個參數(shù)會直接殺掉 php 進(jìn)程，然后重啟 php 進(jìn)程，這樣前端 nginx 就會返回 104: Connection reset by peer 。這個過程是很慢，總體感覺就是網(wǎng)站很卡。

May 01 10:50:58.044162[WARNING] [pool www] child 4074, script'/usr/local/nginx/html/quancha/sameip/detail.php' execution timed out(15.129933 sec), terminating
May 01 10:50:58.045725 [WARNING] [pool www] child 4074 exited on signal 15SIGTERM after 90.227060 seconds from start
May 01 10:50:58.046818 [NOTICE] [pool www] child 4082 started

說一千道一萬最重要的就是程序里控制好超時， gethostbyname 、 curl 、 file_get_contents 等函數(shù)的都要設(shè)置超時時間。

另一個就是多說，這個東西是增加了網(wǎng)站的交互性，但是使用的多了反應(yīng)就慢了，如果你網(wǎng)站超時且使用了多說是，可以關(guān)閉它。

6、自己遇到502的解決辦法：

調(diào)整增大php 和Nginx 的backlog數(shù)。

PHP-FPM 高負(fù)載的解決辦法

Postedon 2011/09/02

這里只是介紹了 php-fpm 的優(yōu)化方法的，但一般情況下和 nginx 組合使用的時候，單獨優(yōu)化其中一項的話，作用不是特別的大，同時還需要對 nginx 進(jìn)行優(yōu)化

NGINX 頻爆 502 BAD GATEWAY 的錯誤，看了網(wǎng)上的教程，仍沒有徹底解決。

目前我總結(jié)的解決 502 BAD GATEWAY 的方式有： 1. 視服務(wù)器的性能，在 php-fmp.conf 里增加 max_children 的值，我目前用 reload 參數(shù)定時重載 php-fpm 。這個主要原因是 php 腳本執(zhí)行時間過長造成的，重載 php-fpm 能杜絕這個問題。如何徹底解決 php-cgi 腳本占用大量內(nèi)存從而導(dǎo)致 502 錯誤的產(chǎn)生還值得進(jìn)一步探討，目前該做法不失為一種好辦法。
具體的做法是，用 crontab 讓 php-fpm 平滑重啟，從而不影響 PHP 腳本的運行。

*/10* * * * /usr/local/php/sbin/php-fpm reload

優(yōu)化設(shè)置

When you running a highload websitewith PHP-FPM via FastCGI, the following tips may be useful to you : )

如果您高負(fù)載網(wǎng)站使用 PHP-FPM 管理 FastCGI ，這些技巧也許對您有用： )

1.Compile PHP's modules as less as possible, the simple the best (fast);

1. 盡量少安裝 PHP 模塊，最簡單是最好（快）的

2. Increas PHP FastCGI child number to 100 and even more.Sometime, 200 is OK! ( On 4GB memory server);

2. 把您的 PHP FastCGI 子進(jìn)程數(shù)調(diào)到 100 或以上，在 4G 內(nèi)存的服務(wù)器上 200 就可以

注：我的 1g 測試機(jī)，開 64 個是最好的，建議使用壓力測試獲取最佳值

3.Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;

3. 使用 socket 連接 FastCGI ， linux 操作系統(tǒng)可以放在 /dev/shm 中
注：在 php-fpm.cnf 里設(shè)置 <valuename=”listen_address”>/tmp/nginx.socket</value> 就可以通過 socket 連接 FastCGI 了， /dev/shm 是內(nèi)存文件系統(tǒng)，放在內(nèi)存中肯定會快了 . 記得這時也要在 nginx 里的配置里進(jìn)行修改，保持一致．

location~ .*\.(php|php5)?$

將 Nginx 與 FastCGI 的通信方式由 TCP 改為 UnixSocket 。 TCP 在高并發(fā)訪問下比 UnixSocket 穩(wěn)定，但 Unix Socket 速度要比 TCP快。