中文字幕亚洲人妻一区,一区二区中文字幕久久,国精偷拍一区二区三区

　　Nginx可以用來提供靜態資源服務(靜態資源文件訪問)、反向代理服務(請求轉發、負載等)、API服務，可以通過配置文件進行配置來實現Nginx的能力，因此本篇就進行配置文件的詳述來進行Nginx使用實踐。

1、Nginx配置概述

　　1.1、配置文件結構

　　Nginx配置文件結構目錄如下圖所示：

　　具體模塊功能分工如下：

全局塊

　　該部分配置主要影響Nginx全局，通常包括下面幾個部分：配置運行Nginx服務器用戶（組）、worker process數、Nginx進程PID存放路徑、錯誤日志的存放路徑配置文件的引入。

events塊

　　該部分配置主要影響Nginx服務器與用戶的網絡連接，主要包括：設置網絡連接的序列化、是否允許同時接收多個網絡連接、事件驅動模型的選擇、最大連接數的配置。

http塊

　　定義MIMI-Type自定義服務日志、允許sendfile方式、傳輸文件連接超時時間、單連接請求數上限。

server塊

　　配置網絡監聽基于名稱的虛擬主機配置、基于IP的虛擬主機配置。

location塊

　　location配置請求根目錄配置、更改location的URI、網站默認首頁配置。

　　1.2、配置文件語法

　　Nginx的配置語法如下：

配置文件由指令與指令塊構成，每條指令以;結尾，
指令與參數間以空格符號分割
指令塊以{}大括號將多條指令組織在一起
include語句允許組合多個配置文件以提升可維護性
使用#符號添加注釋，提供可讀性
使用$符號使用變量
部分指令的參數支持正則表達式

　　如示例：

2、Nginx詳細配置

　　2.1、Nginx全局塊配置

　　配置示例：

user  nobody nobody;
worker_processes  3;

error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;

pid        logs/nginx.pid;
worker_rlimit_nofile 65535;

　　2.1.1、配置運行Nginx服務器用戶（組）

　　指令格式：user user [group];

　　user：指定可以運行Nginx服務器的用戶

　　group：可選項，可以運行Nginx服務器的用戶組。

　　如果user指令不配置或者配置為user nobody nobody，則默認所有用戶都可以啟動Nginx進程(window下不指定)。

　　2.1.2、worker process數配置

　　Nginx服務器實現并發處理服務的關鍵，指令格式：worker_processes number | auto;

　　number：Nginx進程最多可以產生的worker process數。

　　auto：Nginx進程將自動檢測并設定worker process數。

　　worker_processes設置為多少，Nginx的主進程就會創建多少個worker_processes子進程，根據硬件調整，通常worker_process數等于CPU數量或者2倍于CPU。

　　2.1.3、Nginx進程PID存放路徑

　　Nginx進程是作為系統守護進程在運行，需要在某文件中保存當前運行程序的主進程號，Nginx支持該保存文件路徑的自定義。

　　指令格式：pid file;

　　file：指定存放路徑和文件名稱如果不指定默認置于路徑 logs/nginx.pid。

　　2.1.4、錯誤日志的存放路徑

　　指定格式：error_log file | stderr;

　　file：日志輸出到某個文件。

　　filestderr：日志輸出到標準錯誤輸出。

error_log  logs/error.log;  
error_log  logs/error.log  notice;  
error_log  logs/error.log  info;

　　2.1.5、指定指定進程可以打開的最大描述符

worker_rlimit_nofile 65535;

　　這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，但是nginx分配請求并不是那么均勻，所以最好與ulimit -n 的值保持一致。

　　現在在linux 2.6內核下開啟文件打開數為65535，worker_rlimit_nofile就相應應該填寫65535。這是因為nginx調度時分配請求到進程并不是那么的均衡，所以假如填寫10240，總并發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。

　　2.2、events模塊配置

　　配置示例：

use epoll;
accept_mutex on;
multi_accept on;
worker_connections  1024;
keepalive_timeout 60;
client_header_buffer_size 4k;　　
open_file_cache max=65535 inactive=60s;   
open_file_cache_valid 80s;
open_file_cache_min_uses 1;

　　2.2.1、指定事件模型

use epoll;

　　使用epoll的I/O 模型。linux建議epoll，FreeBSD建議采用kqueue，window下不指定。

