nginx怎麼識別後端伺服器異常

❶ 從nginx訪問日誌中怎麼看後端伺服器的狀態信息(nginx前端傳給後端看後端響應

nginx的日誌格式是可以通過日橘蔽志模塊去配置的。

比如：棚余$status 記錄請求狀態，$body_bytes_sent 發送給客戶端的位元組數，不鏈伍滾包括響應頭的大小，$bytes_sent 發送給客戶端的總位元組數等。可在nginx配置文件中這樣配置：

配置完後重啟nginx服務，再查看日誌。

❷ nginx反向代理忽略證書異常

nginx反向代理虧歲忽略證判銀書異常：可以在nginx上配置證書，後端伺服器就不再需要配置證書了。

反向代理配置有誤：沒有正確配置反向代理，如反向代理的機器地址、域名解析、埠號等配置錯誤。

所有的可用冗餘機器全部不可訪問：反向代理可以配置多個冗餘的機器，也可以只配置一個，當所有配置的被反向代掘空宴理的機器全不可訪問，如網路異常等，會導致反向代理後不能顯示。

支持操作系統：

FreeBSD 3— 10 / i386; FreeBSD 5— 10 / amd64。

linux 2.2— 4 / i386; Linux 2.6— 4 / amd64; Linux 3— 4 / armv6l, armv7l, aarch64。

Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v。

AIX7.1 /powerpc。

HP-UX 11.31 / ia64。

Mac OS X/ ppc, i386。

Windows XP,Windows Server 2003,Windows 10。

❸ 如何通過配置NGINX和NGINX Plus來緩解DDoS攻擊

DDOS是一種通過大流量的請求對目標進行轟炸式訪問，導致提供服務的伺服器資源耗盡進而無法繼續提供服務的攻擊手段。

一般盯棗情況下，攻擊者通過大量耐舉請求與連接使伺服器處於飽和狀態，以至於無法接受新的請求或變得很慢。

應用層DDOS攻擊的特徵

應用層（七層/HTTP層）DDOS攻擊通常由木馬程序發起，其可以通過設計更好的利用目標系統的脆弱點。例如，對於無法處理大量並發請求的系統，僅僅通過建立大量的連接，並周期性的發出少量數據包來保持會話就可以耗盡系統的資源，使其無法接受新的連接請求達到DDOS的目的。其他還有採用發送大量連接請求發送大數據包的請求進行攻擊的形式。因為攻擊是由木馬程序發起，攻擊者可以在很短時間內快速建立大量的連接，並發出大量的請求。

以下是一些DDOS的特證，我們可以據此特徵來抵抗DDOS（包括但不限於）：

攻擊經常來源於一些相對固定的IP或IP段，每個IP都有遠大於真實用戶的連接數和請求數。

備註：這並不表明這種請求都是代表著DDOS攻擊。在很多使用NAT的網路架構中，很多的客戶端使用網關的IP地址訪問公網資源。但是，即便如此，這樣的請求數和連接數也會遠少於DDOS攻擊。

因為攻擊是由木馬發出且目的是使昌則碧伺服器超負荷，請求的頻率會遠遠超過正常人的請求。

User-Agent通常是一個非標準的值

Referer有時是一個容易聯想到攻擊的值

使用Nginx、Nginx Plus抵抗DDOS攻擊

結合上面提到的DDOS攻擊的特徵，Nginx、Nginx Plus有很多的特性可以用來有效的防禦DDOS攻擊，可以從調整入口訪問流量和控制反向代理到後端伺服器的流量兩個方面來達到抵禦DDOS攻擊的目的。

限制請求速度

設置Nginx、Nginx Plus的連接請求在一個真實用戶請求的合理范圍內。比如，如果你覺得一個正常用戶每兩秒可以請求一次登錄頁面，你就可以設置Nginx每兩秒鍾接收一個客戶端IP的請求（大約等同於每分鍾30個請求）。

php">limit_req_zone$binary_remote_addrzone=one:10mrate=30r/m;
server{
...
location/login.html{
limit_reqzone=one;
...
}
}`limit_req_zone`命令設置了一個叫one的共享內存區來存儲請求狀態的特定鍵值，在上面的例子中是客戶端IP($binary_remote_addr)。location塊中的`limit_req`通過引用one共享內存區來實現限制訪問/login.html的目的。
限制連接數量
設置Nginx、NginxPlus的連接數在一個真實用戶請求的合理范圍內。比如，你可以設置每個客戶端IP連接/store不可以超過10個。
limit_conn_zone$binary_remote_addrzone=addr:10m;
server{
...
location/store/{
limit_connaddr10;
...
}
}

`limit_conn_zone`命令設置了一個叫addr的共享內存區來存儲特定鍵值的狀態，在上面的例子中是客戶端IP（ $binary_remote_addr）。location塊中`limit_conn`通過引用addr共享內存區來限制到/store/的最大連接數為10。

關閉慢連接

有一些DDOS攻擊，比如Slowlris，是通過建立大量的連接並周期性的發送一些數據包保持會話來達到攻擊目的，這種周期通常會低於正常的請求。這種情況我們可以通過關閉慢連接來抵禦攻擊。

`client_body_timeout`命令用來定義讀取客戶端請求的超時時間，`client_header_timeout`命令用來定於讀取客戶端請求頭的超時時間。這兩個參數的默認值都是60s，我們可以通過下面的命令將他們設置為5s：

server{
client_body_timeout5s;
client_header_timeout5s;
...
}

設置IP黑名單

如果確定攻擊來源於某些IP地址，我們可以將其加入黑名單，Nginx就不會再接受他們的請求。比如，你已經確定攻擊來自於從123.123.123.1到123.123.123.16的一段IP地址，你可以這樣設置：

location/{
deny123.123.123.0/28;
...
}

或者你確定攻擊來源於123.123.123.3、123.123.123.5、123.123.123.7幾個IP，可以這樣設置：

location/{
deny123.123.123.3;
deny123.123.123.5;
deny123.123.123.7;
...
}

設置IP白名單

如果你的網站僅允許特定的IP或IP段訪問，你可以結合使用allow和deny命令來限制僅允許你指定的IP地址訪問你的網站。如下，你可以設置僅允許192.168.1.0段的內網用戶訪問：

location/{
allow192.168.1.0/24;
denyall;
...
}

deny命令會拒絕除了allow指定的IP段之外的所有其他IP的訪問請求。

使用緩存進行流量削峰

通過打開Nginx的緩存功能並設置特定的緩存參數，可以削減來自攻擊的流量，同時也可以減輕對後端伺服器的請求壓力。以下是一些有用的設置：

`proxy_cache_use_stale `的updating參數告訴Nginx什麼時候該更新所緩存的對象。只需要到後端的一個更新請求，在緩存有效期間客戶端對該對象的請求都無需訪問後端伺服器。當通過對一個文件的頻繁請求來實施攻擊時，緩存功能可極大的降低到後端伺服器的請求。

`proxy_cache_key `命令定義的鍵值通常包含一些內嵌的變數（默認的鍵值$scheme$proxy_host$request_uri包含了三個變數）。如果鍵值包含`$query_string`變數，當攻擊的請求字元串是隨機的時候就會給Nginx代理過重的緩存負擔，因此我們建議一般情況下不要包含`$query_string`變數。

屏蔽特的請求

可以設置Nginx、Nginx Plus屏蔽一些類型的請求：

針對特定URL的請求

針對不是常見的User-Agent的請求

針對Referer頭中包含可以聯想到攻擊的值的請求

針對其他請求頭中包含可以聯想到攻擊的值的請求

比如，如果你判定攻擊是針對一個特定的URL：/foo.PHP，我們就可以屏蔽到這個頁面的請求：

location/foo.php{
denyall;
}

或者你判定攻擊請求的User-Agent中包含foo或bar，我們也可以屏蔽這些請求：

location/{
if($http_user_agent~*foo|bar){
return403;
}
...
}

http_name變數引用一個請求頭，上述例子中是User-Agent頭。可以針對其他的http頭使用類似的方法來識別攻擊。

限制到後端伺服器的連接數

一個Nginx、Nginx Plus實例可以處理比後端伺服器多的多的並發請求。在Nginx Plus中，你可以限制到每一個後端伺服器的連接數，比如可以設置Nginx Plus與website upstream中的每個後端伺服器建立的連接數不得超過200個：

upstreamwebsite{
server192.168.100.1:80max_conns=200;
server192.168.100.2:80max_conns=200;
queue10timeout=30s;
}

`max_conns`參數可以針對每一個後端伺服器設置Nginx Plus可以與之建立的最大連接數。`queue`命令設置了當每個後端伺服器都達到最大連接數後的隊列大小，`timeout`參數指定了請求在隊列中的保留時間。

處理特定類型的攻擊

有一種攻擊是發送包含特別大的值的請求頭，引起伺服器端緩沖區溢出。Nginx、Nginx Plus針對這種攻擊類型的防禦，可以參考[Using NGINX and NGINX Plus to Protect Against CVE-2015-1635](http://nginx.com/blog/nginx-protect-cve-2015-1635/?_ga=1.14368116.2137319792.1439284699)

優化Nginx性能

DDOS攻擊通常會帶來高的負載壓力，可以通過一些調優參數，提高Nginx、Nginx Plus處理性能，硬抗DDOS攻擊，詳細參考：[Tuning NGINX for Performance](http://nginx.com/blog/tuning-nginx/?_ga=1.48422373.2137319792.1439284699)

識別DDOS攻擊

到目前為止，我們都是集中在如何是用Nginx、Nginx Plus來減輕DDOS攻擊帶來的影響。如何才能讓Nginx、Nginx Plus幫助我們識別DDOS攻擊呢？`Nginx Plus Status mole`提供了到後端伺服器流量的詳細統計，可以用來識別異常的流量。Nginx Plus提供一個當前服務狀態的儀表盤頁面，同時也可以在自定義系統或其他第三方系統中通過API的方式獲取這些統計信息，並根據歷史趨勢分析識別非正常的流量進而發出告警。

總結

Nginx和Nginx Plus可以作為抵禦DDOS攻擊的一個有力手段，而且Nginx Plus中提供了一些附加的特性來更好的抵禦DDOS攻擊並且當攻擊發生時及時的識別到，另外，你還可以第三方安全防禦來防DDOS，比如：知道創宇抗D保，既可以防DDOS，也能防CC，效果也不錯

❹ Nginx伺服器錯誤是什麼原因

Nginx伺服器錯誤一般有以下幾點原因：

1、請求的header過大。nginx默認的header長度上限是4k，如果超過了這個值,nginx會直接返回400錯誤.

解決方法：配置nginx.conf相關設置。可以通過以下2個參數來調整header上限：

client_header_buffer_size 16k；large_client_header_buffers 4 16k。

2、上傳文件過程中出現錯誤。這時瀏覽器顯示「413 Request Entity Too Large」。這是因為沒有設置client_max_body_size，這個參數默認只是1M，也就是說發布的文章內容大小不能超過1M。

解決方法：增加如下兩行到nginx.conf的http{}段， 增大nginx上傳文件大小限制：設置允許發布內容為8M：client_max_body_size 8M；client_body_buffer_size 128k。

另外如果運行的是php，那麼還要檢查php.ini，這個大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，這樣就不會因為提交數據大小不一致出現的錯誤：post_max_size = 8M；upload_max_filesize = 6M。

修改完配置後，別忘記重新載入。

3、客戶端在為等到伺服器相應返回前就關閉了客戶端描述符。一般出現在客戶端設置超時後，伺服器主動關閉。

解決方法：根據實際Nginx後端伺服器的處理時間修改客戶端超時時間。

4、腳本錯誤（php語法錯誤、lua語法錯誤）。

解決方法：查看nginx_err_log php_err_log。

5、訪問量過大，系統資源限制，不能打開過多文件。 磁碟空間不足。（access log開啟可能導致磁碟滿溢，伺服器主動關閉）。

解決方法：修改/etc/sysctl.conf文件，並使用下面的命令確認： #sysctl -p。要使 limits.conf 文件配置生效，必須要確保 pam_limits.so 文件被加入到啟動文件中。

6、後端服務無法處理，業務中斷。

解決方法：從後端日誌獲取錯誤原因，解決後端伺服器問題。

7、後端伺服器在超時時間內，未響應Nginx代理請求。

解決方法：根據後端伺服器實際處理情況，調正後端請求超時時間。

8、網站頁面緩存過大。

解決方法：配置nginx.conf相關設置：fastcgi_buffers 8 128k；send_timeout 60。

❺ nginx網站502問題怎麼排查

502一般是後端的服務掛了
例如nginx後端轉發請求到tomcat，但tomcat進程意外終止了，nginx就會報正巧502錯誤
檢舉談鍵查後端服務侍缺器是否可以正常工作

❻ nginx容易出現哪些問題

404 bad request

一般原因:請求的Header過大

解決方法：配置nginx.conf相關設置

• client_header_buffer_size 16k;

• large_client_header_buffers 4 64k;

• client_max_body_size 10m;

配置php.ini如下(必須和nginx.conf配置一致)




• post_max_size=10M

• upload_max_filesize=2M

499 Client Closed Request

一般原因:客戶端在為等到伺服器相應返回前就關閉了客戶端描述符。一般出現在客戶端設置超時後，主動關閉socket.

解決方法：根嫌散據實際Nginx後端伺服器的處理時間修改客戶端超時時間。

500 Internal Server Rrror

一般原因：腳本錯誤，（php語法錯誤、lua語法錯誤）

訪問量過大，系統資源限制，不能打開過多文件


磁碟空間不足。（access log開啟可能導致磁碟滿溢 關閉）

解決方法：語法錯誤查看nginx_err_log php_err_log。

文件訪問量：

1.修改nginx配置文件




• worker_rlimit_nofile 65535;

2.修改/etc/security/limits.conf




• * soft nofile 65535

• * hard nofile 65535

502 Bad Gateway、503 Serveice Unavailable

一般原因:後端服務無法處理，芹孝氏業務中斷。

解決方法：從後端日誌獲取錯誤原因，解決後端伺服器問慎凱題。

504 Gateway Timeout

一般原因:後端伺服器在超時時間內，未響應Nginx代理請求

解決方法：根據後端伺服器實際處理情況，調正後端請求超時時間。

❼ nginx不得不說的參數之 為什麼nginx error

nginx不得不說的參數之 proxy_intercept_errors與fastcgi_intercept_errors
為什麼我的error_page 配置沒有生效，沒有正常跳轉？我也遇到過這個問題，所以這才促使我對proxy_intercept_errors與fastcgi_intercept_errors這兩個參數做了詳細的了解。

由於我們商戶和點評信息相關web應用是給用戶做消費決策的商戶和相關點評等信息，瀏覽功能一般比互動功能要重要一些，但是由於一些內部出錯可能會導致整個應用出現異常，導致用戶無法瀏覽到商戶的相關信息。

為了提升商戶頁面的可用性，我們通過靜態抓取現有頁面保存在靜態文件伺服器上，在應用伺服器nginx上配置相關規則，當應用出現異常的時候就會將用戶的請求轉發到降級用途的靜態文件伺服器上。
在整個規則配置過程中，發現了一些問題，就是在nginx上配置了相關error_page的跳轉頁面，發現後端應用異常的時候，預期中的nginx跳轉規則並沒有生效。
error_page 500 501 502 503 504 @shopstatic;

location @shopstatic {
access_log logs/shop-web.access.log maintry;
proxy_pass url;
}
我們業務應用使用的是nginx+java容信激器的結構形式，nginx做反向代理和日誌記錄，當用戶請求到達伺服器時，先判斷nginx配置的根目錄下是否存在對應的靜態文件，不存在的時候轉發到後端的java容器server。我們滑敗襪在nginx中配置了error_page 異常跳轉的規則，預期當後端java容器出現異常錯枯姿誤的時候，對應的請求會被nginx轉發到我們靜態降級的服務，但是實際上，當後端java容器出現異常或者過載的時候，nginx是直接吐出java容器後端的異常信息。

由於第一次配置這樣奇特的nginx規則，搞不清楚是什麼原因，在google上搜了半晌，由於搞不清楚狀況，也描述不清楚，所以一直沒有什麼收獲，後來終於用關鍵詞error_page proxy搜索搞定了，一個老外回答了類似的問題，給了proxy_intercept_errors on；這個配置，自己試了下還真的ok了。

發現學會如何提問，才是自己要努力的方向。

nginx proxy 啟用自定義錯誤頁面：

語法:proxy_intercept_errors on | off;
默認值:
proxy_intercept_errors off;
上下文:http, server, location
當被代理的後端伺服器的響應狀態碼大於等於300時，決定是否直接將響應發送給客戶端，亦或將響應轉發給nginx由error_page指令來處理。

❽ nginx 是怎麼對 後端伺服器 做健康檢查的

apache 相對於nginx 的優點：
rewrite ，比nginx 的rewrite 強大動態頁面，nginx處理動態請求是雞銀清肋，一般動態請求要猛輪apache去做，nginx只適合靜態鋒知前和反向。
模塊超多，基本想到的都可以找到少bug ，nginx 的bug 相對較多超穩定！

❾ 從剛剛「簡書」平台的短暫異常，談Nginx An error occurred報錯～

An error occurred.

Sorry, the page you are looking for is currently unavailable.

Please try again later.

If you are the system administrator of this resource then you should check theerror log for details.

Faithfully yours, nginx.

如上，剛老徐正打算上平台，寫文章，出現如上錯誤，應該持續了幾分鍾～不知道有多少用戶有感知，平台響應還不錯，幾分鍾後已恢復正常～

一般nginx的此類報錯，原因如下（當然，老徐對nginx了解不深，如下都是一些可能原因）

出現問題，首先是去分析nginx的日誌，得到一些線索～

可能的常見原因：

／ 1 ／

很明顯這是一個nginx的錯誤，查看nginx.conf的文件過程中分析可能是以下的問題，在nginx.xml中有如下配置：

標紅的部分是很大的嫌疑，恰好應用中在提交數據的一瞬間和伺服器有多次交互，這些交互都要過nginx。再加上用戶IP來做key，假如多個用戶訪問在網上的最後一跳是同一個路由器，很顯然會被伺服器當成是一台電腦，從而出現判斷錯誤。那麼又一個新問題來了，出現503錯誤後為啥返回的是那個錯誤頁面呢？

帶著這個問題在nginx.conf中又發現了一段配置，如下圖：

這個配置的意思是當出現500、502、503、504的錯誤時返回50x.html頁面，這個頁面在nginx安裝目錄的html文件夾下，內容如下：

這個頁面經過瀏覽器解析就是開頭第一幅圖的樣子。

分析到這里，就大概估計出原因了，把之前的rate值該大一點即可。那麼到底改多大？這個要根據不同的業務而定，甚至去掉這個配置，所以這個是個經驗值，通過多次試驗可以得到一個相對於應用合理的值，這里就不說了。

實際nginx出現這個錯誤原因應該有很多，這里提供一種可能原因，以供網友參考。

／ 2 ／

日誌記錄中HTTP狀態碼出現499錯誤有多種情況，我遇到的一種情況是nginx反代到一個永遠打不開的後端，就這樣了，日誌狀態記錄是499、發送位元組數是0。

老是有用戶反映網站系統時好時壞，因為線上的產品很長時間沒有修改，所以前端程序的問題基本上可以排除，於是就想著是Get方式調用的介面不穩定，問了相關人員，說沒有問題，為了拿到確切證據，於是我問相關人員要了nginx伺服器的日誌文件（awstats日誌），分析後發現日誌中很多錯誤碼為499的錯誤，約占整個日誌文件的1%，而它只佔全部報錯的70%左右（全部報錯見下圖），那麼所有報錯加起來就要超過1%了，這個量還是特別大的。

499錯誤是什麼？讓我們看看NGINX的源碼中的定義：

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */

ngx_string(ngx_http_error_496_page), /* 496, https no certificate */

ngx_string(ngx_http_error_497_page), /* 497, http to https */

ngx_string(ngx_http_error_404_page), /* 498, canceled */

ngx_null_string,                    /* 499, client has closed connection */

可以看到，499對應的是 「client has closed connection」。這很有可能是因為伺服器端處理的時間過長，客戶端「不耐煩」了。

Nginx 499錯誤的原因及解決方法

打開Nginx的access.log發現在最後一次的提交是出現了HTTP1.1 499 0 -這樣的錯誤，在網路搜索nginx 499錯誤，結果都是說客戶端主動斷開了連接。

但經過我的測試這顯然不是客戶端的問題，因為使用埠+IP直接訪問後端伺服器不存在此問題，後來測試nginx發現如果兩次提交post過快就會出現499的情況，看來是nginx認為是不安全的連接，主動拒絕了客戶端的連接.

但搜索相關問題一直找不到解決方法，最後終於在google上搜索到一英文論壇上有關於此錯誤的解決方法：

proxy_ignore_client_abort on;

Don』t know if this is safe.

就是說要配置參數 proxy_ignore_client_abort on;

表示代理服務端不要主要主動關閉客戶端連接。

以此配置重啟nginx,問題果然得到解決。只是安全方面稍有欠缺，但比總是出現找不到伺服器好多了。

還有一種原因是 我後來測試發現 確實是客戶端關閉了連接,或者說連接超時 ,無論你設置多少超時時間多沒用 原來是php進程不夠用了 改善一下php進程數 問題解決

／ 3 ／

今天網站突然出現如下錯誤：

The page you are looking for is temporarily unavailable.Please try again later.

很奇怪，我對伺服器端的技術不是很熟悉，於是查詢了下google，在https://wiki.archlinux.org/index.php/Nginx

上面的解決方法：

Error: The page you are looking for is temporarily unavailable. Please try again later.

This is because the FastCGI server has not been started.

如何解決呢？

剛開始我懷疑是不是nginx掛了，我首先通過 ps aux | grep nginx ，結果出現：

root      3769  0.0  0.0   5760   692 ?        Ss   Apr21   0:00 nginx: master process /usr/local/nginx/sbin/nginx

www       3770  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3771  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3772  0.0  0.1  18712 14276 ?        S    Apr21   0:03 nginx: worker process

www       3774  0.0  0.1  18680 14248 ?        S    Apr21   0:03 nginx: worker process

www       3776  0.0  0.1  18712 14240 ?        S    Apr21   0:03 nginx: worker process

www       3777  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3778  0.0  0.1  18680 14232 ?        S    Apr21   0:02 nginx: worker process

root     24068  0.0  0.0   5196   756 pts/1    S+   14:33   0:00 grep nginx

可見nginx是正常的，本來打算重啟nginx的：

/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf的，

突然覺得有沒有其他方法，有同事提示先在一個目錄下運行下test.html和test.php，結果html可以運行，php無法運行。

證實是php沒有啟動，我剛才也檢測過php的進程，的確是沒有php進程，這台伺服器我不熟悉，同事幫忙查看了下

cd /etc/init.d，就是web管理員經常看的地方，是隨著系統自動啟動的服務，程序等。可以看看：

http://blog.wgzhao.com/2008/12/27/talk-about-rc-local.html的《 說說？ /etc/rc.d/rc.local 》

找到：

/usr/local/php/sbin/php-fpm start，首先什麼是php-fpm呢？

就是FastCGI Process Manager，是一種可選的PHP FastGCI執行模式，有一點很有特點的應用，尤其是一個繁忙的網站中：

(1)可適應的進行再生(NEW!)

(2)基本的統計功能（Apache's mod_status)

(3)高級進程管理功能，能夠優雅的停止/開始

(4)能夠使用不同的工作用戶和不同的php.ini

(5)輸入，輸出日誌記錄...

開啟後，一切恢復正常！自己的伺服器端技術還是有很多地方使用的不夠。需要多學習使用！

總結：

1、試檢查一下nginx.conf的設置，是不是有limit的設置，比如limit_zone、limit_conn，這些參數也是有影響的。

2、檢查一下防火牆，是不是有相關的設置限制。

3、檢查一下nginx.conf的設置，看看有沒有valid_referers none blocked的防鏈設置。

4、看下訪問靜態文件是否正常，錯誤排除～

OK，如上只是一些猜測～

具體原因，具體分析～

越來越多的系統，採用nginx，大家有必要了解些nginx的知識～

❿ 如何判斷nginx upstream比較忙

可以在server下添加

add_header backendIP $upstream_addr;
add_header backendCode $upstream_status;

這樣可納宏在瀏覽器的響應頭中看到backendIP欄位，為後端訪問的IP地址
backendCode欄位，為後端服虧陪務器返回的HTTP狀態碼

可洞空冊以用來判斷哪個伺服器接受了請求，並是否正常