前端報502 bad gateway的原因及解決方案

245次閱讀

沒有評論

共計 5719 個字符，預計需要花費 15 分鐘才能閱讀完成。

前端報 502 bad gateway 怎么回事?502 Bad Gateway 服務器作為網關或者代理時，為了完成請求訪問下一個服務器，但該服務器返回了非法的應答。

解決辦法是：再刷新一下網頁或清理一下電腦的緩沖文件在打開你想打開的網頁就好了。一般情況下，這種辦法是行得通的，但也不排除你所訪問的網頁被屏蔽的可能，如果你所訪問的網頁被屏蔽的話，就不管你怎么刷新也是沒用的了。

1. 什么是 502 bad gateway 報錯

簡單來說 502 是報錯類型代碼 bad gateway 錯誤的網關

2. 產生 502 錯誤的原因

連接超時我們向服務器器發送請求由于服務器當前鏈接太多，導致服務器方面無法給于正常的響應, 產生此類報錯，具體如下：

第一個原因:

DNS 緩沖。這種情況的通常原因是因為你在未開啟 vpn 的情況下訪問了 facebook 這樣的網站。

這個時候自然訪問不上，同時卻在本機留下了緩沖。

這種情況通常在幾分鐘之內就可以訪問了。也可以嘗試在 dos 窗口運行 ipconfig /flushdns，該命令會刷新 DNS 緩沖。

第二個原因:

你的瀏覽器開了代理什么的。確認一下關掉代理。

第三個原因：

dns 被劫持了，即使使用國外的 dns，也會被劫持。有些機子開 vpn 能夠訪問，有些機子確不能。并且排除了代理、防火墻、本地網絡的原因。這個時候同時 ping 遠程網站，比如 facebook。不能訪問的機子通常獲取了一個怪異的 ip，從任何地方都 ping 不通的 ip。而能訪問的機子 ip，在不能訪問的機子上直接可以訪問，也可以 ping 通。這種情況我們可以去掉 VPN 服務器的 DNS。

切換另外的 dns。在 windows 系統中，可以在本地網絡連接的屬性中，去掉默認的 dns，選用國外的 dns，比如 google 的。或 opendns。

3.502 錯誤的 HTTP 周期

任何客戶端 (如 Web 瀏覽器或我們的 CheckUpDown 機器人) 經過下列循環時，與您的 Web 服務器溝通：

獲取您的網站 IP 地址的 IP 名稱 (您的網站 URL 的領導’http://‘)。這查找(轉換的知識產權名稱，IP 地址) 所提供的域名服務器(DNSs)。

打開一個 IP 套接字連接到該 IP 地址。寫一個 HTTP 數據流通過該套接字。

從您的響應的 Web 服務器收到一個 HTTP 數據流。此數據流包含狀態碼的值是由 HTTP 協議。解析此數據流的狀態碼和其他有用信息。

這個錯誤發生在最后一步時，上面的客戶端收到一個 HTTP 狀態碼，它確認為 502‘。

4. 固定 502 錯誤

一般這個問題是由于不良的 IP 之間的溝通后端計算機，包括您可能嘗試訪問的在 Web 服務器上的網站。在分析這個問題，您應該完全清除瀏覽器緩存。

如果您上網時在您嘗試訪問的所有網站上都看這個問題，有兩種可能

1 )你的 ISP 出了重大設備故障 / 過載

2 )有問題的內部互聯網連接如您的防火墻無法正常運作。

在第一種情況下，只有您的 ISP 可以幫助您。在第二種情況下，就需您自己解決任何阻止您進入互聯網的問題。

如果您只有在部分嘗試訪問的網站中出現此問題，那就很可能是一個問題，即這些網站之一，其設備故障或超載。聯系網站的管理員。

5. 出現 502 bad gateway 如何解決問題

最簡單的方法：CTRL+F5 強制刷新

最好的解決辦法當然還是在服務器上做對大家來說不太可能 , 那么我們有什么解救的方法呢? 說白了很簡單, 就是——刷新(不是一般的刷新哦)

刷新的原理：很多人可能不知道刷新也是有兩種的。所謂刷新其實就是從服務器下載數據到本地的硬盤瀏覽器, 再從本地硬盤種讀取數據到瀏覽器顯示給我們看。