補充說明：與apache相類，nginx針對不同的操作系統，有不同的事件模型。

A）標準事件模型

　　Select、poll屬于標準事件模型，如果當前系統不存在更有效的方法，nginx會選擇select或poll。

B）高效事件模型

　　Kqueue：適用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X。使用雙處理器的MacOS X系統使用kqueue可能會造成內核崩潰。

　　Epoll：適用于Linux內核2.6版本及以后的系統。

　　/dev/poll：適用于Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

　　Eventport：適用于Solaris 10。為了防止出現內核崩潰的問題，有必要安裝安全補丁。

　　2.2.2、設置網絡連接的序列化

　　指令格式：accept_mutex on | off;

　　該指令默認為on狀態，但在1.11.3的后續版本中默認為off。表示會對多個Nginx進程接收連接進行序列化，防止多個進程對連接的爭搶。也就是防止“驚群現象”發生，就Nginx的場景來解釋的話大致的意思就是：當一個新網絡連接來到時，多個worker進程會被同時喚醒，但僅僅只有一個進程可以真正獲得連接并處理之。如果每次喚醒的進程數目過多的話，其實是會影響一部分性能的。

　　所以在這里，如果accept_mutex on，那么多個worker將是以串行方式來處理，其中有一個worker會被喚醒；反之若accept_mutex off，那么所有的worker都會被喚醒，不過只有一個worker能獲取新連接，其它的worker會重新進入休眠狀態。

Changes with nginx 1.11.3                                        26 Jul 2016
    *) Change: now the "accept_mutex" directive is turned off by default.

　　這個值的開關與否其實是要和具體場景掛鉤的。

　　2.2.3、是否允許同時接收多個網絡連接

　　指令格式：multi_accept on | off;

　　該指令默認為off狀態，意指每個worker process 一次只能接收一個新到達的網絡連接。若想讓每個Nginx的worker process都有能力同時接收多個網絡連接，則需要開啟此配置。

　　2.2.4、工作進程的最大連接數量

worker_connections 512;

　　每個工作進程的最大連接數量。根據硬件調整，和前面工作進程配合起來用，盡量大，但是別把cpu跑到100%就行。每個進程允許的最多連接數，默認512，理論上每臺nginx服務器的最大連接數為：worker_processes*worker_connections。

　　2.2.5、其余配置

keepalive_timeout 60;　　#keepalive超時時間。

#客戶端請求頭部的緩沖區大小。這個可以根據你的系統分頁大小來設置，一般一個請求頭的大小不會超過1k，不過由于一般系統分頁都要大于1k，所以這里設置為分頁大小。
#分頁大小可以用命令getconf PAGESIZE 取得。但也有client_header_buffer_size超過4k的情況，但是client_header_buffer_size該值必須設置為“系統分頁大小”的整倍數。
client_header_buffer_size 4k;　　

#這個將為打開文件指定緩存，默認是沒有啟用的，max指定緩存數量，建議和打開文件數一致，inactive是指經過多長時間文件沒被請求后刪除緩存。
open_file_cache max=65535 inactive=60s;   

#這個是指多長時間檢查一次緩存的有效信息。
open_file_cache_valid 80s;
#open_file_cache指令中的inactive參數時間內文件的最少使用次數，如果超過這個數字，文件描述符一直是在緩存中打開的，如下例，如果有一個文件在inactive時間內一次沒被使用，它將被移除。
open_file_cache_min_uses 1;

　　2.3、HTTP全局配置模塊

　　2.3.1、定義MIME-Type

#設定mime類型,類型由mime.type文件定義
include       mime.types;
#指定默認文件類型，默認為text/plain。MIME-Type指的是網絡資源的媒體類型，也即前端請求的資源類型include指令將mime.types文件包含進來
default_type  application/octet-stream;

　　我們通過cat mime.types來查看mime.types文件內容，我們發現其就是一個types結構，里面包含了各種瀏覽器能夠識別的MIME類型以及對應類型的文件后綴名字，如下所示：

　　2.3.2、自定義服務日志

　　指令格式：access_log path [format]，適用于HTTP全局模塊、Server全局模塊。

　　path：自定義服務日志的路徑 + 名稱

　　format：可選項，自定義服務日志的字符串格式。

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';
log_format  log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';

