nginx性能配置參數說明：

時間 2019-12-07

標籤 nginx 性能配置參數說明欄目 Nginx 简体版

原文原文鏈接

nginx的配置：main配置段說明
一.正常運行的必備配置：
一、user username [groupname];
指定運行worker進程的用戶和組javascript

二、pid /path/to/pidfile_name;
指定nginxf進程的pid文件路徑。php

三、worker_rlimit_nofile #;
指定一個worker進程所可以打開的最大文件句柄數（最大文件描述符數量）；css

若是沒設置的話，這個值爲操做系統的限制。設置後你的操做系統和Nginx能夠處理比「ulimit -a」更多的文件，因此把這個值設高，這樣nginx就不會有「too many open files」問題。html

四、worker_rlimit_sigpending #;java

設定每一個用戶可以發往worker進程的信號的數量；node

五、server_tokens python

並不會讓nginx執行的速度更快，但它能夠關閉在錯誤頁面中的nginx版本數字，這樣對於安全性是有好處的。nginx

二.優化性能相關的配置：
一、worker_processes #;
worker進程的個數；一般其數值應該爲CPU的物理核心數減1；（高版本可使用」auto「參數）git

二、worker_cpu_affinity cpumask ...;
0000
0001
0010
0100
1000
綁定啓動的worker進程到指定的CPU上
worker_processes 6;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000;
說明：CPU個數<進程數，服務器須要發生進程切換；nginx工做在一個進程響應多個請求的模型下，多個worker進程在沒有請求的狀況下工做在睡眠態，
只有有請求到達後內核調用worker進程到CPU中執行，這樣就會形成上下文切換和進程會在CPU上製造緩存，執行完成後worker進程會退出CPU進入睡眠態，
緩存失效，然後來進入的worker進程會從新生成緩存，形成服務器性能下降。
能夠在系統啓動時將除了系統啓動的其餘CPU隔離出來，綁定worker進程到指定CPU上，CPU的使用權就是特定的worker進程，能夠大大提升服務器性能。

三、ssl_engine device;
在存在ssl硬件加速器的服務器上，指定所使用的ssl硬件加速設備；web

四、timer_resolution t;
時間解析度，值大些好，越小越精緻，可是消耗大，
每次內核事件調用返回時，都會使用gettimeofday()來更新nginx緩存時鐘；timer_resolution用於定義每隔多久纔會由gettimeofday()更新一次緩存時鐘；x86-64系統上，gettimeofday()代價已經很小，能夠忽略此配置；

五、worker_priority nice;
-20,19之間的值；讓worker以指定nice值工做,-20~19nice值越低就會優先獲取CPU資源； ps axo comm,pid ,nice

三.事件相關的配置
一、accept_mutex [on|off]
是否打開Ningx的負載均衡鎖；此鎖可以讓多個worker進輪流地、序列化地與新的客戶端創建鏈接；而一般當一個worker進程的負載達到其上限的7/8，master就儘量再也不將請求調度此worker；

二、lock_file /path/to/lock_file;
lock文件(accept_mutex指的負載均衡鎖)

三、accept_mutex_delay #ms;
accept鎖模式中，一個worker進程爲取得accept鎖的等待時長；若是某worker進程在某次試圖取得鎖時失敗了，至少要等待#ms才能再一次請求鎖；

四、multi_accept on|off;
是否容許一次性地響應多個用戶請求；默認爲Off;

五、use [epoll|rtsig|select|poll];
定義使用的事件模型，建議讓nginx自動選擇；

六、worker_connections #;
每一個worker可以併發響應最大請求數；

四.用於調試、定位問題: 只調試nginx時使用
一、daemon on|off;
是否讓ningx運行後臺（守護進程的方式啓動nginx）；默認爲on，調試時能夠設置爲off，使得全部信息去接輸出控制檯；

二、master_process on|off
是否以master/worker模式運行nginx；默認爲on；調試時可設置off以方便追蹤；

三、error_log /path/to/error_log level;

級別以notice,debug,info,warn,error,crit模式，debug輸出最多，crir輸出最少

錯誤日誌文件及其級別；默認爲error級別；調試時可使用debug級別，但要求在編譯時必須使用--with-debug啓用debug功能；

