注意:下面的nginx版本是1.10,安裝是在CentOS 7中經過epel源進行安裝的nginx默認配置文件。javascript
# egrep -v "(^$)|(^#)|#" /etc/nginx/nginx.conf user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; include /usr/share/nginx/modules/*.conf; events { worker_connections 1024; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; include /etc/nginx/conf.d/*.conf; server { listen 80 default_server; listen [::]:80 default_server; server_name _; root /usr/share/nginx/html; include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } }
下面是基於上面的配置文件進行初步的優化:php
# cat /etc/nginx/nginx.conf user nginx; worker_processes auto; error_log logs/error.log notice; pid /var/run/nginx.pid; worker_ rlimit_nofile 20480; worker_cpu_affinity auto; events { accept_mutex on; #不建議開啓 use epoll; #默認會使用最有效的方法 multi_accept on; worker_connections 20480; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; sendfile on server_tokens off; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; server { listen 80; server_name localhost; charset utf-8; location / { root html; index index.html; } error_page 500 502 503 504 /50x.html; location = /50x/html { root html; } } }
1.listen:設置nginx監聽的IP地址和端口,若是不指定IP地址則監聽在該機器的全部IP地址上,同時可使用default_server來設置默認虛擬主機, ssl用於限制只能經過ssl鏈接提供服務。
2.server_name:設置虛擬主機的名,其後能夠跟一個或者多個主機名,主機名稱可使用通配符和正則表達式。在匹配時首先是精確匹配,其次是左側通配,而後死右側通配,最後是正則。
3.index:定義默認主頁的格式。
4.root:設置請求的根目錄。
5.error_page:定義錯誤提示頁面。css
server { listen 80 default_server; #listen [::]:80 default_server; server_name www.study.com; access_log /var/log/nginx/study_access.log main; location / { index index.html index.htm; root /data/website/study; } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }
測試html
[root@study html]# tree /data/website/ /data/website/ └── study ├── 404.html ├── 50x.html └── index.html 1 directory, 3 files # curl www.study.com study.com
定義指定位置的替換。路徑值能夠包含變量,$document_root和$ realpath_root除外。若是在使用正則表達式定義的位置內使用別名,則此類正則表達式應包含捕獲,而且別名應引用這些捕獲。
舉例java
location /test { root /data/website; } # curl http://www.a.com/test/ /data/website/test/
root指令:給定的路徑對應於location的「/」這個URL;
/test/index.html --> /data/website/test/index.html
alias指令:給定的路徑對應於location的「/uri/"這個URL;
/test/index.html --> /data/website/index.htmlnode
根據http狀態碼重定向錯誤頁面。
舉例linux
location / { root /data/website; } error_page 404 /404.html # echo 404.page >/data/website/404.html # curl http://www.a.com/aaaaa 404.page # curl http://www.a.com/aaaaa -I HTTP/1.1 404 Not Found Server: nginx/1.10.1 Date: Sat, 11 Feb 2017 16:39:24 GMT Content-Type: text/html Content-Length: 9 Connection: keep-alive ETag: "589f3e1d-9"
嘗試查找第1至第N-1個文件,第一個即爲返回給請求者的資源;若1至N-1文件都不存在,則跳轉至最一個uri(必須不能匹配至當前location,而應該匹配至其它location,不然會致使死循環);
舉例nginx
root /data/website; location /test { try_files /test/1.html /test/2.html /test/3.html @abc; } location @abc { rewrite ^/(.*)$ http://baidu.com; } # ls /data/website/test/ 3.html # curl http://www.a.com/test/1.html 33333
location = / { # 精確匹配 / ,主機名後面不能帶任何字符串 [ configuration A ] } location / { # 由於全部的地址都以 / 開頭,因此這條規則將匹配到全部請求 # 可是正則和最長字符串會優先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 開頭的地址,匹配符合之後,還要繼續往下搜索 # 只有後面的正則表達式沒有匹配到時,這一條纔會採用這一條 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 開頭的地址,匹配符合之後,還要繼續往下搜索 # 只有後面的正則表達式沒有匹配到時,這一條纔會採用這一條 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 開頭的地址,匹配符合之後,中止往下搜索正則,採用這一條。 [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { # 匹配全部以 gif,jpg或jpeg 結尾的請求 # 然而,全部請求 /images/ 下的圖片會被 config D 處理,由於 ^~ 到達不了這一條正則 [ configuration E ] } location /images/ { # 字符匹配到 /images/,繼續往下,會發現 ^~ 存在 [ configuration F ] } location /images/abc { # 最長字符匹配到 /images/abc,繼續往下,會發現 ^~ 存在 # F與G的放置順序是沒有關係的 [ configuration G ] } location ~ /images/abc/ { # 只有去掉 config D 纔有效:先最長匹配 config G 開頭的地址,繼續往下搜索,匹配到這一條正則,採用 [ configuration H ] }
1.=開頭表示精確匹配,如 A 中只匹配根目錄結尾的請求,後面不能帶任何字符串。
2.^~ 開頭表示uri以某個常規字符串開頭,不是正則匹配。
3.~ 開頭表示區分大小寫的正則匹配;
4.~* 開頭表示不區分大小寫的正則匹配
5./ 通用匹配, 若是沒有其它匹配,任何請求都會匹配到git
順序 no優先級:
(location =) > (location 完整路徑) > (location ^~ 路徑) > (location ,* 正則順序) > (location 部分起始路徑) > (/)github
上面的匹配結果
按照上面的location寫法,如下的匹配示例成立:
/ -> config A 精確徹底匹配,即便/index.html也匹配不了 /downloads/download.html -> config B 匹配B之後,往下沒有任何匹配,採用B /images/1.gif -> configuration D 匹配到F,往下匹配到D,中止往下 /images/abc/def -> config D 最長匹配到G,往下匹配D,中止往下 你能夠看到 任何以/images/開頭的都會匹配到D並中止,FG寫在這裏是沒有任何意義的,H是永遠輪不到的,這裏只是爲了說明匹配順序 /documents/document.html -> config C 匹配到C,往下沒有任何匹配,採用C /documents/1.jpg -> configuration E 匹配到C,往下正則匹配到E /documents/Abc.jpg -> config CC 最長匹配到C,往下正則順序匹配到CC,不會往下到E
http://seanlook.com/2015/05/17/nginx-location-rewrite/
1.default_type:定義響應的默認MIME類型。可使用types指令來將文件擴展名映射到MIME類型。
2.types:將文件擴展名映射到MIME類型的響應。擴展名不區分大小寫。在nginx配置文件中有個mime.types文件是nginx默認的映射表。要使用特定位置發出全部請求的「application/octet-stream」MIEM類型,可使用以下配置:
location /download/ { types { } default_type application/octet-stream; }
3.types_hash_bucket_size:設置類型哈希表的存儲bucket大小。
4.types_hash_max_size:設置類型哈希表的最大大小。
1.referer_hash_bucket_size:設置有效的查閱器哈希表的bucket大小。
2.referer_hash_max_size:設置有效的查閱器哈希表最大大小。
3.valid_referers:指定「Referer」請求字段值,這將致使嵌入的$invalid_referer變量設置爲空字符串。搜索匹配不區分大小寫。
valid_referers選項
1.none:請求頭中缺乏「Referer」字段;
2.blocked:「請求」字段存在於請求標頭中,但其值已被防火牆或代理服務器刪除; 這樣的值是不以「http://」
或「https://」
開頭的字符串;
3.server_names:「Referer」請求頭字段包含服務器名稱之一;
4.arbitrary string:定義服務器名稱和可選的URI前綴。 服務器名稱的開頭或結尾能夠有「*」。 在檢查期間,「Referer」字段中的服務器端口被忽略;
5.regular expression:第一個符號應該是一個「〜」。 應當注意,表達式將與在「http://」
或「https://」
以後開始的文本匹配。
舉例
location ~* \.(gif|png|jpg|bmp)$ { valid_referers none blockd *.study.com; if ($invalid_referer) { rewrite ^/ http://www.study.com/fuck.html; } }
1.add_header:若是響應碼等於200、20一、20四、20六、30一、30二、30三、304或307,則將指定的字段添加到響應頭中。這裏須要注意:在使用此指令時只能添加報頭而不能重寫報頭。
2.expires:若是響應代碼等於200,201,204,206,301,302,303,304或307,則啓用或禁用添加或修改「Expires」和「Cache-Control」響應頭字段
舉例
location / { add_header X-Via $server_addr; index index.html index.htm; root /data/website/study; } location ~* \.(gif|png|jpg|bmp)$ { expires 30d; }
1.ssl:爲指定的虛擬主機啓用HTTPS協議。建議使用listen指令的ssl參數。
2.ssl_buffer_size:設置用於發送數據的緩衝區大小。
3.ssl_certificate:指定開啓HTTPS協議主機的PEM格式證書文件。從版本1.11.0開始,能夠屢次指定此僞指令來加載不一樣類型的證書,只有OpenSSL 1.0.2或更高版本支持不一樣證書的單獨證書鏈。 對於舊版本,只能使用一個證書鏈。因爲HTTPS協議的限制,虛擬服務器應該在不一樣的IP地址上偵聽,不然將爲第二個站點發出第一個服務器的證書。
4.ssl_certifirate_key:指定具備給定虛擬服務器的PEM格式的密鑰的文件。
5.ssl_ciphers:指定啓用的密碼。 密碼以OpenSSL庫理解的格式指定。
6.ssl_protocols:啓用指定的協議。 僅當使用版本1.0.1或更高版本的OpenSSL庫時,TLSv1.1和TLSv1.2參數才起做用。從版本1.1.13和1.0.12開始支持TLSv1.1和TLSv1.2參數,所以,當舊版nginx版本使用OpenSSL版本1.0.1或更高版本時,這些協議能夠正常工做,但不能禁用。
7.ssl_session_cache:設置存儲會話參數的高速緩存的類型和大小。
8.ssl_session_timeout:客戶端能夠重用會話緩存中ssl參數的過時時間。
9.ssl_prefer_server_ciphers:設置協商加密算法時,優先使用咱們服務端的加密套件,而不是客戶端瀏覽器的加密套件。
ssl_session_cache選項說明
1.off:嚴格禁止使用會話緩存:nginx顯式告訴客戶端會話可能不會被重用。
2.none:緩慢地禁止使用會話緩存:nginx告訴客戶端會話能夠被重用,但實際上不在高速緩存中存儲會話參數。
3.builtin:一個內置在OpenSSL中的緩存; 僅由一個工做進程使用。 緩存大小在會話中指定。 若是未指定大小,則等於20480個會話。 使用內置緩存可能會致使內存碎片。
4.shared:在全部工做進程之間共享的高速緩存。 緩存大小以字節爲單位指定; 一兆字節能夠存儲約4000個會話。 每一個共享緩存應該有一個任意名稱。 具備相同名稱的緩存可用於多個虛擬服務器。
兩種緩存類型能夠同時使用,例如:
ssl_session_cache builtin:1000 shared:SSL:10m;
可是隻使用沒有內置緩存的共享緩存應該更有效。
舉例
server { listen 443 ssl; server_name ssl.study.com; ssl_certificate "/etc/nginx/ssl/study.crt"; ssl_certificate_key "/etc/nginx/ssl/study.key"; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { root /data/website/study/ssl; index index.html index.htm; } }
擴展學習
1.自籤ssl證書時有時會遇到以下問題:
Using configuration from /etc/pki/tls/openssl.cnf Check that the request matches the signature Signature ok The organizationName field needed to be the same in the CA certificate (ca.com) and the request (study.com)
具體解決方法我是將/etc/pki/tls/openssl.cnf文件中countryName = optional
、stateOrProvinceName = optional
、organizationName = optional
這個三個參數修改。
2.因爲使用HTTPS會很是消耗CPU資源,這裏建議開啓keepalive、ssl_session_cache和ssl_session_timeout功能提高性能。其中1M 的會話緩存大概包含 4000 個會話,而默認的ssl_session_timeout爲5m,咱們能夠設置增長時間。
3.但是使用 HSTS 策略強制瀏覽器使用 HTTPS 鏈接,這個須要作好全站HTTPS才能申請。可是加入後清除比較麻煩,這個須要注意。
4.nginx在1.1.13和1.0.12版本後默認是ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2,TLSv1.1與TLSv1.2要確保OpenSSL >= 1.0.1 ,SSLv3 如今還有不少地方在用但有很多被攻擊的漏洞。
https://luckymrwang.github.io/2015/10/09/Nginx-SSL-性能優化/
https://aotu.io/notes/2016/08/16/nginx-https/
http://seanlook.com/2015/05/28/nginx-ssl/
1.log_not_found:啓用或者禁用將未找到的文件記錄到error_log中。默認開啓。
2.log_subrequest:啓用或者禁用將子請求記錄到access_log中。默認關閉。
3.access_log:設置緩衝日誌寫入的路徑,格式和配置。
4.log_format:指定日誌格式。
5.open_log_file_cache:定義一個緩存,用於存儲其名稱包含變量的經常使用日誌的文件描述符。默認關閉。
6.rewrite_log:啓用或禁用將ngx_http_rewrite_module模塊僞指令的處理結果記錄到通知級別的error_log。默認關閉。
7.error_log:配置錯誤日誌。第一個參數定義將存儲日誌的文件。第二個參數肯定日誌記錄的級別,能夠是如下之一:debug,info,notice,warn,error,crit,alert或emerg。 以上的日誌級別按嚴重性遞增的順序列出。
access_log參數
1.gzip壓縮等級。
2.buffer設置內存緩存區大小。
3.flush保存在緩存區中的最長時間。
4.off不記錄日誌。
好比,設置 buffer,buffer 滿 32k 才刷盤;假如 buffer 不滿 5s 鍾強制刷盤的配置以下:
access_log /var/log/nginx/access.log buffer=32k flush=5s;
log_format日誌格式
變量 | 含義 |
---|---|
$remote_addr | client address |
$remote_user | 用戶名提供基本認證 |
$time_local | 公共日誌格式中的本地時間 |
$request | 記錄請求的URL和HTTP協議 |
$status | response status |
$body_bytes_sent | 發送到客戶端的字節數,不計數響應頭 |
$http_referer | url跳轉來源 |
$http_user_agent | 用戶端瀏覽器信息 |
$http_x_forwarded_for | 記錄客戶端IP地址 |
$bytes_sent | 發送到客戶端的字節數 |
$connection | 鏈接序列號 |
$connection_requests | 經過鏈接發出的當前請求數 |
$msec | 日誌寫入時間。單位爲秒,精度是毫秒。 |
$pipe | 若是請求是經過HTTP流水線(pipelined)發送,pipe值爲「p」,不然爲「.」。 |
$request_length | 請求的長度(包括請求行,請求頭和請求正文)。 |
$request_time | 請求處理時間,單位爲秒,精度毫秒; 從讀入客戶端的第一個字節開始,直到把最後一個字符發送給客戶端後進行日誌寫入爲止。 |
open_log_file_cache參數
1.max:設置緩存中的最大文件描述符數量,若是緩存被佔滿,採用LRU算法將描述符關閉。
2.inactive:設置存活時間,默認是10s
3.min_uses:設置在inactive時間段內,日誌文件最少使用多少次後,該日誌文件描述符記入緩存中,默認是1次
4.valid:設置檢查頻率,默認60s
1.break:中止處理當前的ngx_http_rewrite_module僞指令集。
2.if:評估指定的條件。 若是爲true,那麼在大括號中指定的模塊指令將被執行,而且請求被分配在if指令內部的配置。 if指令內的配置繼承自先前的配置級別。
3.return:中止處理並將指定的代碼返回給客戶端。
4.rewrite:若是指定的正則表達式匹配請求URI,那麼將按照替換字符串中指定的方式更改URI。 重寫指令按照它們在配置文件中的出現順序執行。 可使用標誌來終止指令的進一步處理。 若是替換字符串以「http://」
,「https://」
或「$ scheme」
開頭,則處理中止,並將重定向返回給客戶端。
5.set:設置指定變量的值。 該值能夠包含文本,變量及其組合。
6.uninitialized_variable_warn:控制是否記錄警告未初始化的變量。
1.變量名;若是變量的值爲空字符串或「0」,則爲false;在版本1.0.1以前,以「0」開頭的任何字符串被視爲false值。
2.使用「=」和「!=」運算符將變量與字符串進行比較;
3.~:模式匹配,區分字符大小寫;~*:模式匹配,不區分字符大小寫;!~:模式不匹配,區分字符大小寫;!~*: 模式不匹配,不區分字符大小寫;
4.使用「-f」和「!-f」運算符檢查文件存在;
5.使用「-d」和「!-d」運算符檢查目錄存在;
6.使用「-e」和「!-e」運算符檢查文件,目錄或符號連接是否存在;
7.使用「-x」和「!-x」運算符檢查可執行文件。
1.last:中止處理當前的ngx_http_rewrite_module指令集,並開始搜索與更改的URI匹配的新位置;
2.break:中止處理當前的ngx_http_rewrite_module指令集,如同break指令同樣;
3.redirect:返回具備302代碼的臨時重定向; 若是替換字符串不以「http://」
,「https://」
或「$ scheme」
開頭,則使用;
4.permanent:返回301代碼的永久重定向。
舉例
多目錄轉成參數:
abc.domian.com/sort/2 => abc.domian.com/index.php?act=sort&name=abc&id=2
if ($host ~* (.*)\.domain\.com) { set $sub_name $1; rewrite ^/sort\/(\d+)\/?$ /index.php?act=sort&cid=$sub_name&id=$1 last; }
目錄對換
/123456/xxxx -> /xxxx?id=123456
rewrite ^/(\d+)/(.+)/ /$2?id=$1 last;
例以下面設定nginx在用戶使用ie的使用重定向到/nginx-ie目錄下:
if ($http_user_agent ~ MSIE) { rewrite ^(.*)$ /nginx-ie/$1 break; }
目錄自動加「/」
if (-d $request_filename){ rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent; }
將多級目錄下的文件轉成一個文件,加強seo效果
/job-123-456-789.html 指向/job/123/456/789.html
rewrite ^/job-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /job/$1/$2/jobshow_$3.html last;
https://xuexb.com/html/nginx-url-rewrite.html
http://www.tiyee.net/post/122
http://blog.c1gstudio.com/archives/434
1.fastcgi_pass:設置FastCGI服務器的地址。 地址能夠指定爲域名或IP地址和端口:fastcgi_pass localhost:9000
。若是域名解析爲多個地址,則全部這些地址都將以循環方式使用。 此外,能夠將地址指定爲服務器組。
2.fastcgi_index:在$ fastcgi_script_name變量的值中設置將附加在以斜槓結尾的URI後面的文件名。 例如,使用這些設置和「/page.php」請求,SCRIPT_FILENAME參數將等於「/home/www/scripts/php/page.php」
,對於「/」請求,它將等於「/home/www/scripts/php/index.php「
。
3.fastcgi_param:設置應傳遞到FastCGI服務器的參數。 該值能夠包含文本,變量及其組合。 當且僅當沒有在當前級別上定義fastcgi_param僞指令時,這些僞指令才繼承自上一級。
4.fastcgi_cache_path:設置緩存的路徑和其餘參數。 緩存數據存儲在文件中。 高速緩存中的密鑰和文件名都是將MD5函數應用於代理URL的結果。 levels參數定義緩存的層次結構級別:從1到3,每一個級別接受值1或2.例如,在如下配置中:fastcgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;
緩存中的文件名將以下所示:/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c
。
5.fastcgi_cache:定義用於緩存的共享內存區域。 同一區域能夠在幾個地方使用。 參數值能夠包含變量(1.7.9)。 off參數禁用從先前配置級別繼承的緩存。
6.fastcgi_cache_key:定義用於緩存的鍵。
7.fastcgi_cache_methods:若是客戶端請求方法列在此指令中,那麼響應將被緩存。 「GET」和「HEAD」方法老是添加到列表中,但建議明確指定它們。
8.fastcgi_cache_min_uses:設置在其後響應將被緩存的請求數。
9.fastcgi_cache_use_stable:肯定在與FastCGI服務器通訊期間發生錯誤時,可使用過期緩存響應的狀況。默認禁用。
10.fastcgi_cache_valid:設置不一樣響應代碼的緩存時間。
11.fastcgi_connect_timeout:定義與FastCGI服務器創建鏈接的超時。 應該注意,該超時一般不能超過75秒。
12.fastcgi_send_timeout:設置將請求發送到FastCGI服務器的超時。 超時僅在兩個連續的寫操做之間設置,而不是用於傳輸整個請求。 若是FastCGI服務器在此時間內未收到任何內容,則鏈接將關閉。
13.fastcgi_read_timeout:定義從FastCGI服務器讀取響應的超時。 超時僅在兩個連續讀取操做之間設置,而不是用於傳輸整個響應。 若是FastCGI服務器在此時間內未傳輸任何內容,則鏈接將關閉。
14.fastcgi_buffer_size:設置用於讀取從FastCGI服務器接收的響應的第一部分的緩衝區大小。 這部分一般包含一個小的響應報文header。 默認狀況下,緩衝區大小等於一個內存頁。是4K或8K,取決於平臺。 然而,它能夠作得更小。
15.fastcgi_buffers:設置用於從FastCGI服務器讀取單個鏈接的響應的緩衝區的數量和大小。 默認狀況下,緩衝區大小等於一個內存頁。 是4K或8K,取決於平臺。
16.fastcgi_busy_buffers_size:當啓用來自FastCGI服務器的響應緩衝時,限制可能響應報文還沒有徹底讀取而忙於向客戶端發送響應的緩衝區的總大小。 同時,其他緩衝區可用於讀取響應,而且若是須要,緩衝對臨時文件的響應的一部分。 默認狀況下,大小受限於由fastcgi_buffer_size和fastcgi_buffers指令設置的兩個緩衝區的大小。
17.fastcgi_buffering:啓用或禁用來自FastCGI服務器的響應報文緩衝。
18.fastcgi_temp_file_write_size:當啓用從FastCGI服務器到臨時文件的響應緩衝時,限制寫入臨時文件的數據大小。 默認狀況下,大小受限於由fastcgi_buffer_size和fastcgi_buffers指令設置的兩個緩衝區。 臨時文件的最大大小由fastcgi_max_temp_file_size指令設置。
19.fastcgi_max_temp_file_size:當啓用來自FastCGI服務器的響應緩衝,而且整個響應不適合由fastcgi_buffer_size和fastcgi_buffers指令設置的緩衝區時,響應的一部分能夠保存到臨時文件。 此僞指令設置臨時文件的最大大小。 一次寫入臨時文件的數據大小由fastcgi_temp_file_write_size指令設置。
20.fastcgi_temp_path:定義用於存儲具備從FastCGI服務器接收的數據的臨時文件的目錄。 最多能夠在指定目錄下使用三級子目錄層次結構。
舉例
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=fcgicache:10m; server { listen 80; server_name www.a.com; location / { root html; index index.html index.htm; } location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_cache fcgicache; fastcgi_cache_key $request_uri; fastcgi_cache_valid 200 302 10m; fastcgi_cache_valid 301 1h; fastcgi_cache_valid any 1m; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html/$fastcgi_script_name; include fastcgi_params; } } } 沒有啓用緩存的測試: # ab -c 100 -n 1000 http://www.a.com/info.php ··· Requests per second: 1299.63 [#/sec] (mean) Time per request: 76.945 [ms] (mean) Time per request: 0.769 [ms] (mean, across all concurrent requests) Transfer rate: 48288.03 [Kbytes/sec] received ··· 啓用緩存的測試: # ab -c 100 -n 1000 http://www.a.com/info.php ... Requests per second: 7686.87 [#/sec] (mean) Time per request: 13.009 [ms] (mean) Time per request: 0.130 [ms] (mean, across all concurrent requests) Transfer rate: 285607.67 [Kbytes/sec] received ...
注意
1.建立緩存最少須要定義四個指令:fastcgi_cache_path、fastcgi_cache_key、fastcgi_cache_valid、fastcgi_cache。
2.緩存定義的目錄須要手動建立。
1.proxy_pass:設置代理服務器的協議和地址以及應映射位置的可選URI。 做爲協議,能夠指定「http」或「https」。
2.proxy_set_header:用於proxy server向backend server發請求報文時,將某請求首部從新賦值,或在原有值後面添加一個新的值; 也能夠添加自定義首部;
3.proxy_cache_path:設置緩存的路徑和其餘參數。 緩存數據存儲在文件中。 高速緩存中的文件名是將MD5函數應用於高速緩存密鑰的結果。 levels參數定義緩存的層次結構級別:從1到3,每一個級別接受值1或2.
4.proxy_cache_key:定義用於緩存的鍵。
5.proxy_cache_valid:設置不一樣響應代碼的緩存時間。
6.proxy_connect_timeout:定義與代理服務器創建鏈接的超時。 應該注意,該超時一般不能超過75秒。
7.proxy_send_timeout:設置將請求傳輸到代理服務器的超時。 超時僅在兩個連續的寫操做之間設置,而不是用於傳輸整個請求。 若是代理服務器在此時間內未收到任何內容,則鏈接將關閉。
8.proxy_read_timeout:定義從代理服務器讀取響應的超時。 超時僅在兩個連續讀取操做之間設置,而不是用於傳輸整個響應。 若是代理服務器在此時間內未發送任何內容,則鏈接將關閉。
9.proxy_buffer_size:設置用於讀取從代理服務器接收的響應的第一部分的緩衝區大小。 這部分一般包含一個小的響應頭。 默認狀況下,緩衝區大小等於一個內存頁。 這是4K或8K,取決於平臺。 然而,它能夠作得更小。
10.proxy_buffering:啓用或者禁用proxy 緩衝。
11.proxy_buffers:設置用於從代理服務器讀取單個鏈接的響應的緩衝區的數量和大小。 默認狀況下,緩衝區大小等於一個內存頁。 這是4K或8K,取決於平臺。
12.proxy_busy_buffers_size:當啓用來自代理服務器的響應緩衝時,限制可能忙於向客戶端發送響應的緩衝區的總大小,而響應還沒有徹底讀取。 同時,其他緩衝區可用於讀取響應,而且若是須要,緩衝對臨時文件的響應的一部分。 默認狀況下,大小受由proxy_buffer_size和proxy_buffers指令設置的兩個緩衝區的大小的限制。
13.proxy_cache_methods:若是客戶端請求方法列在此指令中,那麼響應將被緩存。 「GET」和「HEAD」方法老是添加到列表中,但建議明確指定它們。 另請參見proxy_no_cache指令。
14.proxy_no_cache:定義響應不會保存到緩存的條件。 若是字符串參數的至少一個值不爲空,而且不等於「0」,則不會保存響應。
15.proxy_cache_min_uses:設置在其後響應將被緩存的請求數。
舉例
proxy_pass後面的路徑不帶uri時,其會將location的uri傳遞給後端的主機;下面的示例會將/uri/傳遞給backend服務器;
location /uri/ { proxy_pass http://hostname; }
proxy_pass後面的路徑是一個uri時,其會將location的uri替換爲後端主機本身的uri;
location /uri/ { proxy_pass http://hostname/new_uri/; }
若是location定義其uri時使用的正則表達式模式匹配,則proxy_pass後的路徑不可以使用uri;
location ~* \.(jpg|gif|jpeg)$ { proxy_pass http://HOSTNAME; }
此處的http://HOSTNAME
後面不能有任何uri,哪怕只有/也不能夠;
關於緩存相關的配置:
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=proxycache:10m; location / { proxy_cache proxycache; proxy_cache_key $request_uri; proxy_cache_valid 200 302 10m; proxy_cache_valid 301 1h; proxy_cache_valid any 1m; proxy_pass http://192.168.0.201/bbs/; index index.html index.htm; } 中間從新載入配置在訪問頁面進行緩存。 # ll /var/cache/nginx/proxy/ 總用量 0 drwx------ 4 nginx nginx 24 2月 20 00:12 9
1.server:定義服務器的地址和其餘參數。 能夠將地址指定爲域名或IP地址,具備可選端口或做爲在「unix:」前綴後指定的UNIX域套接字路徑。 若是未指定端口,則使用端口80。 解析爲多個IP地址的域名會一次定義多個服務器。
2.hash:指定服務器組的負載平衡方法,其中客戶端 - 服務器映射基於散列鍵值。 鍵能夠包含文本,變量及其組合。 請注意,從組中添加或刪除服務器可能會致使將大多數密鑰從新映射到不一樣的服務器。
3.ip_hash:指定組應使用負載平衡方法,其中請求根據客戶端IP地址分佈在服務器之間。 客戶端IPv4地址的前三個八位字節或整個IPv6地址用做散列密鑰。 該方法確保來自同一客戶端的請求將始終傳遞到同一服務器,除非此服務器不可用。 在後一種狀況下,客戶端請求將被傳遞到另外一個服務器。 最可能的是,它將始終是相同的服務器。
4.keepalive:激活與上游服務器的鏈接的緩存。connections參數設置保存在每一個工做進程的緩存中的上游服務器的空閒keepalive鏈接的最大數量。 當超過此數量時,最近使用的最少鏈接將關閉。應該特別注意的是,keepalive僞指令不限制nginx工做進程能夠打開的到上游服務器的鏈接的總數。 鏈接參數應設置爲足夠小,以容許上游服務器處理新的傳入鏈接。
server參數
1.weight=number:設置服務器的權重,默認爲1。
2.max_fails=number:設置應在fail_timeout參數設置的持續時間內與服務器通訊的失敗嘗試次數,以考慮服務器在fail_timeout參數設置的持續時間內不可用。 默認狀況下,失敗嘗試次數設置爲1.零值禁用嘗試計數。
3.fail_timeout=time:與服務器通訊的指定次數的失敗嘗試發生在考慮服務器不可用的時間。以及服務器將被視爲不可用的時間段。默認狀況下,參數設置爲10秒。
4.backup:將服務器標記爲備份服務器。 當主服務器不可用時,將傳遞請求。
5.down將服務器標記爲永久不可用。
1.limit_conn:設置共享內存區域和給定鍵值的最大容許鏈接數。 當超出此限制時,服務器將返回503(服務臨時不可用)錯誤以回覆請求。
2.limit_conn_log_level:設置服務器限制鏈接數時所需的日誌記錄級別。
3.limit_conn_status:設置要響應拒絕的請求返回的狀態代碼。
4.limit_conn_zone:設置將保持各類鍵的狀態的共享內存區域的參數。特別地,該狀態包括當前鏈接數。鍵能夠包含文本,變量及其組合。不計入具備空鍵值的請求。
5.limit_req:設置共享內存區域和請求的最大突發大小。 若是請求速率超過爲區域配置的速率,則它們的處理被延遲,使得以定義的速率處理請求。 過多的請求被延遲,直到它們的數量超過最大突發大小,在這種狀況下,請求以錯誤503(服務臨時不可用)結束。 默認狀況下,最大突發大小等於零。
6.limit_req_log_level:爲服務器因爲速率超過或拒絕請求處理而拒絕處理請求的狀況設置所需的日誌記錄級別。 延遲的日誌級別比拒絕的日誌級別低一個點; 例如,若是指定了「limit_req_log_level notice」,則會使用信息級別記錄延遲。
7.limit_req_status:設置要響應拒絕的請求返回的狀態代碼。
8.limit_req_zone:設置將保持各類鍵的狀態的共享內存區域的參數。 特別地,該狀態存儲當前的過多請求數。 鍵能夠包含文本,變量及其組合。 不計入具備空鍵值的請求。
9.limit_except:對指定範圍以外的其它的方法進行訪問控制; 方法參數能夠是如下之一:GET,HEAD,POST,PUT,DELETE,MKCOL,COPY,MOVE,OPTIONS,PROPFIND,PROPPATCH,LOCK,UNLOCK或PATCH。
10.limit_rate:限制客戶端每秒鐘所可以傳輸的字節數,默認爲0表示無限制; 速率以字節/秒指定。這是對每一個請求設置限制,所以若是客戶端同時打開兩個鏈接,則總速率將是指定限制的兩倍。
11.limit_rate_after:設置初始量,在此以後,對客戶端的響應的進一步傳輸將受到速率限制。
12.internal:指定給定位置只能用於內部請求。 * 對於外部請求,返回客戶端錯誤404(找不到)。
客戶端請求限制
location /download { limit_except GET { allow 192.168.0.220; deny all; } }
下載速度限制
location /download { limit_rate 20480; } # wget http://www.a.com/download/test.img --2017-02-12 01:19:55-- http://www.a.com/download/test.img 正在解析主機 www.a.com (www.a.com)... 192.168.0.220 正在鏈接 www.a.com (www.a.com)|192.168.0.220|:80... 已鏈接。 已發出 HTTP 請求,正在等待迴應... 200 OK 長度:209715200 (200M) [application/octet-stream] 正在保存至: 「test.img」 0% [ ] 245,760 20.0KB/s 剩餘 2h 50m
請求鏈接數限制
如下配置將限制每一個客戶端IP與服務器的鏈接數,同時限制與虛擬服務器的鏈接總數:
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=perserver:10m; server { ... limit_conn perip 10; limit_conn perserver 100; }
請求速率限制
如下配置將限制來自單個IP地址的請求的處理速率,同時限制虛擬服務器的請求處理速率:
limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s; limit_req_zone $server_name zone=perserver:10m rate=10r/s; server { ... limit_req zone=perip burst=5 nodelay; limit_req zone=perserver burst=10; }
速率在每秒請求數(r/s)中指定。若是須要每秒小於一個請求的速率,則在每分鐘請求中指定(r/m)。例如,每秒半請求爲30r/m。
若是不但願在請求受限時延遲過多的請求,則應使用參數nodelay。
1.open_file_cache:配置nginx存儲下面內容的緩存 文件描述符、文件大小和最近一次的修改時間;打開的目錄結構;沒有找到的或者沒有權限操做的文件信息。
2.open_file_cache_errors:是否緩存找不到路徑的文件,或者沒有權限訪問的文件相關信息。
3.open_file_cache_min_uses:設置由open_file_cache指令的inactive參數配置的時間段內文件訪問的最小數量。
4.open_file_cache_valid:每隔多久檢查一次緩存項的有效性。
舉例
open_file_cache max=100000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
參數說明:
1.max:表示能夠緩存的最大條目上限,一旦達到則會使用LRU算法清除最近最少使用的緩存項。
2.inactive:在指定的時長內沒有被訪問過的緩存項爲非活動緩存項,直接刪除。
3.off:禁用緩存。
1.gzip:啓用或者停用gzip壓縮響應。
2.gzip_buffers:設置用於壓縮響應的緩衝區數量和大小。
3.gzip_comp_level:設置gzip壓縮級別。接受的的值爲1~9之間。
4.gzip_disable:爲指定的客戶端禁用gzip功能。咱們設置成IE6或者更低版本以使咱們的方案可以普遍兼容。
5.gzip_min_length:設置gzip壓縮的最小長度。長度僅根據「Content-Length」響應頭字段肯定。
6.gzip_http_version:設置壓縮響應所需的請求的最小HTTP版本。
7.gzip_proxied:根據請求和響應啓用或者禁用代理請求響應的gzip壓縮。
8.gzip_types:除了「text/html」以外,還容許爲指定的MIME類型使用gzip壓縮。
9.gzip_vary:若是指令gzip,gzip_static或gunzip處於活動狀態,則啓用或禁用插入「Vary:Accept-Encoding」響應頭字段。
舉例
gzip on; gzip_buffers 32 8k; gzip_comp_level 6; gzip_disable "msie6"; gzip_min_length 1k; gzip_http_version 1.1; gzip_proxied any; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; gzip_vary on;
關於gzip_proxied指令的參數說明:
1.off:禁用全部代理請求的壓縮,忽略其餘參數;
2.expired:若是響應頭包括具備禁用緩存的值的「Expires」字段,則啓用壓縮;
3.no-cache:若是響應頭包括具備「no-cache」參數的「Cache-Control」字段,則啓用壓縮;
4.no-store:若是響應頭包括具備「no-store」參數的「Cache-Control」字段,則啓用壓縮;
5.private:若是響應頭包括具備「private」參數的「Cache-Control」字段,則啓用壓縮;
6.no_last_modified:若是響應頭不包括「Last-Modified」字段,則啓用壓縮;
7.no_etag:若是響應報頭不包括「ETag」字段,則啓用壓縮;
8.auth:若是請求頭包括「受權」字段則啓用壓縮;
9.any:啓用對全部代理請求的壓縮。
1.auth_basic:啓用使用「HTTP Basic Authentication」協議驗證用戶名和密碼。
2.auth_basic_user_file:指定驗證的用戶名和密碼。通常是用htpasswd生成用戶和密碼。
3.stub_status:顯示nginx基本狀態信息。
各狀態說明
1.Active connections:當前客戶端鏈接數,包括等待鏈接。
2.accepts:接受的客戶端鏈接的總數。
3.handled:處理的鏈接的總數。 一般,參數值與accept相同,除非已達到某些資源限制(例如,worker_connections限制)。
4.requests:客戶端請求的總數。
5.Reading:nginx正在讀取請求頭的當前鏈接數。
6.Writing:nginx正在將響應寫回客戶端的當前鏈接數。
7.Waiting:等待請求的空閒客戶端鏈接的當前數量。
舉例
location /nginx_status { auth_basic nginx_status; auth_basic_user_file .nginx_user; stub_status; } # cat /etc/nginx/.nginx_user bols:$apr1$nD1i394h$QZYXyYD1AO5wUgakx9N7X. # curl -u bols:bols http://www.study.com/nginx_status Active connections: 1 server accepts handled requests 19 19 34 Reading: 0 Writing: 1 Waiting: 0
1.worker_cpu_affinity:針對多核CPU設置將nginx的worker進程綁定在指定的cpu上。綁定的CPU仍是會運行別的進程,若是想要將CPU的核心只運行nginx的worker進程,須要使用taskset命令進行設置。在新版本的1.10中此選項可使用auto讓其自動綁定。
2.worker_priority:定義worker進程的優先級,負數意味着級別高,通常是在-20~19之間選擇。通常不建議設置此選項。
3.worker_processes:worker進程的數量,通常是CPU核心數量減1,在新版本1.10能夠設置成auto實現自行設定。
4.worker_rlimit_nofile:指定一個worker進程打開的最多文件句柄數。
1.accept_mutex:worker接收請求時的負載均衡鎖,啓用時可讓worker進程輪流、序列化的接受請求。不然則向全部worker進程通知請求。使用此選項能夠避免出現驚羣現象,可是若是worker進程比較少則能夠不開啓此選項。
2.accept_mutex_delay:若是啓用accept_mutex選項則此選項是指定若是另外一個worker進程接受鏈接的最長時間。
3.multi_accept:若是禁用此選項則worker進程會一次接受一個鏈接,不然worker進程將接受全部新鏈接。
4.use:指定使用處理鏈接的方法。通常不指定有nginx本身選擇。
5.worker_connections:一個worker進程所可以響應的最大請求數量。則設置此選項是還須要考慮worker_rlimit_nofile選項的限制。
1.keepalive_disable:指定禁用那種瀏覽器使用keepalive功能。設置成msie6則在收到POST請求時時禁用,設置成safari則禁用OS x系統的Safari瀏覽器的保持功能。
2.keepalive_requests:在keepalive鏈接上所容許請求的最大資源數。
3.keepalive_timeout:設置keepalive鏈接的 超時時間。
4.tcp_nodelay:nginx不要緩存數據,而是一段一段的發送。當須要及時發送數據時就應該設置這個選項,這樣發送一個小數據塊信息時就不能當即獲得返回值。
5.tcp_nopush:在一個數據包中發送全部頭文件,而不是一個接一個的發送。
6.client_body_timeout:定義讀取客戶端請求報文body的超時時間。超時時間僅設置在兩個連續讀取操做之間的時間,而不是用於傳輸整個請求體。若是客戶端在此時間內未發送任何內容,則會將408(請求超時)錯誤返回給客戶端。
7.send_time:發送響應報文的超時時長。僅在兩個連續的寫操做之間設置,而不是用於傳輸整個響應。若是客戶端在此時間內未收到任何內容,則鏈接關閉。
8.clent_header_timeout:定義讀取客戶端請求報文header的超時。 若是客戶端在此時間內未傳輸整個頭,則會向客戶端返回408(請求超時)錯誤。
9.reset_timeout_connection:啓用或禁用重置超時鏈接。 復位以下進行。 在關閉套接字以前,將對其設置SO_LINGER選項,其超時值爲0.當套接字關閉時,TCP RST將發送到客戶端,並釋放此套接字佔用的全部內存。 這有助於避免使已填充緩衝區的已關閉套接字長時間處於FIN_WAIT1狀態。應注意,超時keep-alive 鏈接正常應該關閉。
1.client_body_buffer_size:設置用於讀取客戶端請求報文body的緩衝區大小。當請求報文body大於緩衝區大小整個整個主體部分寫入到臨時文件中。32位系統默認是8k,在64位系統中是16k。
2.client_body_in_file_only:指定是否將客戶端的請求報文保存到文件中,該指令通常是在調試中使用。
3.clinet_body_in_single_buffer:指定是否將客戶端的請求報文保存在單個緩衝區中。
4.client_body_temp_path:指定客戶端請求報文的臨時存放目錄。目錄可使用三級子目錄形式。
5.client_header_buffer_size:指定客戶端請求報文的header的緩衝區大小。大多數狀況下默認的1k已經足夠使用,若是請求包括長cookie或者來自WAP客戶端就須要進行調整。若是請求報文中不適合則由large_client_header_buffers指令進行配置緩衝區大小。
6.client_max_body_size:設置在客戶端的請求報文的body中「Content-Length」字段的最大容許大小。若是請求大小超過此大小則會報413錯誤。設置爲0將禁用對客戶機請求正文大小的檢查。
7.large_client_header_buffers:設定客戶端請求報文header的緩衝區最大數量和大小。請求行不能超過一個緩衝區的大小,超過則會顯示414(Request-URI Too Large)錯誤返回到客戶端。 請求報文header字段也不能超過一個緩衝區的大小,超過則會顯示400(Bad Request)錯誤返回到客戶端。
1.aio:啓用或者禁用異步文件I/O。若是啓用aio則還須要設置directio。
2.directio:讀取大於或者等於指定大小的文件是容許使用directio方式傳輸。
3.sendfile:啓用或者禁用sendfile()傳輸文件。
4.sendfile_max_chunk:當設置爲非0時限制單個sendfile()調用中傳輸的數據量。
5.output_buffers:設置用於從磁盤讀取響應報文的緩衝區數量和大小。
在傳統的文件傳輸read()、write()中其具體工做流程以下:調用read()把文件數據copy到內容緩衝區中-->read()將數據從內核緩衝區copy到用戶緩衝區中-->write()將文件數據從用戶的緩衝區中copy到內核與socket相關的緩衝區中-->文件數據從socket緩衝封裝好報文響應併發送。
上面的流程能夠簡化成以下:
硬盤-->內核buf-->用戶buf-->內核socket相關緩衝區-->協議引擎
而使用sendfile()進行傳輸則不會在把數據copy到用戶空間,而是直接從內核緩衝區進行操做,具體工做流程以下:
sendfile()系統調用,文件數據copy到內核緩衝區-->數據從內核緩衝區到socket相關的緩衝區-->最後從socket相關的緩衝區copy到協議引擎
在使用AIO時須要設置directio選項,而且aio生效則sendfile就不會使用。在Linux中要麼使用aio讀取到緩衝區,要麼用sendfile直接發送二者不可同時使用。
在配置directio時是針對每一個請求文件大小而決定是否開啓directio。例如咱們設置成:directio 5m;
。此選項說明若是文件小於5m則使用sendfile進行傳輸,而directio則會禁用從而aio也不會使用。若是傳輸的文件大於或者等於5m那麼將啓用directio,從而aio生效,而sendfile並不生效。
這種設計貌似恰好把linux下aio和sendfile兩種機制的優勢很好的結合起來使用。對於大文件採用aio,節省cpu,而對於小文件,採用sendfile,減小拷貝;而且對於大文件aio採用directio,避免擠佔文件系統緩存,讓文件系統緩存更多的小文件。 從理論上來看,這種配置比較適合系統內存有限、小文件請求比較多、間隔有幾個大文件請求的Web環境;若是內存足夠大,那麼應該充分利用文件系統緩存,而directio使得aio沒法使用緩存是衡量最終是否須要採用aio的一個須要仔細考慮的因素;
1.ignore_invalid_headers:控制是否應忽略具備無效名稱的header字段。 有效名稱由英文字母,數字,連字符以及可能的下劃線組成(由underscores_in_headers指令控制)。若是在服務器級別指定了僞指令,那麼只有在服務器是默認值時才使用該值。 指定的值也適用於偵聽相同地址和端口的全部虛擬服務器。
2.underscores_in_headers:啓用或禁用在客戶端請求報文header字段中使用下劃線。 當禁用下劃線的使用時,其名稱包含下劃線的請求標題字段將被標記爲無效,並受到ignore_invalid_headers指令的約束。若是在服務器級別指定了僞指令,那麼只有在服務器是默認值時才使用該值。 指定的值也適用於監聽相同地址和端口的全部虛擬服務器。
HTTP頭是能夠包含英文字母([A-Za-z])、數字([0-9])、鏈接號(-)hyphens, 也可義是下劃線(_)。在使用nginx的時候應該避免使用包含下劃線的HTTP頭。主要的緣由有如下2點。
1.默認的狀況下nginx引用header變量時不能使用帶下劃線的變量。要解決這樣的問題只能單獨配置underscores_in_headers on。
2.默認的狀況下會忽略掉帶下劃線的變量。要解決這個須要配置ignore_invalid_headers off。
固然,nginx設置變量的時候是沒有任何這樣的限制的,能夠直接設置帶下劃線的header。可是最好不要這樣作。在使用nginx作多級代理的時候,也須要注意一些header不要重複設置。好比用來保存用戶IP的這個header只在最上層的nginx裏配置就行,後面的nginx不要重複設置致使覆蓋。
1.disable_symlinks:肯定打開文件時應該如何處理符號連接。
2.server_token:啓用或禁用在錯誤消息和「Server」響應頭字段中發出nginx版本。
https://segmentfault.com/a/1190000007897976
https://my.oschina.net/wmy596/blog/693898
http://www.cnblogs.com/leezhxing/p/4374035.html
http://pmghong.blog.51cto.com/3221425/1178836
https://github.com/qiwsir/ITArticles/blob/master/Nginx/配置性能優化的方法.md
https://www.zybuluo.com/ty4z2008/note/290139
http://www.z-dig.com/nginx-optimization-25.html
https://mos.meituan.com/library/30/how-to-optimize-nginx/