#用了log_format指令設置了日志格式之后，需要用access_log指令指定日志文件的存放路徑；
access_log  logs/access.log  main;
access_log  logs/host.access.404.log  log404;

　　日志格式如下所示：

$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
$remote_user：用來記錄客戶端用戶名稱；
$time_local： 用來記錄訪問時間與時區；
$request： 用來記錄請求的url與http協議；
$status： 用來記錄請求狀態；成功是200，
$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
$http_referer：用來記錄從那個頁面鏈接訪問過來的；
$http_user_agent：記錄客戶瀏覽器的相關信息；

　　注意：通常web服務器放在反向代理的后面，這樣就不能獲取到客戶的IP地址了，通過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，可以增加x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。

　　2.3.3、緩存配置

　　open_file_cache max指令指定緩存是否啟用，可以適用于在HTTP全局模塊、server全局模塊以及location模塊進行使用，如下所示：

# 這個將為打開文件指定緩存，默認是沒有啟用的，max指定緩存數量，建議和打開文件數一致，inactive是指經過多長時間文件沒被請求后刪除緩存。
open_file_cache max=65535 inactive=60s;

# 語法:open_file_cache_errors on | off ，默認值:off
# 配置適用模塊:http, server, location，這個指令指定是否在搜索一個文件是記錄cache錯誤。
open_file_cache_errors on

#語法:open_file_cache_min_uses number 默認值:1 
# 配置適用模塊:http, server, location，這個指令指定了在open_file_cache指令無效的參數中一定的時間范圍內可以使用的最小文件數,如果使用更大的值,文件描述符在cache中總是打開狀態.
open_file_cache_min_uses 2

# 語法:open_file_cache_valid time 默認值:60 
# 配置適用模塊:http, server, location 這個指令指定了何時需要檢查open_file_cache中緩存項目的有效信息.
open_file_cache_valid 30s

　　2.3.4、允許sendfile方式傳輸文件

　　sendfile參數用于開啟高效文件傳輸模式，也就是基于IO的零拷貝技術，其配置說明如下：

# sendfile指令指定nginx是否調用sendfile函數(zero copy方式)來輸出文件，對于普通應用，必須設為on。
# 如果用來進行下載等應用磁盤IO重負載應用，可設置為off，以平衡磁盤與網絡IO處理速度，降低系統uptime。
# 默認為off，可以在http塊，server塊，location塊。
sendfile on | off;  
# size>0，則Nginx進程的每個worker process每次調用sendfile()傳輸的數據了最大不能超出此值；若size=0則表示不限制。默認值為0
sendfile_max_chunk size;  #如100K
# 在FreeBSD上使用TCP_NOPUSH套接字選項， 在Linux上使用TCP_CORK套接字選項。 在Linux和FreeBSD 4.*上將響應頭和正文的開始部分一起發送；此選項僅在使用sendfile的時候使用。
tcp_nopush on;
#  這個選項僅在將連接轉變為長連接的時候才被啟用。將tcp_nopush和tcp_nodelay兩個指令設置為on用于防止網絡阻塞；
tcp_nodelay on;

　　2.3.5、HttpGzip模塊配置

　　gzip模塊支持在線實時壓縮輸出數據流，瀏覽器請求會告訴服務端當前瀏覽器支持的壓縮類型，服務端會將數據根據瀏覽器支持的壓縮類型進行壓縮返回。瀏覽器請求時會附帶支持的壓縮類型，如下圖所示：

　　配置示例及含義如下：

# 用于設置開啟或者關閉gzip模塊，“gzip on”表示開啟GZIP壓縮，實時壓縮輸出數據流；
gzip on;
# 設置允許壓縮的頁面最小字節數，頁面字節數從header頭的Content-Length中獲取。默認值是0，不管頁面多大都進行壓縮。建議設置成大于1K的字節數，小于1K可能會越壓越大；
gzip_min_length 1K
# 表示申請4個單位為16K的內存作為壓縮結果流緩存，默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果；
gzip_buffers 4 16k;
# 用于設置識別HTTP協議版本，默認是1.1，目前大部分瀏覽器已經支持GZIP解壓，使用默認即可；
gzip_http_version 1.1;
# 用來指定GZIP壓縮比(1~9)，1 壓縮比最小，處理速度最快；9 壓縮比最大，傳輸速度快，但處理最慢，也比較消耗cpu資源；
gzip_comp_level 2;
# 用來指定壓縮的類型，無論是否指定，“text/html”類型總是會被壓縮的；
gzip_types text/plain application/json application/x-javascript application/css application/xml application/xml+rss 
　　　　text/javascript application/x-httpd-php image/jpeg image/gif image/png image/x-ms-bmp;

