Nginx php如何解決502 Bad Gateway錯誤
在Web服務器中有很多先進的技術(shù)，Nginx php就是其中的一個，接下來我們就看看在Nginx 中的相關(guān)問題解決，希望大家有所收獲。Nginx php中配置php fastcgi組解決莫名其妙的502 Bad Gateway錯誤
一般Nginx php都采用這樣的方式：
- location ~ \.php$ {
- proxy_pass http://localhost:9000;
- fastcgi_param SCRIPT_FILENAME /data/_hongdou$fastcgi_
script_name;- include fastcgi_params;
- }
這個方式只能連接到一組spawn-fcgi開啟的fastcgi，在服務器負載稍高時常常出現(xiàn)502 bad gateway錯誤。
起先懷疑這是php-cgi的進程開得太少，增加后仍然有反映時常有錯，偶然間發(fā)現(xiàn)php-cgi會報出這樣的錯誤：
- zend_mm_heap corrupted
看來是php-cgi在執(zhí)行某些代碼時有問題，以致于該線程中止。
在服務器上可能還會看到php-cgi進程在不斷變少，估計是出現(xiàn)錯誤的php-cgi的進程自動退出了。
php的問題總是不太容易能解決，所以在Nginx php方面想想辦法，Nginx的好處是它總是能爆出一些稀奇古怪的做法出來。在Nginx的proxy中，規(guī)避莫名其妙錯誤的辦法無非是proxy到一個upstream的服務器組中，然后配置proxy_next_upstream，讓Nginx遇到某種錯誤碼時，自動跳到下一個后端上。這樣，應用服務器即使不穩(wěn)定，但是在Nginx后面就變成了穩(wěn)定服務。想到Nginx的fastcgi和proxy是一路東西，所以proxy能用的經(jīng)驗，移植到fastcgi也能跑得起來。照著這個思路，用spawn-fcgi多開同樣一組php進程，所不同的僅僅是端口：
- 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é)果正確，能跑起來；同時在服務器上netstat -n|grep 9000和grep 9001都有記錄，證明連接無誤；在前臺查閱頁面，一切運行正常。這個配置是最簡單的配置，既然能連接上upstream，那么很顯然upstream的一些東西都可以拿來用，比如ip_hash、weight、max_fails等。這樣的配置在單機下不知能不能共享session，沒有測試，如果有問題，可以加上ip_hash，或者配置php把session存進memcached中。然后就是fastcgi_next_upstream的配置，Nginx wiki中沒有介紹到這個配置，查了一下，在Nginx php的CHANGES中有提到，而且出生年月是和proxy_next_upstream一樣的。
既然如此，那就照proxy_next_upstream一樣配吧。一般按默認的值error timeout就可以工作，因為php出現(xiàn)502錯誤的異常是返回的500錯誤，所以我把fastcgi_next_upstream定為：fastcgi_next_upstream error timeout invalid_header http_500;通過這個配置，就可以基本杜絕任何時常性的500錯誤，出問題的幾率會變小很多，如果客戶反映仍然激烈，那么就多增加幾組fastcgi進程。以上配置能夠杜絕由于php所引起的“莫名其妙”的時常性的502錯誤，同時可使Nginx搭配php比從前方式更為強悍。假如Nginx還是返回502錯誤，那這次就一定是出現(xiàn)服務器掛掉或其它嚴重問題的了。
【編輯推薦】