①基本刷新：就是點擊刷新或者使用 F5 快捷鍵, 基本刷新只是從本地的硬盤重新拿取數據到瀏覽器，并不重新向服務器發出請求。大部分用戶很多時候都是這樣刷新的，遇到 502 報錯的就沒有任何效果。

②從服務器刷新：如果你重新直接點擊你想要瀏覽的網頁鏈接，你會發現剛才還是顯示 502 bad getway 的頁面現在又可以正常瀏覽了! 明白道理了吧? 當你點擊你想要瀏覽的網頁鏈接的時候，是會從服務器重新下載數據的。解決方法就是從服務器上刷新：快捷鍵 ctrl+F5，這樣就是重新向服務器發送請求了。如果服務器能正常給予你響應你就可以看到頁面了。

另附：

nginx 502 bad gateway 錯誤的原因及解決方法

nginx 502 bad Gateway 的錯誤已經遇到好幾次了，這里做一下記錄，備忘哈哈。

會有好多種情況出現 502 錯誤，下面我們分情況來說一下。

一、fastcgi 緩沖區設置過小

出現錯誤，首先要查找 nginx 的日志文件，目錄為 /var/log/nginx，在日志中發現了如下錯誤。

2013/01/17 13:33:47 [error] 15421#0: *16 upstream sent too big header while reading response header from upstream

查閱了一下資料，大意是 nginx 緩沖區有一個 bug 造成的, 我們網站的頁面消耗占用緩沖區可能過大。

網上查找了一下解決方法，在國外網站看到了一個增加緩沖區的方法，徹底解決了 Nginx 502 Bad Gateway 的問題。方法如下：

http {

…

fastcgi_buffers 8 16k;

fastcgi_buffer_size 32k;

…

}

請根據服務器已經網站的情況自行增大上述兩個配置項。

二、代理緩沖區設置過小