# 選項可以讓前端的緩存服務器緩存經過GZIP壓縮的頁面，例如用Squid緩存經過Nginx壓縮的數據。
gzip_vary on;

　　效果如下所示(原始文件+效果)：

　　2.3.6、負載均衡配置

　　upstream是Nginx的HTTP Upstream模塊，這個模塊通過一個簡單的調度算法來實現客戶端IP到后端服務器的負載均衡。upstream常見參數如下：

service：反向服務地址 加端口。
weight：權重。
max_fails：允許請求失敗的次數，默認為1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤；并認為主機已掛掉則，踢出。
fail_timeout：踢出后重新探測時間，也就是在經歷了max_fails次失敗后，暫停服務的時間。max_fails可以和fail_timeout一起使用。
down：表示當前的server暫時不參與負載均衡；
backup：預留的備份機器。當其他所有的非backup機器出現故障或者忙的時候，才會請求backup機器，因此這臺機器的壓力最輕；
max_conns：允許最大連接數。
slow_start：當節點恢復，不立即加入,而是等待 slow_start 后加入服務對列。

　　注意：當負載調度算法為ip_hash時，后端服務器在負載均衡調度中的狀態不能是weight和backup。

　　upstream支持以下幾種負載均衡算法，配置如下所示：

輪詢(默認)

　　每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。

upstream backserver {
　　server 192.168.0.14;
　　server 192.168.0.15;
}

指定權重

　　指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。

upstream backserver {
　　server 192.168.0.14 weight=8;
　　server 192.168.0.15 weight=10;
}

ip_hash(IP綁定)

　　每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決分布式session的問題。

upstream backserver {
　　ip_hash;
　　server 192.168.0.14:8888;
　　server 192.168.0.15:8080;
}

least_conn最少連接優先

　　把請求轉發給連接數較少的后端服務器。輪詢算法是把請求平均的轉發給各個后端，使它們的負載大致相同；但是有些請求占用的時間很長，會導致其所在的后端負載較高。這種情況下，least_conn這種方式就可以達到更好的負載均衡效果。

upstream backserver {
    least_conn; #把請求轉發給連接數較少的后端服務器
    server localhost:8080 weight=2;
    server localhost:8081;
    server localhost:8082 backup;
    server localhost:8083 max_fails=3 fail_timeout=20s;
}

fair(第三方)

　　按后端服務器的響應時間來分配請求，響應時間短的優先分配。

upstream backserver {
    server server1;
    server server2;
    fair;
}

url_hash(第三方)

　　按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。

upstream backserver {
　　server squid1:3128;
　　server squid2:3128;
　　hash $request_uri;
　　hash_method crc32;
}

　　2.3.7、其他配置文件

server_names_hash_bucket_size 128;
# 保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。
# 參數hash bucket size總是等于hash表的大小，并且是一路處理器緩存大小的倍數。在減少了在內存中的存取次數后，使在處理器中加速查找hash表鍵值成為可能。
# 如果hash bucket size等于一路處理器緩存的大小，那么在查找鍵的時候，最壞的情況下在內存中查找的次數為2。
# 第一次是確定存儲單元的地址，第二次是在存儲單元中查找鍵 值。因此，如果Nginx給出需要增大hash max size 或 hash bucket size的提示，那么首要的是增大前一個參數的大小。

client_header_buffer_size 4k;
# 客戶端請求頭部的緩沖區大小。這個可以根據你的系統分頁大小來設置，一般一個請求的頭部大小不會超過1k，不過由于一般系統分頁都要大于1k，所以這里設置為分頁大小。
# 分頁大小可以用命令getconf PAGESIZE取得。

large_client_header_buffers 8 128k;
# 客戶請求頭緩沖大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，如果header過大，它會使用large_client_header_buffers來讀取。

client_max_body_size 300m;
# 設定通過nginx上傳文件的大小。

proxy_connect_timeout 90; 
#后端服務器連接的超時時間_發起握手等候響應超時時間。

