摘要：如果狀態(tài)碼附帶文字段落，該文本將被放置在響應(yīng)主體。相反，如果狀態(tài)碼后面是一個(gè)，該將成為頭部值。沒有狀態(tài)碼的將被視為一個(gè)狀態(tài)碼，這種情況下需要以或者開頭。因?yàn)楹筒荒芎?jiǎn)單的只返回狀態(tài)碼，還必須有重定向的，這就是指令無法返回的原因了。

server模塊是http的子模塊，它用來定義一個(gè)虛擬主機(jī)

例子：

server {
    listen      80;
    server_name localhost www.example.com;
    root        /Users/yangyi/www;# 全局定義，表示在該server下web的根目錄
    index       index.php index.html index.htm; 
    charset     utf-8;
    access_log  logs/host.access.log  main; #用來指定此虛擬主機(jī)的訪問日志存放路徑，輸出格式為main。
    error_log   logs/host.error.log  error; #錯(cuò)誤日志存放路徑，輸出格式為error。
    error_page  404  /404.html; #狀態(tài)碼為404時(shí)的時(shí)候的網(wǎng)頁地址,還可定義500,502之類的
    ....
}

以上一些配置為在該server下具有全局性，例如 root，可在location中重新定義root

用來指定IP地址或者域名，多個(gè)域名之間用空格分開

當(dāng)我們想定義多個(gè)server監(jiān)聽同一個(gè)端口但訪問的host不一樣時(shí)，server_name就派上用場(chǎng)了。nginx會(huì)根據(jù)HTTP請(qǐng)求的header Host選擇nginx配置文件里符合條件的server_name的server配置

匹配順序如下

完全匹配的server_name;

后綴匹配: *.example.com;

前綴匹配: www.example.*;

正則匹配: ~w+.com;

listen指令里配置了default或default_server的server;如｀l(xiāng)isten 80 default｀

第一個(gè)匹配上listen的server。

所以當(dāng)我們監(jiān)聽的的端口只有一個(gè)server配置的時(shí)候，server_name 可以不填

兩者作用差不多，區(qū)別在于最終映射的地址不同，例：

location /request_path/image/ {
    # 如果現(xiàn)在訪問 /request_path/image/a/b.jpg,root映
    # 射的地址為/local_path/image/request_path/image/a/b.jpg,
    # 而alias為/local_path/image/a/b.jpg
    root    /local_path/image/;
    alias   /local_path/image/; 
}

語法：error_page code ... [=[response]] uri
使用字段: http, server, location, if in location

產(chǎn)生的效果為內(nèi)部跳轉(zhuǎn)(internal redirect)，即用戶頁面地址不變，但內(nèi)容實(shí)際上為設(shè)置的uri對(duì)應(yīng)的內(nèi)容
我們也可以自定義設(shè)置返回的狀態(tài)碼，如：
error_page 502 503 =200 /50x.html;
這樣用戶訪問產(chǎn)生502 、503的時(shí)候給用戶的返回狀態(tài)是200，內(nèi)容是50x.html。
還有一種寫法是 = 后面不帶狀態(tài)碼，是針對(duì)相應(yīng)的內(nèi)容不是一個(gè)靜態(tài)的頁面，最終返回的狀態(tài)碼取決于對(duì)應(yīng)url服務(wù)返回的狀態(tài)碼。

最主要和最復(fù)雜的配置，通過定位和解析url，判斷該選擇什么配置，支持正則和條件判斷；

簡(jiǎn)單例子，匹配所有請(qǐng)求

location / {
    root   /home/www/html;
    index  index.php index.html index.htm;
}

一個(gè)正則匹配的例子：

# 匹配.php結(jié)尾的請(qǐng)求
location ~ .php$ {
    ....
}

一個(gè)反向代理的例子：