五.網絡鏈接相關的設置：
一、keepalive_timeout time;
保持鏈接的超時時長；默認爲75秒；
參數的第一個值指定了客戶端與服務器長鏈接的超時時間，超過這個時間，服務器將關閉鏈接。參數的第二個值（可選）指定了應答頭中Keep-Alive: timeout=time的time值，這個值可使一些瀏覽器知道何時關閉鏈接，以便服務器不用重複關閉，
若是不指定這個參數，nginx不會在應答頭中發送Keep-Alive信息。（但這並非指怎樣將一個鏈接「Keep-Alive」）參數的這兩個值能夠不相同。

在http早期，每一個http請求都要求打開一個tpc socket鏈接，而且使用一次以後就斷開這個tcp鏈接。使用keep-alive能夠改善這種狀態，即在一次TCP鏈接中能夠持續發送多份數據而不會斷開鏈接。經過使用keep-alive機制，能夠減小tcp鏈接創建次數，也意味着能夠減小TIME_WAIT狀態鏈接，以此提升性能和提升httpd服務器的吞吐率(更少的tcp鏈接意味着更少的系統內核調用,socket的accept()和close()調用)。可是，keep-alive並非免費的午飯,長時間的tcp鏈接容易致使系統資源無效佔用。配置不當的keep-alive，有時比重複利用鏈接帶來的損失還更大。因此，正確地設置keep-alive timeout時間很是重要。

二、keepalive_requests n;默認爲100
在一次長鏈接上容許承載的最大請求數；

三、keepalive_disable [msie6 | safari | none ]
對指定的瀏覽器禁止使用長鏈接；

四、tcp_nodelay on|off
對keepalive鏈接是否使用TCP_NODELAY選項；
tcp_nopush on;
http請求包體的最大值；經常使用於限定客戶所可以請求的最大包體；根據請求首部中的Content-Length來檢測，以免無用的傳輸；

五、client_header_timeout time;
讀取http請求首部的超時時長；

指令指定讀取客戶端請求頭標題的超時時間。這裏的超時是指一個請求頭沒有進入讀取步驟，若是鏈接超過這個時間而客戶端沒有任何響應，Nginx將返回一個」Request time out」 (408)錯誤。

六、client_body_timeout time;
讀取http請求包體的超時時長；

指令指定讀取請求實體的超時時間。這裏的超時是指一個請求實體沒有進入讀取步驟，若是鏈接超過這個時間而客戶端沒有任何響應，Nginx將返回一個」Request time out」 (408)錯誤。

七、send_timeout time;
發送響應報文的超時時長；默認爲60秒

指令指定了發送給客戶端應答後的超時時間，Timeout是指沒有進入完整established狀態，只完成了兩次握手，若是超過這個時間客戶端沒有任何響應，nginx將關閉鏈接。

八、reset_timeout_connection

告訴nginx關閉不響應的客戶端鏈接。這將會釋放那個客戶端所佔有的內存空間。

六.對客戶端請求的限制：
一、limit_except method ... { ... }
指定對範圍以外的其它方法的訪問控制；

limit_except GET {
allow 172.16.0.0/16;
deny all;
}

二、client_max_body_size SIZE;
http請求包體的最大值；經常使用於限定客戶所可以請求的最大包體；根據請求首部中的Content-Length來檢測，以免無用的傳輸；

三、limit_rate speed;
限制客戶端每秒鐘傳輸的字節數；默認爲0，表示沒有限制；

四、limit_rate_after time;
nginx向客戶發送響應報文時，若是時長超出了此處指定的時長，則後續的發送過程開始限速；

四、limit_conn perip 200;

limit_conn限制每個IP併發鏈接數是２００；

5 、limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
　　limit_req zone=one burst=3 nodelay;

用於按key限制請求的處理速率，特別適用於限制單個IP的請求處理速率。
本例中，設置了10m字節的共享空間來存儲key，即$binary_remote_addr，共享空間的名字是one，限制請求的處理速率爲一秒一個。
下面limit_req中指定了burst參數爲5，表示最多容許五個請求排隊，超過的就直接返回503狀態了。
我們限制的請求處理速率是一秒一個，burst參數爲５。意思就是在某一秒內，容許有１個正常請求＋５個excessive請求被處理，多的就要被503了。
若是沒有nodelay參數，那麼最多burst個excessive請求則按rate參數規定的速率延遲發送給後端。
若是有nodelay參數，則表示這些excessive請求會立馬發送給後端。因此這種狀況下，後端請求到達的速率可能不止rate這麼多。
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req zone=one burst=3 nodelay;