proxy_read_timeout 180;
# 連接成功后_等候后端服務器響應時間_其實已經進入后端的排隊之中等候處理（也可以說是后端服務器處理請求的時間）。

proxy_send_timeout 180;
# 后端服務器數據回傳時間_就是在規定時間之內后端服務器必須傳完所有的數據。

proxy_buffer_size 256k;
# 設置從被代理服務器讀取的第一部分應答的緩沖區大小，通常情況下這部分應答中包含一個小的應答頭。
# 默認情況下這個值的大小為指令proxy_buffers中指定的一個緩沖區的大小，不過可以將其設置為更小。

proxy_buffers 4 256k;
# 設置用于讀取應答（來自被代理服務器）的緩沖區數目和大小，默認情況也為分頁大小，根據操作系統的不同可能是4k或者8k

proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
# 設置在寫入proxy_temp_path時數據的大小，預防一個工作進程在傳遞文件時阻塞太長

proxy_temp_path /data0/proxy_temp_dir;
# proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區

proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;
# 設置內存緩存空間大小為200MB，1天沒有被訪問的內容自動清除，硬盤緩存空間大小為30GB。

keepalive_timeout 120;
# keepalive超時時間。

client_body_buffer_size 512k;
# 如果把它設置為比較大的數值，例如256k，那么，無論使用firefox還是IE瀏覽器，來提交任意小于256k的圖片，都很正常。
# 如果注釋該指令，使用默認的client_body_buffer_size設置，也就是操作系統頁面大小的兩倍，8k或者16k，問題就出現了。
# 無論使用firefox4.0還是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤

proxy_intercept_errors on;
# 表示使nginx阻止HTTP應答代碼為400或者更高的應答。

　　2.4、Server全局模塊

listen 80;
# listen用于指定虛擬主機的服務端口。
server_name 192.168.8.18 cszhi.com;
# server_name用來指定IP地址或者域名，多個域名之間用空格分開。
index index.html index.htm index.php;
# index用于設定訪問的默認首頁地址。
root /wwwroot/www.cszhi.com
# root指令用于指定虛擬主機的網頁根目錄，這個目錄可以是相對路徑，也可以是絕對路徑。
charset gb2312;
# Charset用于設置網頁的默認編碼格式。
access_log logs/www.ixdba.net.access.log main;
# access_log用來指定此虛擬主機的訪問日志存放路徑，最后的main用于指定訪問日志的輸出格式。
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
# 錯誤頁，如果返回對應錯誤碼則跳到對應錯誤頁面

　　2.5、location模塊

　　2.5.1、location模塊語法

　　location URL配置塊位于Server模塊之內，URL地址匹配是進行Nginx配置中最靈活的部分。 location支持正則表達式匹配，也支持條件判斷匹配，用戶可以通過location指令實現Nginx對動、靜態網頁進行過濾處理。使用location URL匹配配置還可以實現反向代理，用于實現PHP動態解析或者負載負載均衡。location語法為是 location[=|～|～*|^～|@]/uri/{……} ，uri前面的方括號中的內容是可選項，解釋如下：

/ 基于uri目錄匹配。
= 表示把URI作為字符串，以便與參數中的uri做完全匹配。
～表示正則匹配URI時是字母大小寫敏感的。
～* 表示正則匹配URI時忽略字母大小寫問題。
^～表示正則匹配URI時只需要其前半部分與uri參數匹配即可。

　　2.5.2、正則優先級

　　如果根據匹配規則，多條location命中，則按照優先級進行匹配，其流程如下流程圖所示：

優先級：(location =) > (location 完整路徑) > (location ^~ 路徑) > (location ~,~* 正則順序) > (location 部分起始路徑) > (/)

　　如下所示示例：

location = / {  
   return 250; 
}
location / {  
   return 251;
} 
location /documents/ {  
   return 252;
}  
location ~ /documents/Abc {
    return 253;
}
location ^~ /images/ {
    return 254;
}
location ~* \.(gif|jpg|jpeg)$ {
    return 255; 
}
location /images/abc {
    return 256;
}
location ~ /images/abc/ {
    return 257;
}

　　測試結果如下：

