nginx 499 狀態碼優化


在grafana界面中發現不少499的狀態碼,在網上了解到出現499的原因大體都是說服務端處理時間過長,客戶端主動關閉了連接。

   

既然原因可能是服務端處理時間太長了,看一下upstream_response_time時間可以了解到后端程序處理了多久。

先了解一下什么是upstream_response_time和request_time分別是什么:

  • request_time:服務端從接受客戶端請求的第一個字節到服務端應用程序處理完發送完響應數據的時間,包括請求數據時間、程序響應時間、輸出響應時間
  • upstream_response_time:指nginx向后端如php,tomcat等建立連接開始到到處理完數據關閉連接為止的時間

上面說過,原因可能是服務端處理時間太長了, 那么應該upstream_resopnse_time和request_time時間很長才對。。看下圖,打臉了,upstream_response_time沒有記錄,request_time也非常短,也就是說nginx根本沒有將請求轉發到php處理,而是直接返回了499狀態碼,所以沒有upstream_response_time,並且request_time時間很短,甚至為零。

這么說我這里出現499不是服務端處理時間太長了,而是另有他因。

看來百度是不行的,google查找,原因可能是以下:

  1. 客戶端請求速度過快,觸發了nginx保護機制,直接返回499狀態碼
  2. 第二種情況就是客戶端主動關閉了連接
  3. 證書錯誤

優化方法:

    #size limits for 502 499
    client_max_body_size             50m;
    client_body_buffer_size        256k;
    client_header_timeout     3m;
    client_body_timeout 3m;
    client_body_temp_path /dev/shm/client_body_temp;
    send_timeout             3m;

 proxy_ignore_client_abort on; # 告訴nginx不要主動關閉連接
    proxy_connect_timeout 600;
 proxy_read_timeout 600; proxy_send_timeout 600;
    proxy_buffer_size 32k;
    proxy_buffers 4 64k;
    proxy_busy_buffers_size 128k;
    proxy_temp_file_write_size 512k;

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM