nginx 499錯誤處理及nginx的配置參數小結

更新時間：2024年09月19日 09:22:31 作者：我愛看明朝

在項目容器化改造中,修改Nginx超時設置可解決499錯誤,本文就來介紹一下nginx 499錯誤處理及nginx的配置參數小結,感興趣的可以了解一下

背景

近期響應集團降本增效，節(jié)省ci,stg機器，我們項目開始容器化，在改造過程中，鏈路的訪問發(fā)生了變化，導致出現了499，解決方如下

訪問鏈路: 域名—> ELB (內網訪問) —> openrestry （stg環(huán)境，支持自定義lua腳本） —> ELB(提供服務固定ip) —> （容器集群）POd

499處理

nignx報499的原因是服務端響應超時，nginx主動斷開連接。例如：nginx配置默認超時時間為60s，當服務端接口響應為62s才返回結果，那么當60s時，nginx主動斷開連接。
1. 調整如下proxy_xxx_timeout
2. 優(yōu)化接口，提高接口的響應速度

server{
    location / {
        proxy_connect_timeout 200;
        proxy_send_timeout 200;
        proxy_read_timeout 200;
    }
}

proxy_connect_timeout: 控制與后端服務器建立連接的超時時間，單位是秒，默認是60秒。

proxy_read_timeout: 控制等待后端服務器響應的超時時間，單位是秒，默認是60秒。

proxy_send_timeout: 控制發(fā)送請求到后端服務器的超時時間，單位是秒，默認是60秒。

這三個參數都是在使用 nginx 作為反向代理時，用于限制與后端服務器通信的超時時間，從而避免代理服務器被后端服務器的響應阻塞而無法響應客戶端的請求。例如，如果后端服務器出現了異?；蚓W絡故障，會導致響應的延遲或永遠不返回，此時代理服務器會等待超時時間，然后返回錯誤響應。

注意：在使用這些超時設定時，應當考慮應用程序的網絡和運行環(huán)境，以便確定適當的超時時間。超時時間設置過短可能導致請求失敗，而設置過長可能導致前端網站的響應變慢?？梢赃m當根據實際情況調整，并進行測試，以確?？煽啃院托阅堋抵狄膊皇窃酱笤胶?，對于確實響應慢的接口，要進行性能優(yōu)化。

知識擴展: nginx配置參數

server{
    location / {
        proxy_ignore_client_abort  on;
        proxy_connect_timeout 200;
        proxy_send_timeout 200;
        proxy_read_timeout 200;
    }
}

proxy_ignore_client_abort: 用于實現“忽略客戶端終止”功能。默認情況下，“nginx”會將與客戶端的連接請求轉發(fā)到后端服務器，但如果客戶端中途斷開請求服務，則通常會導致到后端的連接被提前關閉。這時，后端程序可能會繼續(xù)執(zhí)行一段時間，但已經無法將響應發(fā)送回代理服務器，因此可能導致代理服務器上的錯誤響應。

proxy_ignore_client_abort: off 默認配置，客戶端斷開連接會中止響應
proxy_ignore_client_abort: on 客戶端斷開連接不會中止響應，代理服務器將忽略客戶端請求終止，并讓后端服務器繼續(xù)響應，直到響應完成。

http:{

    fastcgi_connect_timeout 200;
    fastcgi_send_timeout 200;
    fastcgi_read_timeout 200; 
}

以上參數當你的技術選型里有包含FastCGI,可以考慮開啟上述fastcgi_xx_timeout參數。

如未接觸過，我們來簡單介紹下: FastCGI（Fast Common Gateway Interface）是一種 Web 應用程序的接口協議，它提出了一種新型的方式來處理動態(tài) Web 內容。astCGI 和早期的 CGI 腳本處理方式不同，CGI 腳本在每次請求時都會啟動新的進程，這可能造成性能損失和資源浪費。而 FastCGI 利用了一些進程復用技術，使得每個應用程序可以一直保持在內存中的狀態(tài)，等待下一次請求，大大提高了性能。

Tomcat容器并未內置FastCGI功能，在標準的SpringBoot應用程序中，你需要特別安裝、配置和/或使用第三方 FastCGI 庫或框架來實現與 FastCGI 協議的通信。例如，可以使用 Mod_jk 來實現 Tomcat 與前端 Web 服務器之間的 FastCGI 通信。

http {

    client_max_body_size 500m; //限制客戶端請求體超過配置的值，超過返回413
    client_body_buffer_size 10M; //
    # client_body_temp: /xx // 大于client_body_buffer_size是存儲的磁盤目錄
    keepalive_timeout  65s; //
    client_header_timeout 600s; //
    client_body_timeout  600s;  // 
    proxy_connect_timeout 200s;
    proxy_send_timeout    200s;
    proxy_read_timeout    200s;
    proxy_max_temp_file_size 0;

    limit_req_zone $binary_remote_addr zone=burstLimit:10m rate=40r/s;

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_types text/plain text/css application/json application/x-javascript application/javascript text/javascript appliaction/xml;
    gzip_comp_level 3;
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_vary off;
}

client_max_body_size：限制客戶端請求體超過配置的值，超過返回413 Request Entity Too Large,在http,server,location均可配置。這個參數是針對單個請求體的大小，而不是控制所有請求的綜合大小。