http://localhost/ -> return 250
http://localhost/downloads/download.html -> return 251
http://localhost/images/1.gif -> return 254
http://localhost/images/abc -> return 256　　此處實驗和理論結果沖突，理論上該是返回254，歡迎大家實驗指正
http://localhost/images/abc/def -> return 257 此處試驗和理論結果沖突，理論上該是返回254，歡迎大家實驗指正
http://localhost/documents/document.html -> return 252
http://localhost/documents/1.jpg -> return 255
http://localhost/documents/Abc.jpg -> return 253

　　2.5.3、rewrite重定向

　　指令語法:rewrite regex replacement[flag];

　　應用位置:server、location、if

　　rewrite是實現URL重定向的重要指令，他根據regex(正則表達式)來匹配內容跳轉到replacement，結尾是flag標記。

　　如：

location /rewrite_to_baidu {
       rewrite ^/ http://www.baidu.com;
}

　　效果如下，訪問http://localhost/rewrite_to_baidu，直接跳轉到了http://www.baidu.com。

　　rewrite會用到以下語法。

last – 基本上都用這個Flag。
break – 中止rewirte，不在繼續匹配。
redirect – 返回臨時重定向的HTTP狀態302。
permanent – 返回永久重定向的HTTP狀態301。

　　注：last和break最大的不同在于，break是終止當前location的rewrite檢測,而且不再進行location匹配 - last是終止當前location的rewrite檢測,但會繼續重試location匹配并處理區塊中的rewrite規則。

last

結束當前的請求處理，用替換后的URI重新匹配location；
可理解為重寫（rewrite）后，發起了一個新請求，進入server模塊，匹配location；
如果重新匹配循環的次數超過10次，nginx會返回500錯誤；
返回302 http狀態碼；
瀏覽器地址欄顯示重地向后的url。

break

結束當前的請求處理，使用當前資源，不在執行location里余下的語句；
返回302 http狀態碼；
瀏覽器地址欄顯示重地向后的url。

　　另外，還可以通過if判斷進行rewrite，語法如下：

Syntax:    if (condition) { ... }
Default:    —
Context:    server, location

　　能作為條件的內容如下：

變量名；如果變量的值為空字符串或“ 0”，則為false；否則為true （在1.0.1版之前，任何以“ 0”開頭的字符串都被視為錯誤值。）。
使用“ =”和“ !=”運算符將變量與字符串進行比較；
將變量同使用“ ~”（區分大小寫的匹配）和“ ~*”（不區分大小寫的匹配）的正則表達式進行匹配。正則表達式也可以使用占位符用于以后通過$1..$9變量進行填充。也可使用非運算符“ !~”和“ !~*”。如果正則表達式包含“ }”或“ ;”字符，則整個表達式應用單引號或雙引號引起來。
使用“ -f”和“ !-f”運算符檢查文件是否存在；
使用“ -d”和“ !-d”運算符檢查目錄是否存在；
使用“ -e”和“ !-e”運算符檢查文件，目錄或符號鏈接是否存在；
使用“ -x”和“ !-x”運算符檢查可執行文件。

　　常見參數如下：

$args #這個變量等于請求行中的參數。
$content_length #請求頭中的Content-length字段。
$content_type #請求頭中的Content-Type字段。
$document_root #當前請求在root指令中指定的值。
$host #請求主機頭字段，否則為服務器名稱。
$http_user_agent #客戶端agent信息
$http_cookie #客戶端cookie信息
$limit_rate #這個變量可以限制連接速率。
$request_body_file #客戶端請求主體信息的臨時文件名。
$request_method #客戶端請求的動作，通常為GET或POST。
$remote_addr #客戶端的IP地址。
$remote_port #客戶端的端口。
$remote_user #已經經過Auth Basic Module驗證的用戶名。
$request_filename #當前請求的文件路徑，由root或alias指令與URI請求生成。
$query_string #與$args相同。
$scheme #HTTP方法（如http，https）。
$server_protocol #請求使用的協議，通常是HTTP/1.0或HTTP/1.1。
$server_addr #服務器地址，在完成一次系統調用后可以確定這個值。
$server_name #服務器名稱。
$server_port #請求到達服務器的端口號。
$request_uri #包含請求參數的原始URI，不包含主機名，如：”/foo/bar.php?arg=baz”。
$uri #不帶請求參數的當前URI，$uri不包含主機名，如”/foo/bar.html”。
$document_uri #與$uri相同。

　　示例：

# 多目錄轉成參數 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;
}