如果你使用的是 nginx 反向代理，如果 header 過大，超出了默認的 1k，就會引發上述的 upstream sent too big header (說白了就是 nginx 把外部請求給后端處理，后端返回的 header 太大，nginx 處理不過來就會導致 502。

server {

listen 80;

server_name *.lxy.me;

location / {

############### 添加這 3 行

proxy_buffer_size 64k;

proxy_buffers 32 32k;

proxy_busy_buffers_size 128k;

############### 添加這 3 行

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

…………

}

三、默認 php-cgi 的進程數設置過少

在安裝好使用過程中出現 502 問題，一般是因為默認 php-cgi 進程是 5 個，可能因為 phpcgi 進程不夠用而造成 502，需要修改 /usr/local/php/etc/php-fpm.conf 將其中的 max_children 值適當增加。也有可能是 max_requests 值不夠用。需要說明的是這連個配置項占用內存很大，請根據服務器配置進行設置。否則可能起到反效果。

四、php 執行超時

php 執行超時，修改 /usr/local/php/etc/php.ini 將 max_execution_time 改為 300

五、nginx 等待時間超時

部分 PHP 程序的執行時間超過了 Nginx 的等待時間，可以適當增加 nginx.conf 配置文件中 FastCGI 的 timeout 時間

http {

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

……

}

nginx 502 bad gateway

一些運行在 Nginx 上的網站有時候會出現“502 Bad Gateway”錯誤，有些時候甚至頻繁的出現。以下是小編搜集整理的一些 Nginx 502 錯誤的排查方法，供參考：

Nginx 502 錯誤的原因比較多，是因為在代理模式下后端服務器出現問題引起的。這些錯誤一般都不是 nginx 本身的問題，一定要從后端找原因! 但 nginx 把這些出錯都攬在自己身上了，著實讓 nginx 的推廣者備受置疑，畢竟從字眼上理解，bad gateway? 不就是 bad nginx 嗎? 讓不了解的人看到，會直接把責任推在 nginx 身上，希望 nginx 下一個版本會把出錯提示寫稍微友好一些，至少不會是現在簡單的一句 502 Bad Gateway，另外還不忘附上自己的大名。

Nginx 502 的觸發條件

502 錯誤最通常的出現情況就是后端主機當機。在 upstream 配置里有這么一項配置：proxy_next_upstream，這個配置指定了 nginx 在從一個后端主機取數據遇到何種錯誤時會轉到下一個后端主機，里頭寫上的就是會出現 502 的所有情況拉，默認是 error timeout。error 就是當機、斷線之類的，timeout 就是讀取堵塞超時，比較容易理解。我一般是全寫上的：

proxy_next_upstream error timeout invalid_header http_500 http_503;

不過現在可能我要去掉 http_500 這一項了，http_500 指定后端返回 500 錯誤時會轉一個主機，后端的 jsp 出錯的話，本來會打印一堆 stacktrace 的錯誤信息，現在被 502 取代了。但公司的程序員可不這么認為，他們認定是 nginx 出現了錯誤，我實在沒空跟他們解釋 502 的原理了……

503 錯誤就可以保留，因為后端通常是 apache resin，如果 apache 死機就是 error，但 resin 死機，僅僅是 503，所以還是有必要保留的。

解決辦法

遇到 502 問題，可以優先考慮按照以下兩個步驟去解決。

1、查看當前的 PHP FastCGI 進程數是否夠用：

netstat -anpo | grep “php-cgi” | wc -l

如果實際使用的“FastCGI 進程數”接近預設的“FastCGI 進程數”，那么，說明“FastCGI 進程數”不夠用，需要增大。

2、部分 PHP 程序的執行時間超過了 Nginx 的等待時間，可以適當增加 nginx.conf 配置文件中 FastCGI 的 timeout 時間，例如：

http {

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

……

}

……

php.ini 中 memory_limit 設低了會出錯，修改了 php.ini 的 memory_limit 為 64M，重啟 nginx，發現好了，原來是 PHP 的內存不足了。

如果這樣修改了還解決不了問題，可以參考下面這些方案：

一、max-children 和 max-requests

一臺服務器上運行著 nginx php(fpm) xcache，訪問量日均 300W pv 左右。

最近經常會出現這樣的情況：php 頁面打開很慢，cpu 使用率突然降至很低，系統負載突然升至很高，查看網卡的流量，也會發現突然降到了很低。這種情況只持續數秒鐘就恢復了。

檢查 php-fpm 的日志文件發現了一些線索。

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200 Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10,“127.0.0.1:9000″ Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587

在這幾句的前面，是 1000 多行的關閉 children 和開啟 children 的日志。

原來，php-fpm 有一個參數 max_requests，該參數指明了，每個 children 最多處理多少個請求后便會被關閉，默認的設置是 500。因為 php 是把請求輪詢給每個 children，在大流量下，每個 childre 到達 max_requests 所用的時間都差不多，這樣就造成所有的 children 基本上在同一時間被關閉。

在這期間，nginx 無法將 php 文件轉交給 php-fpm 處理，所以 cpu 會降至很低(不用處理 php，更不用執行 sql)，而負載會升至很高(關閉和開啟 children、nginx 等待 php-fpm)，網卡流量也降至很低(nginx 無法生成數據傳輸給客戶端)

解決問題很簡單，增加 children 的數量，并且將 max_requests 設置為 0 或者一個比較大的值：

打開 /usr/local/php/etc/php-fpm.conf 調大以下兩個參數(根據服務器實際情況，過大也不行)

5120 600

然后重啟 php-fpm。

二、增加緩沖區容量大小

將 nginx 的 error log 打開，發現“pstream sent too big header while reading response header from upstream”這樣的錯誤提示。查閱了一下資料，大意是 nginx 緩沖區有一個 bug 造成的, 我們網站的頁面消耗占用緩沖區可能過大。參考老外寫的修改辦法增加了緩沖區容量大小設置，502 問題徹底解決。后來系統管理員又對參數做了調整只保留了 2 個設置參數：client head buffer，fastcgi buffer size。

三、request_terminate_timeout

如果主要是在一些 post 或者數據庫操作的時候出現 502 這種情況，而不是在靜態頁面操作中常見，那么可以查看一下 php-fpm.conf 設置中的一項：

request_terminate_timeout

這個值是 max_execution_time，就是 fast-cgi 的執行腳本時間。

0s

0s 為關閉，就是無限執行下去。(當時裝的時候沒仔細看就改了一個數字)問題解決了，執行很長時間也不會出錯了。優化 fastcgi 中，還可以改改這個值 5s 看看效果。

php-cgi 進程數不夠用、php 執行時間長、或者是 php-cgi 進程死掉，都會出現 502 錯誤。

正文完