這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)Nginx php怎樣解決502 Bad Gateway錯(cuò)誤，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)成立以來(lái)不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術(shù)為基點(diǎn)，以客戶需求中心、市場(chǎng)為導(dǎo)向”的快速反應(yīng)體系。對(duì)公司的主營(yíng)項(xiàng)目，如中高端企業(yè)網(wǎng)站企劃 / 設(shè)計(jì)、行業(yè) / 企業(yè)門(mén)戶設(shè)計(jì)推廣、行業(yè)門(mén)戶平臺(tái)運(yùn)營(yíng)、app開(kāi)發(fā)定制、手機(jī)網(wǎng)站開(kāi)發(fā)、微信網(wǎng)站制作、軟件開(kāi)發(fā)、香港機(jī)房服務(wù)器托管等實(shí)行標(biāo)準(zhǔn)化操作，讓客戶可以直觀的預(yù)知到從成都創(chuàng)新互聯(lián)可以獲得的服務(wù)效果。

在Web服務(wù)器中有很多先進(jìn)的技術(shù)，Nginx php就是其中的一個(gè)，接下來(lái)我們就看看在Nginx 中的相關(guān)問(wèn)題解決，希望大家有所收獲。Nginx php中配置php fastcgi組解決莫名其妙的502 Bad Gateway錯(cuò)誤

一般Nginx php都采用這樣的方式：

location ~ \.php$ {  
proxy_pass http://localhost:9000;  
fastcgi_param SCRIPT_FILENAME /data/_hongdou$fastcgi_
script_name;  
include fastcgi_params;  
} 

這個(gè)方式只能連接到一組spawn-fcgi開(kāi)啟的fastcgi，在服務(wù)器負(fù)載稍高時(shí)常常出現(xiàn)502 bad gateway錯(cuò)誤。

起先懷疑這是php-cgi的進(jìn)程開(kāi)得太少，增加后仍然有反映時(shí)常有錯(cuò)，偶然間發(fā)現(xiàn)php-cgi會(huì)報(bào)出這樣的錯(cuò)誤：

zend_mm_heap corrupted

看來(lái)是php-cgi在執(zhí)行某些代碼時(shí)有問(wèn)題，以致于該線程中止。

在服務(wù)器上可能還會(huì)看到php-cgi進(jìn)程在不斷變少，估計(jì)是出現(xiàn)錯(cuò)誤的php-cgi的進(jìn)程自動(dòng)退出了。

php的問(wèn)題總是不太容易能解決，所以在Nginx php方面想想辦法，Nginx的好處是它總是能爆出一些稀奇古怪的做法出來(lái)。在Nginx的proxy中，規(guī)避莫名其妙錯(cuò)誤的辦法無(wú)非是proxy到一個(gè)upstream的服務(wù)器組中，然后配置proxy_next_upstream，讓Nginx遇到某種錯(cuò)誤碼時(shí)，自動(dòng)跳到下一個(gè)后端上。這樣，應(yīng)用服務(wù)器即使不穩(wěn)定，但是在Nginx后面就變成了穩(wěn)定服務(wù)。想到Nginx的fastcgi和proxy是一路東西，所以proxy能用的經(jīng)驗(yàn)，移植到fastcgi也能跑得起來(lái)。照著這個(gè)思路，用spawn-fcgi多開(kāi)同樣一組php進(jìn)程，所不同的僅僅是端口：

spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f php-cgi -C 100  
spawn-fcgi -a 127.0.0.1 -p 9001 -u nobody -f php-cgi -C 100 

然后把fastcgi的這段配置改成用upstream的方式：

upstream backend {  
server 127.0.0.1:9000;  
server 127.0.0.1:9001;  
}  
location ~ \.php$ {  
proxy_pass http://backend;  
fastcgi_param SCRIPT_FILENAME /data/_hongdou$fastcgi_
script_name;  
include fastcgi_params;  
} 

檢查配置結(jié)果正確，能跑起來(lái)；同時(shí)在服務(wù)器上netstat -n|grep 9000和grep 9001都有記錄，證明連接無(wú)誤；在前臺(tái)查閱頁(yè)面，一切運(yùn)行正常。這個(gè)配置是最簡(jiǎn)單的配置，既然能連接上upstream，那么很顯然upstream的一些東西都可以拿來(lái)用，比如ip_hash、weight、max_fails等。這樣的配置在單機(jī)下不知能不能共享session，沒(méi)有測(cè)試，如果有問(wèn)題，可以加上ip_hash，或者配置php把session存進(jìn)memcached中。然后就是fastcgi_next_upstream的配置，Nginx wiki中沒(méi)有介紹到這個(gè)配置，查了一下，在Nginx php的CHANGES中有提到，而且出生年月是和proxy_next_upstream一樣的。

既然如此，那就照proxy_next_upstream一樣配吧。一般按默認(rèn)的值error timeout就可以工作，因?yàn)閜hp出現(xiàn)502錯(cuò)誤的異常是返回的500錯(cuò)誤，所以我把fastcgi_next_upstream定為：fastcgi_next_upstream error timeout invalid_header http_500;通過(guò)這個(gè)配置，就可以基本杜絕任何時(shí)常性的500錯(cuò)誤，出問(wèn)題的幾率會(huì)變小很多，如果客戶反映仍然激烈，那么就多增加幾組fastcgi進(jìn)程。以上配置能夠杜絕由于php所引起的“莫名其妙”的時(shí)常性的502錯(cuò)誤，同時(shí)可使Nginx搭配php比從前方式更為強(qiáng)悍。假如Nginx還是返回502錯(cuò)誤，那這次就一定是出現(xiàn)服務(wù)器掛掉或其它嚴(yán)重問(wèn)題的了。

上述就是小編為大家分享的Nginx php怎樣解決502 Bad Gateway錯(cuò)誤了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。