測試參考地址：http://mp.weixin.qq.com/s?__biz=MzI5ODExMjk4Ng==&mid=402812915&idx=1&sn=e8fca3a91539c152398c6fb01c9dcef6&mpshare=1&scene=1&srcid=100834dW5nyrd7PKiRgnxYk2#rd

六、limit_conn_zone $binary_remote_addr zone=perip:10M
　 limit_conn perip 200;

一個是限制併發鏈接
要限制鏈接，必須先有一個容器對鏈接進行計數，"zone=" 給它一個名字，能夠隨便叫，這個名字要跟下面的 limit_conn 一致
$binary_remote_addr = 用二進制來儲存客戶端的地址，1m 能夠儲存 32000 個併發會話
limit_conn_zone $binary_remote_addr zone=perip:10M
limit_conn perip 200;

測試參考地址：http://storysky.blog.51cto.com/628458/642970/

七.文件操做的優化：
一、sendfile on|off
是否啓用sendfile功能；可讓sendfile()發揮做用。sendfile()能夠在磁盤和TCP socket之間互相拷貝數據(或任意兩個文件描述符)。Pre-sendfile是傳送數據以前在用戶空間申請數據緩衝區。

以後用read()將數據從文件拷貝到這個緩衝區，write()將緩衝區數據寫入網絡。sendfile()是當即將數據從磁盤讀到OS緩存。由於這種拷貝是在內核完成的，sendfile()要比組合read()和write()以及打開關閉丟棄緩衝更加有效

二、aio on|off
是否啓用aio(異步IO模式)功能；

、directio size | off
當size大於等於時，是否啓用直接IO模式功能。（直接IO模式表示不在內存中緩存）

三、open_file_cache max=N [inactive=time]|off
是否打開文件緩存功能；
max: 緩存條目的最大值；當滿了之後將根據LRU算法進行置換；
inactive: 某緩存條目在指定時長時沒有被訪問過期，將自動被刪除；默認爲60s;
緩存的信息包括：
文件句柄、文件大小和上次修改時間；
已經打開的目錄結構；
沒有找到或沒有訪問權限的信息；

四、open_file_cache_errors on|off
是否緩存文件找不到或沒有權限訪問等相關信息；

五、open_file_cache_valid time;
多長時間檢查一次緩存中的條目是否超出非活動時長，默認爲60s;

六、open_file_cache_min_use #;
在inactive指定的時長內被訪問超此處指定的次數地，纔不會被刪除；

八.對客戶端請求的特殊處理：
一、ignore_invalid_headers on|off
是否忽略不合法的http首部；默認爲on; off意味着請求首部中出現不合規的首部將拒絕響應；只能用於server和http;

二、log_not_found on|off
是否將文件找不到的信息也記錄進錯誤日誌中；

三、resolver address;
指定nginx使用的dns服務器地址；

四、resover_timeout time;
指定DNS解析超時時長，默認爲30s;

五、server_tokens on|off;
是否在錯誤頁面中顯示nginx的版本號；

九.nginx代理設置優化：

proxy_pass http://127.0.0.1:8080; #來自jsp請求交給tomcat處理

proxy_redirect off;

proxy_set_header Host $host; #後端的Web服務器能夠經過X-Forwarded-For獲取用戶真實IP

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_connect_timeout 90; #nginx跟後端服務器鏈接超時時間(代理鏈接超時)

proxy_read_timeout 90; #鏈接成功後，後端服務器響應時間(代理接收超時)

proxy_buffer_size 4k; #設置代理服務器（nginx）保存用戶頭信息的緩衝區大小

proxy_buffers 6 32k; #proxy_buffers緩衝區，網頁平均在32k如下的話，這樣設置

proxy_busy_buffers_size 64k;#高負荷下緩衝大小（proxy_buffers*2）

proxy_temp_file_write_size 64k; #設定緩存文件夾大小，大於這個值，將從upstream服務器傳

十.內存及磁盤資源分配：
一、client_body_in_file_only on|clean|off
HTTP的包體是否存儲在磁盤文件中；非off表示存儲，即便包體大小爲0也會建立一個磁盤文件；on表示請求結束後包體文件不會被刪除，clean表示會被刪除；

二、client_body_in_single_buffer on|off;
HTTP的包體是否存儲在內存buffer當中；默認爲off；