# 匹配到/api開頭的路由時(shí)候，將請(qǐng)求轉(zhuǎn)發(fā)到http://192.168.0.1，但是通常不是直接填寫地址，而是設(shè)置一個(gè)`upstream`配置，后面會(huì)提到
location /api {
    proxy_pass  http://192.168.0.1; #請(qǐng)求轉(zhuǎn)向地址192.168.0.1
    #不修改被代理服務(wù)器返回的響應(yīng)頭中的location頭
    proxy_redirect off;
    #使用nginx反向代理后，如果要使服務(wù)獲取真實(shí)的用戶信息，用以下的設(shè)置
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

vue-router、react-router等路由框架要開啟history模式可以選擇的nginx配置的例子

location / {
  alias     static/;
  try_files $uri $uri/ /index.html;
}

location的匹配規(guī)則和順序

第一種是 = 類型，表示精確匹配，優(yōu)先級(jí)最高，一旦匹配到忽略之后的正則匹配

^~ 類型，表示前綴匹配，是字符串開頭匹配而非正則匹配，當(dāng)匹配到該規(guī)則時(shí)，停止往下面的搜索，所以如果存在兩個(gè)^~ 匹配的時(shí)候要注意有順序之分。優(yōu)先級(jí)比正則高。

~ 和 ~*,正則匹配，兩者區(qū)別是后者不區(qū)分大小寫。有順序之分，匹配到第一個(gè)正則停止搜索。

/uri,普通字符串匹配，無順序之分，會(huì)選擇匹配長(zhǎng)度最長(zhǎng)的配置。

/ 通用匹配，匹配所有請(qǐng)求

還有一種特殊匹配類型 @url，只用于nginx內(nèi)部跳轉(zhuǎn)，例:

location / {
    root /var/www/html;
    error_page 404 @40x;
}
location @40x {
  root /var/www/errors/40x.html;
}

upstream后端服務(wù)器提供簡(jiǎn)單的負(fù)載均衡（輪循調(diào)度和客戶端 IP）。

例子：

upstream backend  {
  server backend1.example.com weight=5;
  server backend2.example.com:8080;
  server unix:/tmp/backend3;
}
 
server {
  location / {
    proxy_pass  http://backend;
  }
}

有常用兩種負(fù)載均衡支持調(diào)度算法，分別是 weight 和 ip_hash 。weight 模式下可以為每個(gè) server 設(shè)置weight值，weight值越大，分配到的訪問機(jī)率越高，ip_hash 為同一個(gè)ip的
分配同一個(gè)后端服務(wù)器，這樣我們不用解決session共享問題。

include指令 使nginx配置更加靈活，將部分配置直接拆分出來,分成不同的配置文件

例子：

http {
    include mime.types;
    include vhost/*.conf; # 虛擬主機(jī)配置
}

mime type 和 文件擴(kuò)展名的對(duì)應(yīng)關(guān)系一般放在 mime.types 里，然后 用 include mime.types;
mime.types作用：通過文件的擴(kuò)展名設(shè)置了Content-Type，Nginx如果沒找到對(duì)應(yīng)文件的擴(kuò)展名的話，就使用默認(rèn)的Type，默認(rèn)Type通用 default_type 定義，比如 default_type application/octet-stream ;
完整的 mime.types 配置：https://github.com/h5bp/server-configs-nginx/blob/master/mime.types

一個(gè)虛擬主機(jī)對(duì)一個(gè)文件配置，放到vhost文件夾下面，然后通過include指令包含進(jìn)來，這樣更便于維護(hù)和管理

gzip 壓縮，用來對(duì)靜態(tài)資源進(jìn)行壓縮，需要客戶端同時(shí)支持才有效。

配置：

http {
    #開啟gzip壓縮
    gzip  on;
    #IE6的某些版本對(duì)gzip的壓縮支持很不好,故關(guān)閉
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    #HTTP1.0以上的版本都啟動(dòng)gzip
    gzip_http_version 1.0；
    #指定哪些類型的相應(yīng)才啟用gzip壓縮，多個(gè)用空格分隔
    gzip_types 
    application/javascript 
    application/json 
    text/css 
    text/plain;
    # 壓縮等級(jí)，可選1-9，值越大壓縮時(shí)間越長(zhǎng)壓縮率越高，
    # 通常選5，能壓縮到原來的1/4
    gzip_comp_level 5;
}

rewrite模塊配合很多模塊一起使用，包含幾個(gè)指令：

break

if

return

rewrite

rewrite_log

set

uninitialized_variable_warn

這里簡(jiǎn)單介紹下break、if、return，重點(diǎn)介紹 rewrite

語法: break;
使用字段: server, location, if
此指令的意思是停止執(zhí)行當(dāng)前虛擬主機(jī)的后續(xù)rewrite指令集

例子

# 如果訪問的文件名不存在，反向代理到localhost 。這里的break也是停止rewrite檢查
if (!-f $request_filename) {
    break;
    proxy_pass http://127.0.0.1;
}

語法: if (condition) { ... }
使用字段: server, location
if 判斷一個(gè)條件，如果條件成立，則后面的大括號(hào)內(nèi)的語句將執(zhí)行，相關(guān)配置從上級(jí)繼承。

條件(conditon)可以是如下任何操作：

當(dāng)表達(dá)式只是一個(gè)變量時(shí)，如果值為空或任何以0開頭的字符串都會(huì)當(dāng)做false；

使用“=”和“!=”比較一個(gè)變量和字符串；

使用“~”做正則表達(dá)式匹配，“~*”做不區(qū)分大小寫的正則匹配，“!~”做區(qū)分大小寫的正則不匹配；

使用“-f”和“!-f” 檢查一個(gè)文件是否存在；

使用“-d”和“!-d”檢查一個(gè)目錄是否存在；

使用“-e”和“!-e”檢查一個(gè)文件、目錄、符號(hào)鏈接是否存在；

使用“-x”和“ !-x”檢查一個(gè)文件是否可執(zhí)行；

# 如果提交方法為POST，則返回狀態(tài)405（Method not allowed）
if ($request_method = POST) {
    return 405;
}

語法: return code [text];
return code URL;
return URL;
使用字段: server, location, if
停止處理并為客戶端返回狀態(tài)碼，非標(biāo)準(zhǔn)的444狀態(tài)碼將關(guān)閉連接，不發(fā)送任何響應(yīng)頭?？梢允褂玫臓顟B(tài)碼有：204，400，402-406，408，410, 411, 413, 416與500-504。如果狀態(tài)碼附帶文字段落，該文本將被放置在響應(yīng)主體。相反，如果狀態(tài)碼后面是一個(gè)URL，該URL將成為location頭部值。沒有狀態(tài)碼的URL將被視為一個(gè)302狀態(tài)碼，這種情況下URL需要以“http://”, “https://”, 或者 “$scheme”開頭。

語法: rewrite regex replacement [flag];
使用字段: server, location, if
使用nginx提供的全局變量或自己設(shè)置的變量，然后結(jié)合正則表達(dá)式和標(biāo)志位實(shí)現(xiàn)url重寫以及重定向。多條 rewrite 順序靠前且匹配的優(yōu)先執(zhí)行。可以通過設(shè)置 flag 停止繼續(xù)處理。如果replacement 以“http://”, “https://”, 或者 “$scheme”開頭，那么將立即停止處理并臨時(shí)重定向給客戶端。

flag可以是如下參數(shù)：

last，完成該rewrite規(guī)則的執(zhí)行后，停止處理后續(xù)rewrite指令集；然后查找匹配改變后URI的新location；

break，完成該rewrite規(guī)則的執(zhí)行后，停止處理后續(xù)rewrite指令集，并不再重新查找；但是當(dāng)前l(fā)ocation內(nèi)剩余非rewrite語句和location外的的非rewrite語句可以執(zhí)行；

redirect，返回302臨時(shí)重定向，地址欄會(huì)顯示跳轉(zhuǎn)后的地址；

permanent，返回301永久重定向，地址欄會(huì)顯示跳轉(zhuǎn)后的地址；即表示如果客戶端不清理瀏覽器緩存，那么返回的結(jié)果將永久保存在客戶端瀏覽器中了。

因?yàn)?01和302不能簡(jiǎn)單的只返回狀態(tài)碼，還必須有重定向的URL，這就是return指令無法返回301,302的原因了。兩種重定向的方式對(duì)客戶端來說是一樣的，就是重新加載另外一個(gè)url。我們?cè)趯?shí)際設(shè)置中推薦只使用永久重定向，因?yàn)榕R時(shí)重定向可能造成在url為A頁面，但顯示的是B頁面的內(nèi)容，造成網(wǎng)址劫持。

比較難以理解的是 last 和 break，讓我們先了解 nginx 運(yùn)行的11個(gè)階段，注意到第四階段：

typedef enum {  
    NGX_HTTP_POST_READ_PHASE = 0,   //讀取請(qǐng)求頭  
  
    NGX_HTTP_SERVER_REWRITE_PHASE,   //執(zhí)行rewrite  
  
    NGX_HTTP_FIND_CONFIG_PHASE,  //根據(jù)uri替換location  
    NGX_HTTP_REWRITE_PHASE,      //根據(jù)替換結(jié)果繼續(xù)執(zhí)行rewrite  
    NGX_HTTP_POST_REWRITE_PHASE, //執(zhí)行rewrite后處理  
  
    NGX_HTTP_PREACCESS_PHASE,    //認(rèn)證預(yù)處理   請(qǐng)求限制，連接限制  
  
    NGX_HTTP_ACCESS_PHASE,       //認(rèn)證處理  
    NGX_HTTP_POST_ACCESS_PHASE,  //認(rèn)證后處理， 認(rèn)證不通過， 丟包  
  
    NGX_HTTP_TRY_FILES_PHASE,    //嘗試try標(biāo)簽  
    NGX_HTTP_CONTENT_PHASE,      //內(nèi)容處理  
  
    NGX_HTTP_LOG_PHASE           //日志處理  
} ngx_http_phases;  

所以我們?cè)賮砝斫鈒ast與break的區(qū)別：
last： 停止當(dāng)前這個(gè)請(qǐng)求，并根據(jù)rewrite匹配的規(guī)則重新發(fā)起一個(gè)請(qǐng)求。新請(qǐng)求又從第一階段開始執(zhí)行…
break：相對(duì)last，break并不會(huì)重新發(fā)起一個(gè)請(qǐng)求，只是跳過當(dāng)前的rewrite階段，并執(zhí)行本請(qǐng)求后續(xù)的執(zhí)行階段…

通過實(shí)例會(huì)更加清晰的理解

server {
    listen 80 default_server;
    server_name dcshi.com;
    root www;

    location /break/ {
        rewrite ^/break/(.*) /test/$1 break;
        echo "break page";
    } 

    location /last/ {
         rewrite ^/last/(.*) /test/$1 last;
         echo "last page";
    }    

    location /test/ {
       echo "test page";
    }
}

請(qǐng)求:http://dcshi.com/break/*
輸出: break page
分析：正如上面討論所說，break是跳過當(dāng)前請(qǐng)求的rewrite階段，并繼續(xù)執(zhí)行本請(qǐng)求的其他階段，很明顯，對(duì)于/foo 對(duì)應(yīng)的content階段的輸出為 echo “break page”; (content階段，可以簡(jiǎn)單理解為產(chǎn)生數(shù)據(jù)輸出的階段，如返回靜態(tài)頁面內(nèi)容也是在content階段；echo指令也是運(yùn)行在content階段，一般情況下content階段只能對(duì)應(yīng)一個(gè)輸出指令，如同一個(gè)location配置兩個(gè)echo，最終只會(huì)有一個(gè)echo指令被執(zhí)行)；當(dāng)然如果你把/break/里的echo 指令注釋，然后再次訪問/break/xx會(huì)報(bào)404，這也跟我們預(yù)期一樣：雖然/break/xx被重定向到/test/xx,但是break指令不會(huì)重新開啟一個(gè)新的請(qǐng)求繼續(xù)匹配，所以nginx是不會(huì)匹配到下面的/test/這個(gè)location；在echo指令被注釋的情況下，/break/ 這location里只能執(zhí)行nginx默認(rèn)的content指令，即嘗試找/test/xx這個(gè)html頁面并輸出起內(nèi)容，事實(shí)上，這個(gè)頁面不存在，所以會(huì)報(bào)404的錯(cuò)誤。

請(qǐng)求: http://dcshi.com/last/*
輸出: test page
分析: last與break最大的不同是，last會(huì)重新發(fā)起一個(gè)新請(qǐng)求，并重新匹配location，所以對(duì)于/last,重新匹配請(qǐng)求以后會(huì)匹配到/test/,所以最終對(duì)應(yīng)的content階段的輸出是test page;

解釋完了 last 和 break ，我們?cè)賹懸粋€(gè)實(shí)例用來說明 rewrite 可以做什么事情。通過rewrite將不帶www的請(qǐng)求統(tǒng)一轉(zhuǎn)向?yàn)閣ww：

server {
    # ........
    server_name www.abc.com ;//只留一個(gè)
    # ......
｝

server {
  server_name  abc.com;
  rewrite ^(.*)$ http://www.abc.com$1 permanent; 
}

或者是：

server {
   listen 80;
   server_name abc.com www.abc.com;
   if ( $host != "www.abc.com"  ) {
       rewrite ^/(.*) http://www.abc.com/$1 permanent;
   }
   location / {
       root /data/www/www;
       index index.html index.htm;
   }
}

參考：

http://tool.oschina.net/apidocs/apidoc?api=nginx-zh

https://www.jianshu.com/p/bed000e1830b

http://blog.sina.com.cn/s/blog_4f9fc6e10102ux0w.html