# 所有路徑為 /images/*.png|jpg的請求都轉發到/test下，try_files會依次順序訪問接下來的路徑，前一個路徑不存在則訪問下一個。
# 如下例，要是$arg_file不存在則最后會返回"image not found exception"
location / {
    rewrite '^/images/(.*)\.(png|jpg)$' /test?file=$1.$2;
    set $image_file $1;
    set $image_type $2;
}
location /test {
   root html;
   try_files /$arg_file /image404.html;
}
location /image404.html {
    return 404 "image not found exception";
}

　　最后一個示例如下所示：

　　2.5.4、proxy_pass

　　proxy_pass主要用作代理轉發，相較rewrite，proxy_pass不影響瀏覽器地址欄的url。在nginx中配置proxy_pass代理轉發時，如果在proxy_pass后面的url加/，表示絕對根路徑；如果沒有/，表示相對路徑，把匹配的路徑部分也給代理走。

假設下面四種情況分別用 http://192.168.1.1/proxy/test.html 進行訪問。
# 第一種：代理到URL：http://127.0.0.1/test.html
location /proxy/ {
    proxy_pass http://127.0.0.1/;
}
# 第二種（相對于第一種，最后少一個 / ），代理到URL：http://127.0.0.1/proxy/test.html
    location /proxy/ {
proxy_pass http://127.0.0.1;
}
# 第三種：代理到URL：http://127.0.0.1/aaa/test.html
location /proxy/ {
    proxy_pass http://127.0.0.1/aaa/;
}
# 第四種（相對于第三種，最后少一個 / ），代理到URL：http://127.0.0.1/aaatest.html
location /proxy/ {
    proxy_pass http://127.0.0.1/aaa;
}

# 另外可與負載均衡upstream進行配合使用，如下所示，會被負載到：http://30.4.4.4:9999/proxy/test.html或者http://30.4.4.5:8888/proxy/test.html
upstream apptest {
    server 30.4.4.4:9999;
    server 30.4.4.5:8888;
}
location /proxy {
    proxy_pass http://apptest;
    proxy_set_header Host whhealth.org.cn:2005;        
}

　　2.5.5、deny、allow

　　Nginx的deny和allow指令是由ngx_http_access_module模塊提供，Nginx安裝默認內置了該模塊。除非在安裝時有指定 --without-http_access_module。

　　語法：allow/deny address | CIDR | unix: | all

　　它表示，允許/拒絕某個ip或者一個ip段訪問.如果指定unix:,那將允許socket的訪問。注意：unix在1.5.1中新加入的功能。在nginx中，allow和deny的規則是按順序執行的。

# 示例1：這段配置值允許192.168.0.0/24網段和127.0.0.1的請求，其他來源IP全部拒絕。
location / {
    allow 192.168.0.0/24;
    allow 127.0.0.1;
    deny all;
}
# 示例2：訪問的uri中包含admin的請求，只允許110.21.33.121這個IP的請求。
location ~ "admin" {
    allow 110.21.33.121;
    deny all
}
# 禁止多個目錄
location ~ ^/(cron|templates)/ {
    deny all;
    break;
}

　　效果如下所示：

3、常見場景配置

　　3.1、日常常見操作

#第一個必選規則是直接匹配網站根，通過域名訪問網站首頁比較頻繁，使用這個會加速處理，官網如是說。  
#這里是直接轉發給后端應用服務器了，也可以是一個靜態首頁  
location = / {  
    proxy_pass http://tomcat:8080/index  
}  

# 第二個必選規則是處理靜態文件請求，這是nginx作為http服務器的強項  
# 有兩種配置模式，目錄匹配或后綴匹配,任選其一或搭配使用  
location ^~ /static/ {  
    root /webroot/static/;  
}  
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {  
    root /webroot/res/;  
}  

# 第三個規則就是通用規則，用來轉發動態請求到后端應用服務器  
# 非靜態文件請求就默認是動態請求 
location / {  
    proxy_pass http://tomcat:8080/  
}

　　3.2、日志切割

　　我們可以通過crontab生成定時任務，定時對nginx日志進行歸檔。

# 列出當前用戶的定時任務crontab
crontab -l
# 編輯crontab
crontab -e
# 分 時 日 月 星期 command
MAILTO=“”
0 0 * * * sh /usr/local/nginx/logs/rotate.sh
# 重啟crontab
systemctl restart crond.service
# 查看crontab狀態
systemctl status crond.service