三、cleint_body_buffer_size size;默認爲16K
nginx接收HTTP包體的內存緩衝區大小；（超出將存儲到硬盤上。使用client_body_temp_path）

這個指令能夠指定鏈接請求實體的緩衝區大小。若是鏈接請求超過緩存區指定的值，那麼這些請求實體的總體或部分將嘗試寫入一個臨時文件。

四、client_body_temp_path dir-path [level1 [level2 [level3]]];
HTTP包體存放的臨時目錄；
client_body_temp_path /var/tmp/client/ 1 2

五、client_header_buffer_size size;
正常狀況下接收用戶請求的http報文header部分時分配的buffer大小；默認爲1k;

指令指定客戶端請求頭部的緩衝區大小。絕大多數狀況下一個請求頭不會大於1k，不過若是有來自於wap客戶端的較大的cookie它可能會大於 1k，Nginx將分配給它一個更大的緩衝區，這個值能夠在large_client_header_buffers裏面設置。

六、large_client_header_buffers number size;
存儲超大Http請求首部的內存buffer大小及個數；

指定客戶端一些比較大的請求頭使用的緩衝區數量和大小。請求字段不能大於一個緩衝區大小，若是客戶端發送一個比較大的頭，nginx將返回」Request URI too large」 (414)一樣，請求的頭部最長字段不能大於一個緩衝區，不然服務器將返回」Bad request」 (400)。
緩衝區只在需求時分開。默認一個緩衝區大小爲操做系統中分頁文件大小，一般是4k或8k，若是一個鏈接請求最終將狀態轉換爲keep- alive，它所佔用的緩衝區將被釋放。

六、client_max_body_size 200M;

http請求包體的最大值；經常使用於限定客戶所可以請求的最大包體；根據請求首部中的Content-Length來檢測，以免無用的傳輸；
指令指定容許客戶端鏈接的最大請求實體大小，它出如今請求頭部的Content-Length字段。若是請求大於指定的值，客戶端將收到一個」Request Entity Too Large」 (413)錯誤。記住，瀏覽器並不知道怎樣顯示這個錯誤。

七、connection_pool_size size;
nginx對於每一個創建成功的tcp鏈接都會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲256；

八、request_pool_size size;
nginx在處理每一個http請求時會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲4k;

十一壓縮說明

gzip 是告訴nginx採用gzip壓縮的形式發送數據。這將會減小咱們發送的數據量。

gzip_disable 爲指定的客戶端禁用gzip功能。咱們設置成IE6或者更低版本以使咱們的方案可以普遍兼容。

gzip_http_version 1.1;

gzip_static 告訴nginx在壓縮資源以前，先查找是否有預先gzip處理過的資源。這要求你預先壓縮你的文件（在這個例子中被註釋掉了），從而容許你使用最高壓縮比，這樣nginx就不用再壓縮這些文件了

gzip_min_length 設置對數據啓用壓縮的最少字節數。若是一個請求小於1000字節，咱們最好不要壓縮它，由於壓縮這些小的數據會下降處理此請求的全部進程的速度。

gzip_comp_level 設置數據的壓縮等級。這個等級能夠是1-9之間的任意數值，9是最慢可是壓縮比最大的。咱們設置爲4，這是一個比較折中的設置。（壓縮級別，1壓縮比最小處理速度最快，9壓縮比最大但處理最慢，同時也最消耗CPU,通常設置爲3就能夠了）

gzip_buffers 4 8k; （設置系統獲取幾個單位的緩存用於存儲gzip的壓縮結果數據流）

gzip_type 設置須要壓縮的數據格式。上面例子中已經有一些了，你也能夠再添加更多的格式。 text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Nginx做爲反向代理的時候啓用，開啓或者關閉後端服務器返回的結果，匹配的前提是後端服務器必需要返回包含」Via」的 header頭。

　　off – 關閉全部的代理結果數據的壓縮
　　expired – 啓用壓縮，若是header頭中包含「Expires」頭信息
　　no-cache – 啓用壓縮，若是header頭中包含「Cache-Control:no-cache」頭信息
　　no-store – 啓用壓縮，若是header頭中包含「Cache-Control:no-store」頭信息
　　private – 啓用壓縮，若是header頭中包含「Cache-Control:private」頭信息
　　no_last_modified – 啓用壓縮,若是header頭中不包含「Last-Modified」頭信息
　　no_etag – 啓用壓縮 ,若是header頭中不包含「ETag」頭信息
　　auth – 啓用壓縮 , 若是header頭中包含「Authorization」頭信息
　　any – 無條件啓用壓縮