client_body_buffer_size：客戶端請求體數據到內存時緩存區(qū)分配的大小。如果請求的數據小于這個配置直接將數據先在存在內存，如果請求的值大于client_body_buffer_size小client_max_body_size，就會將數據先存儲到臨時文件中，臨時文件默認路徑是/tmp/，也可通過配置client_body_temp指定目錄

client_body_temp: 當請求體大于client_body_buffer_size小于client_max_body_size是，配置這個參數存儲到指定的磁盤路徑，注意這個需要修改權限（chomd），否則會報Permission denied

keepalive_timeout: 當使用http/1.1協議是，可以使用keepalive復用tcp的連接，減少tcp三次握手四次揮手建立網絡連接的時間。keepalive_time的意思是每次請求完畢后保持指定時間的連接，可以避免頻繁創(chuàng)建和關閉連接的過程。默認值是75s，若設置為0，表示禁止keepalive連接

client_header_timeout：客戶端像服務端發(fā)送一個完整的request header的超時時間，默認60s，如果客戶端在指定時間內沒有發(fā)送一個完整的request header，nginx返回http 408(request time out)

client_body_timeout：戶端像服務端發(fā)送一個完整的request body的超時時間, 默認60s，如果客戶端在指定時間內沒有接受到請求體數據,注意不是整個請求提數據傳輸，是在接受到header后到開始傳輸body這個過程的超時時間(官方文檔: The timeout is set only for a period between two successive read operations, not for the transmission of the whole request body If a client does not transmit anything within this time, the request is terminated with the 408 (Request Time-out) error.)， nginx返回http 408(request time out)。

proxy_max_temp_file_size: 緩存到磁盤的文件大小，如果設置為0，則不緩存到磁盤。如果超過了設置的值，則nginx將與proxy的服務器同步的傳遞內容，則不在還緩沖到磁盤

limit_req_zone： nginx限流模塊,$binary_remote_addr表明限制的目標，remote_addr記錄的是ip信息占用7~15個字節(jié)，binary_remote_addr表示壓縮的ip,僅占用4個字節(jié)。zone=name:size分配一個名為name的并且大小為size的內存空間，用來存儲訪問的頻次信息;rate=40r/s表示同一個ip每秒只允許40個請求通過

gzip: on：開啟gzip壓縮靜態(tài)資源, off關閉

gzip_min_length: 1k 配置開啟壓縮的大小，資源大于這個的才壓縮，再小就不要壓縮

gzip_buffers 4: 16k 緩沖，壓縮在內存緩沖幾塊，每塊多大

gzip_types: text/plain text/css application/json application/x-javascript application/javascript text/javascript appliaction/xml; 對那些類型的文件用壓縮

gzip_comp_level: 3; 壓縮級別（[1-9]級別越高，壓的越小，越耗費CPU計算時間）

gzip_disable: “MSIE [1-6].(?!.*SV1)”; 正則匹配什么樣的uri不進行gzip壓縮，此處表示ie6及一下不啟用gzip（因為這些版本不支持）

gzip_vary: off 是否傳輸壓縮標志

nginx增加健康檢查

nginx開源版本沒有自帶負載均衡后端節(jié)點的健康檢查，但是通過額外的nginx_upstream_check_module模塊對后端節(jié)點做健康檢查。

upstream name{
 server 192.168.0.1:80;
 server 192.168.0.2:80;
 check interval=3000 rise=2 fail=5 timeout=1000 type=http;

}

對name的這個upstream負載均衡，每個節(jié)點3s檢測一次，請求2次正常則標記realserver狀態(tài)為up,如果檢測5次都失敗，則標記ralserver狀態(tài)為down，超時時間為1s.

各種負載均衡軟硬件

ELB HAproxy nginx openresty F5 LVS

HaProxy: 一款負載均衡軟件，與nginx角色一樣，支持TCP/HTTP兩種協議的負載均衡，使得其負載均衡功能非常豐富；支持8種左右的負載均衡算法，尤其是在http模式下，有非常多的實用的均衡算法；擁有一個功能出色的監(jiān)控頁面，實時了解系統(tǒng)當前的狀態(tài);功能強大的ACL支持，給用戶極大的方便(ACL access control list訪問控制列表：符合ACL規(guī)則請求由backend指定的后端服務器池執(zhí)行基于ACL規(guī)則的負載均衡，不符合的可以直接中斷響應，也可以交由其他服務器執(zhí)行)；自帶監(jiān)控檢查，nginx需要增加額外的模塊支持健康檢查。缺點是配置文件比較繁瑣，需要一定的技術水平和經驗進行部署和維護。

ELB： AWS提供的云軟件負載均衡服務，實用云端的應用部署，有點易于使用；缺點是定制化自定義有限，對企業(yè)級需要可能不夠全面

F5：負載均衡硬件，性能非常好，每秒處理的請求數可以達到百萬級，采購價格也非常貴十幾萬到百萬人民幣都有，適用于大型企業(yè)流量特別多的情況。

LVS：軟件負載均衡，由阿里的章文嵩博士研發(fā)，是國內最早的自由軟件，配置方便，抗負載能力強；不足：不支持正則處理，不支持做動靜分離，對網絡環(huán)境比較依賴

openresty：對nginx的擴展，自由度高支持實用lua及大量的第三方模塊，方便的搭建能夠處理高并發(fā)，擴展性極高的web應用，網關，從而將nginx從簡單的負載均衡，變成一個強大的網關、通用的web應用平臺。