　　編寫rotate.sh腳本進行日志歸檔操作。

#!/bin/bash
log_path="/usr/local/nginx/logs/"
datetime=$(date -d "-1 day" "+%Y%m%d")
mkdir -p $log_path/history
mv $log_path/access.log $log_path/history/access.log_$datetime.log
mv $log_path/error.log $log_path/history/error.log_$datetime.log

# 像Nginx主進程發送USR1信號重新生成日志文件
kill -USE1 $(cat $log_path/nginx.pid)

　　3.3、反向代理

　　正向代理，是指客戶端與目標服務器之間增加一個代理服務器，客戶端直接訪問代理服務器，在由代理服務器訪問目標服務器并返回客戶端并返回。這個過程當中客戶端需要知道代理服務器地址，并配置連接。

# 正向代理
location = /baidu.html {
    proxy_pass http://www.baidu.com;
}

　　反向代理，是指客戶端訪問目標服務器，在目標服務內部有一個統一接入網關將請求轉發至后端真正處理的服務器并返回結果。這個過程當中客戶端不需要知道代理服務器地址，代理對客戶端而言是透明的。

# 反向代理
location = /fox {
    proxy_pass http://127.0.0.1:8080/;
}

　　代理相關參數

proxy_pass # 代理服務
proxy_redirect off; # 是否允許重定向
proxy_set_header Host $host; # 傳 header 參數至后端服務
proxy_set_header X-Forwarded-For $remote_addr; # 設置request header 即客戶端IP地址 proxy_connect_timeout 90; # 連接代理服務超時時間
proxy_send_timeout 90; # 請求發送最大時間
proxy_read_timeout 90; # 讀取最大時間
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

　　3.4、代理緩存

　　代理緩存,獲取服務器端內容進行緩存，詳情可參考官網，http://nginx.org/en/docs/http/ngx_http_proxy_module.html

#proxy_cache_path 緩存路徑
#levels 緩存層級及目錄位數
#keys_zone 緩存區內存大小
#inactive 有效期
proxy_cache_path /tmp/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
    server {
        listen 80;
        server_name  localhost *.yuanma.com;
        location / {
          proxy_set_header Host   $host;
          proxy_set_header X-Real-IP  $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_pass http://backend/;
        proxy_cache my_cache; #以全路徑md5值作為Key
        proxy_cache_key $host$uri$is_args$args;
    }
}

　　緩存參數詳細說明:

　　緩存清除，添加ngx_cache_purge模塊，步驟如下：

#下載ngx_cache_purge 模塊包
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
#查看已安裝模塊
./sbin/nginx -V
#進入nginx安裝包目錄 重新構建 --add-module為模塊解壓的全路徑
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with- http_ssl_module --with-debug --add-module=/root/ngx_cache_purge-2.3
#重新編譯
make
#熱升級
kill -SIGUSR2 nginx的pid號

　　清除緩存配置如下：

location ~ /clear(/.*) { 
　　#允許訪問的IP
　　allow 192.168.3.1;
　　#禁止訪問的IP
　　deny all; 
　　#配置清除指定緩存區和路徑(與proxy_cache_key一致)         
　　proxy_cache_purge my_cache $host$1$is_args$args;
}

　　3.5、下載限速

　　3.6、https轉http

　　生成自簽名證書，http://www.rzrgm.cn/hnxxcxg/p/7610582.html

# 使用openssl工具生成一個RSA私鑰
openssl genrsa -des3 -out server.key 1024 # 生成CSR(證書簽名請求)
openssl req -new -key server.key -out server.csr # 刪除私鑰中的密碼
openssl rsa -in server.key -out server.key
# 生成自簽名證書
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

　　配置https服務 : http://nginx.org/en/docs/http/configuring_https_servers.html

http {
    #監聽本機443端口為https協議
    server {
        listen  443 ssl;
        server_name  localhost;

        ssl_certificate      cert.pem;    #SSL證書路徑
        ssl_certificate_key  cert.key;    #SSL證書key路徑

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {
            proxy_pass http://localhost:8080    #將監聽443的https服務轉發到本機的8080 http服務
        }
   }
}

　　3.7、websocket請求轉發

posted on 2021-04-22 20:37 kosamino 閱讀(1086) 評論(0) 收藏舉報