十二 locaton 匹配說明

一、利用valid_referers指令防盜鏈：

HTTP Referer是Header的一部分，當瀏覽器向Web服務器發送請求的時候，通常會帶上Referer，告訴服務器我是從哪一個頁面連接過來的，服務器藉此能夠得到一些信息用於處理，

例如防止未經容許的網站盜鏈圖片、文件等。所以HTTP Referer頭信息是能夠經過程序來假裝生成的，因此經過Referer信息防盜鏈並不是100%可靠，可是，它可以限制大部分的盜鏈

狀況。

none:表示無Referer值的狀況。
blocked:表示Referer值被防火牆進行假裝。
server_names:表示一個或多個主機名稱。從Nginx 0.5.33版本開始，server_names中可使用通配符"*"號。

location ~* \.(gif|jpg|png|swf|flv|css|js|flv|swf|jpeg)$ {
valid_referers none blocked *.zjol.com.cn *.zzhz.com.cn *.zjtdw.com; 定義合規的引用
if ($invalid_referer) { return 403; } 拒毫不合規的引用

二、nginx和php-fpm同樣內建了一個狀態頁，對於想了解nginx的狀態以及監控nginx很是有幫助。查看http://127.0.0.1/ngx_status

active connections – 活躍的鏈接數量
server accepts handled requests — 總共處理了多少個鏈接 , 成功建立多少次握手, 總共處理了多少個請求
reading — 讀取客戶端的鏈接數.
writing — 響應數據到客戶端的數量
waiting — 開啓 keep-alive 的狀況下,這個值等於 active – (reading+writing), 意思就是 Nginx 已經處理完正在等候下一次請求指令的駐留鏈接.

location ~ ^/NginxStatus/{
stub_status on;
access_log off;

allow 127.0.0.1;

}

三、ginx.conf 配置中有個漏洞，那就是沒有配置哪些目錄是不容許直接訪問的，在傳統tomcat做爲服務器的時候，tomcat自己的機制就禁止直接訪問WEB-INF下的內容，

可是在nginx中，因爲配置了部份內容直接從nginx轉發出去，這就致使了WEB-INF目錄實際上可能會被暴露出去，一旦暴漏了，那麼系統架構，源代碼，數據庫配置文件，

系統配置文件等內容將一併泄露，這對於商業項目來說會是致命的安全隱患，再次提醒本身以及相關人士，必定要配置不容許訪問的目錄。
location ~ ^/(WEB-INF|META-INF)/{
deny all;
}

四、封殺特定的url特定的文件擴展名，好比.bak

location ~* \.(bak|save|sh|sql|mdb|svn|git|old|php|zip|exe|rar|asp|aspx)$ {
return 405;
}

五、
location ~ /\.ht {
deny all;
}

五、你能夠對指定的目錄設置訪問權限。全部的網站目錄應該一一的配置，只容許必須的目錄訪問權限。你能夠經過IP地址來限制訪問目錄/docs/:

location /docs/ {

deny 192.168.1.1;

allow 192.168.1.0/24;｝

十三其它安全加固說明

一、封殺各類user-agent，user-agent 也即瀏覽器標識，每一個正常的web請求都包含用戶的瀏覽器信息，除非通過假裝，惡意掃描工具通常都會在user-agent裏留下某些特徵字眼，

好比scan，nmap等。咱們能夠用正則匹配這些字眼，從而達到過濾的目的

if ($http_user_agent ~* "java|python|perl|ruby|curl|bash|echo|uname|base64|decode|md5sum|select|concat|httprequest|httpclient|nmap|scan" ) {
return 403;
}

if ($http_user_agent ~* "" ) { return 403; }

阻止Soso和有道的機器人：

if ($http_user_agent ~* Sosospider|YodaoBot) {return 403;

二、封殺特定的http方法和行爲

if ($request_method !~ ^(GET|POST|HEAD)$ ) {
return 405;
}
if ($http_range ~ "\d{9,}") {
return 444;
}

三、強制網站使用域名訪問，能夠逃過IP掃描，
if ( $host !~* 'abc.com' ) { return 403;}

四、強制要求referer

if ($http_referer = "" ) ｛ return 403; ｝