nginx+php 出現502 bad gateway，通常這都不是nginx的問題，而是因爲 fastcgi或者php的問題致使的，常見的有如下幾種。php
1. php.ini 的memory_limit 太小（若是有個別php程序進程須要佔用極大內存時這個必須注意）html
2. php-fpm.conf 中max_children或者max_requests 設置不合理（設置太小會由於沒有足夠的cgi進程處理請求，設置過大會出現一下子有響應正常，一下子等好久纔有響應的狀況，通常狀況下children 按 照內存計算，好比說1G設置64，2G128。這個根據實際狀況自行調整。另外查看當前的PHP FastCGI進程數是否夠用的命令爲：netstat -anpo |grep “php-cgi” | wc -l 若是實際使用的“FastCGI進程數”接近預設的“FastCGI進程 數”，那麼，說明“FastCGI進程數”不夠用，須要增大。）前端
3. 查看nginx錯誤日誌，發現 pstream sent too big header while reading response headerfrom upstream ，則檢查client head buffer，fastcgi buffer size是否太小，可設置爲32K。linux
4. php 程序執行時間過長而超時，檢查nginx和fastcgi中各類timeout設置。（nginx 中的 fastcgi_connect_timeout 300;fastcgi_send_timeout 300 ：fastcgi_read_timeout300; keepalive_timeout ； php-fpm中的request_terminate_timeout，php.ini中的max_execution_time）nginx
5. php-fpm 有一個參數 max_requests ，該參數指明瞭每一個children最多處理多少個請求後便會被關閉。在大量處理請求下，若是該值設置太小會致使 children頻繁的自殺和創建而浪費 大量時間，若全部的children差很少都在這個時候自殺，則重建前將沒有children響應請求，因而出現502 。能夠將該值設置大一些或者是0[無限]。web
以上差很少是比較常見的502的問題緣由以及解決辦法，其實解決問題的最好的方式仍是本身去看nginx和fastcgi的errorlog。後端
最後借用網上的萬金油說法作個總結： php-cgi進程數不夠用、php執行時間長、或者是php-cgi進程死掉，都會出現502錯誤。緩存
502 錯誤是全部用 nginx 跑 php 的運維人員不肯意看見的服務器
nginx 出現 502 有不少緣由，但大部分緣由能夠歸結爲資源數量不夠用 , 也就是說後端 php-fpm 處理有問題， nginx 將正確的客戶端請求發給了後端的 php-fpm 進程，可是由於 php-fpm 進程的問題致使不能正確解析 php 代碼，最終返回給了客戶端 502 錯誤。網絡
服務器出現 502 的緣由是鏈接超時 咱們向服務器發送請求 因爲服務器當前連接太多，致使服務器方面沒法給於正常的響應 , 產生此類報錯
所以若是你服務器併發量很是大，那隻能先增長機器，而後按如下方式優化會取得更好效果 ; 但若是你併發不大卻出現 502 ，通常均可以歸結爲配置問題，腳本超時問題。
1.php-fpm 進程數不夠用
使用 netstat -napo |grep "php-fpm" | wc -l 查看一下當前 fastcgi 進程個數，若是個數接近 conf 裏配置的上限，就須要調高進程數。
但也不能無休止調高，能夠根據服務器內存狀況，能夠把 php-fpm 子進程數調到 100 或以上，在 4G 內存的服務器上 200 就能夠。
2. 調高調高 linux 內核打開文件數量
可使用這些命令 ( 必須是 root 賬號 )
echo 'ulimit -HSn 65536'>> /etc/profile
echo 'ulimit -HSn 65536'>> /etc/rc.local
source /etc/profile
3. 腳本執行時間超時
若是腳本由於某種緣由長時間等待不返回 ，致使新來的請求不能獲得處理，能夠適當調小以下配置。
nginx.conf 裏面主要是以下
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
php-fpm.conf 裏如要是以下
request_terminate_timeout =10s
4. 緩存設置比較小
修改或增長配置到 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
可能的緣由機房網絡丟包或者機房有硬件防火牆禁止訪問該域名
但最重要的是程序裏要設置好超時，不要使用 php-fpm 的 request_terminate_timeout ，
最好設成 request_terminate_timeout=0;
由於這個參數會直接殺掉 php 進程，而後重啓 php 進程，這樣前端 nginx 就會返回 104: Connection reset by peer 。這個過程是很慢，整體感受就是網站很卡。
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 等函數的都要設置超時時間。
另外一個就是多說，這個東西是增長了網站的交互性，可是使用的多了反應就慢了，若是你網站超時且使用了多說是，能夠關閉它。
六、本身遇到502的解決辦法：
調整增大php 和Nginx 的backlog數。
PHP-FPM 高負載的解決辦法
Postedon 2011/09/02
這裏只是介紹了 php-fpm 的優化方法的，但通常狀況下和 nginx 組合使用的時候，單獨優化其中一項的話，做用不是特別的大，同時還須要對 nginx 進行優化． nginx 的作法方法參考： http://blog.haohtml.com/archives/6213 . 上面的優化前和優化後的圖，看得出先後差距仍是特別的大的．
致使 nginx 502 bad gateway 的PHP-CGI(FASTCGI)
NGINX 頻爆 502 BAD GATEWAY 的錯誤，看了網上的教程，仍沒有完全解決。
目前我總結的解決 502 BAD GATEWAY 的方式有： 1. 視服務器的性能，在 php-fmp.conf 裏增長 max_children 的值，我目前用的
15.
2.
用 reload 參數定時重載 php-fpm 。這個主要緣由是 php 腳本執行時間過長形成的，重載 php-fpm 能杜絕這個問題。如何完全解決 php-cgi 腳本佔用大量內存從而致使 502 錯誤的產生還值得進一步探討，目前該作法不失爲一種好辦法。具體的作法是，用 crontab 讓 php-fpm 平滑重啓，從而不影響 PHP 腳本的運行。
*/10* * * * /usr/local/php/sbin/php-fpm reload
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 優化設置 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
When you running a highload websitewith PHP-FPM via FastCGI, the following tips may be useful to you : )
若是您高負載網站使用 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 子進程數調到 100 或以上，在 4G 內存的服務器上 200 就能夠
注：個人 1g 測試機，開 64 個是最好的，建議使用壓力測試獲取最佳值
3.Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;
3. 使用 socket 鏈接 FastCGI ， linux 操做系統能夠放在 /dev/shm 中
注：在 php-fpm.cnf 裏設置 <valuename=」listen_address」>/tmp/nginx.socket</value> 就能夠經過 socket 鏈接 FastCGI 了， /dev/shm 是內存文件系統，放在內存中確定會快了 . 記得這時也要在 nginx 裏的配置裏進行修改，保持一致．
location~ .*\.(php|php5)?$
{
#
將 Nginx 與 FastCGI 的通訊方式由 TCP 改成 UnixSocket 。 TCP 在高併發訪問下比 UnixSocket 穩定，但 Unix Socket 速度要比 TCP 快。fastcgi_pass unix:/tmp/php-cgi.sock;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
4. Increase Linux 「max open files」, using the following command(must be root):
# echo ‘ulimit -HSn 65536′>> /etc/profile
# echo ‘ulimit -HSn 65536 >> /etc/rc.local
# source /etc/profile
4. 調高 linux 內核打開文件數量，可使用這些命令 ( 必須是 root 賬號
)
echo ‘ulimit -HSn 65536′ >> /etc/profile
echo ‘ulimit -HSn 65536′ >> /etc/rc.local
source /etc/profile
注：我是修改 /etc/rc.local ，加入 ulimit -SHn 51200 的
5.Increase PHP-FPM open file description rlimit:
# vi /path/to/php-fpm.conf
Find 「<value name=」rlimit_files」>1024</value>」
Change 1024 to 4096 or higher number.
Restart PHP-FPM.
5. 增長 PHP-FPM 打開文件描述符的限制
:
# vi /path/to/php-fpm.conf
找到「<value name=」rlimit_files」>1024</value>」
把 1024 更改成 4096 或者更高.
重啓 PHP-FPM.6. Using PHP code accelerator,e.g eAccelerator, XCache. And set 「cache_dir」 to /dev/shm on Linux.
6. 使用 php 代碼加速器，例如 eAccelerator, XCache. 在 linux 平臺上能夠把 `cache_dir` 指向 /dev/shm