寫日志之前先copy一段nginx502的原因，從某網看到如下，然而這並不是重點，最重要還是看博主手敲的東西。
一、NGINX 502錯誤排查
NGINX 502 Bad Gateway錯誤是FastCGI有問題，造成NGINX
502錯誤的可能性比較多。將網上找到的一些和502 Bad
Gateway錯誤有關的問題和排查方法列一下，先從FastCGI配置入手：
1.FastCGI進程是否已經啟動
2.FastCGI worker進程數是否不夠
運行 netstat -anpo | grep “php-cgi” | wc -l
判斷是否接近FastCGI進程，接近配置文件中設置的數值，表明worker進程數設置太少
3.FastCGI執行時間過長
根據實際情況調高以下參數值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.FastCGI Buffer不夠
nginx和apache一樣，有前端緩沖限制，可以調整緩沖參數
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
5.Proxy Buffer不夠
如果你用了Proxying，調整
proxy_buffer_size 16k;
proxy_buffers 4 16k;
參見：http://www.server110.com
6.https轉發配置錯誤
正確的配置方法
server_name www.mydomain.com;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}
當然，還要看你後端用的是哪種類型的FastCGI，我用過的有php-fpm，流量約為單台機器40萬PV(動態頁面),
現在基本上沒有碰到502。
7.php腳本執行時間過長
將php-fpm.conf的<value
name="request_terminate_timeout">0s</value>的0s改成一個時間
~~~~~~~~~~~~~~~~~~~~~~~~~~~華麗麗的分割線~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
博主遇到的問題是因為代碼中有一個參數通過引用傳遞，然後訪問之後直接502，博主看到此信息，第一時間是直接把display_errors打開，
然後我就有疑問了為什麼打開了錯誤顯示，就不502了，只是有些E_STRICT的警告，之後經過了一輪輪調試，仍舊沒有辦法之後原因。
無可奈何之後查看了nginx的錯誤截圖如下。當時想這尼瑪不是php fastcgi的報錯，為什麼會出現在nginx的錯誤日志裡面，這感覺不怎麼科學，苦思冥想
再經過幾輪傷痛無果的調試，依然感覺無力，只能先暫告一段落。
作為一個幸運的程序員，不知道動了那根筋想倒騰一下之後本地虛擬機環境中一直不寫錯誤日志文件的問題，配置是沒有問題，就是不寫錯誤日志。（各位看官不要吐槽，因為博主平常都是
直接頁面顯示錯誤加xdebug，所以覺得無所謂，不寫關我毛毛雨的事情，不虛。）博主慧眼加高等智慧的大腦（這個時代寫博主必須加點逼格）覺得應該是文件權限的問題，然後果斷來一下
chmod 777高超技能，重啟php-fpm，來段錯誤代碼測試了一下，尼瑪還是如預期寫入了錯誤日志文件。此刻回想起來上午的問題，總感覺輸出的錯誤警告神馬會不會和寫入日志的一樣。覺
得那就裸衣干，tail一下錯誤日志，屏蔽display，撸一下代碼，尼瑪此刻竟然不報502了，完美運行，錯誤日志如期寫入日志文件，不科學啊，打開nginx的錯誤日志再撸一發發現nginx沒有了
錯誤。
好吧！感覺問題找到了關於502錯誤是因為php的錯誤日志權限問題，沒有辦法寫入，然後直接拋給了cgi，所以nginx就502了。至於為什麼會下拋給cgi，這個我也不懂，別問我，懂的人後面
過幾招。
哎呦，不錯哦。此段裝逼路程結束。謝謝Tvb，謝謝爸媽，謝謝博客園。
