區塊鏈網路nginx

Ⅰ nginx 配置詳解是什麼

Nginx是lgor Sysoev為俄羅斯訪問量第二的rambler.ru站點設計開發的。從2004年發布至今，憑借開源的力量，已經接近成熟與完善。

Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。

Nginx的穩定性、功能集、示例配置文件和低系統資源的消耗讓他後來居上，在全球活躍的網站中有12.18%的使用比率，大約為2220萬個網站。

1、全局塊：配置影響nginx全局的指令。一般有運行nginx伺服器的用戶組，nginx進程pid存放路徑，日誌存放路徑，配置文件引入，允許生成worker process數等。

2、events塊：配置影響nginx伺服器或與用戶的網路連接。有每個進程的最大連接數，選取哪種事件驅動模型處理連接請求，是否允許同時接受多個網路連接，開啟多個網路連接序列化等。

3、http塊：可以嵌套多個server，配置代理，緩存，日誌定義等絕大多數功能和第三方模塊的配置。如文件引入兄升晌，mime-type定義，日誌自定義，是否使用sendfile傳輸文件，連接超時時間，單連接請求數等。

4、server塊：配置虛擬主機的相關參數，一個http中可以有多個server。

5、location塊：配置請求的路由，以及各種頁面的處理情況。

Nginx常用功能。

1、Http代理，反向代理：作為web伺服器最常用的功能之一，尤其是反向代理。

Nginx在做反向代理時，提供性能穩定，並且能夠提供配置靈活的轉發功能。Nginx可以根據不同的正則匹配，採取不同的轉發策略，比如圖片文件結尾的走文件伺服器，動態頁面走web服務羨鋒器，只要你正則寫的沒問題，又有相對應的伺服器解決方案。

。並且Nginx對返回結果進行錯誤頁跳轉笑手，異常判斷等。如果被分發的伺服器存在異常，他可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。

2、負載均衡

Nginx提供的負載均衡策略有2種：內置策略和擴展策略。內置策略為輪詢，加權輪詢，Ip hash。擴展策略，就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他一一找出來做下實現。

Ⅱ 07《Nginx 入門教程》Nginx 的 Http 模塊介紹（上）

本部分內容將詳細介紹 Nginx 中對 Http請求的 11 個處理階段，分成 3 個小節講解並進行相關實驗操作。

Nginx 將一個 Http 請求分成多個階段，以模塊為單位進行處理。其將 Http請求的處理過程分成了 11 個階段，各個階段可以包含任意多個 Http 的模塊並以流水線的方式處理請求。這 11 個 Http 階段如下所示：

網上有人做了一個非常形象的圖片，如下圖所示。我們可以看到 11 個階段的處理順序，以及每個階段中涉及到的相關模塊以及模塊之間的順序。

POST_READ 階段是 Nginx 接收到 Http 請求完整頭部後的處理階段，這里主要使用的是 realip 模塊獲取用戶的真實地址，方便後續對該 IP 進行限速或者過濾其請求等。

SERVER_REWRITE 和後面的 REWRITE 階段一般是使用 rewrite 模塊修改 Http請求的 uri，實現請求的控制。

FIND_CONFIG 階段只是做 location 的匹配項。

PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 請求訪問許可權相關的階段。PREACCESS 階段是在連接之前要做的訪問控制, 這個階段有 limit_conn 和 limit_req 等模塊工作。ACCESS 階段是解決用戶能不能訪問，比如根據用戶名、密碼限制用戶訪問(auth_basic 模塊)、根據 ip 限制用戶訪問(access 模塊)以及第三方模塊認證限制用戶的訪問(auth_request模塊)。POST_ACCESS 是在 ACCESS 之後要做的一些工作。

TRY_FILES 階段為訪問靜態文件資源而設置的。有時候又稱之為 PRECONTENT 階段，即在 CONTENT 階段之前做的事情。主要是 try_files 模塊在此階段工作。

最重要的 CONTENT 是處理 Http 請求內容的階段，大部分 HTTP 模塊介入這個階段，比如 index、autoindex、concat 以及反向代理的模塊都是在這里生效的。

LOG 是處理完請求後的日誌記錄階段，如 access_log 模塊。

realip 模塊是在 postread 階段生效的，它的作用是: 當本機的 nginx 處於一個反向代理的後端時獲取到真實的用戶 ip。 如果沒有 realip 模塊，Nginx 中的 $remote_addr 可能就不是客戶端的真實 ip 了，而是代理主機的 ip。
realip模塊的配置實例如下:

set_real_ip_from 是指定我們信任的後端代理伺服器，real_ip_header 是告訴 nginx 真正的用戶 ip 是存在 X-Forwarded-For 請求頭中的。

當 real_ip_recursive 設置為 off 時，nginx 會把 real_ip_header 指定的 Http頭中的最後一個 ip 當成真實 ip;

而當 real_ip_recursive 為 on 時，nginx 會把 real_ip_header 指定的 Http頭中的最後一個不是信任伺服器的 ip (前面設置的set_real_ip_from)當成真實 ip。通過這樣的手段，最後拿到用戶的真實 ip。

rewrite 模塊可以看到它在 SERVER_REWRITE 和 REWRITE 階段都有介入。rewrite 模塊的主要功能是改寫請求的 uri。它是 Nginx 默認安裝的模塊。rewrite 模塊會根據正則匹配重寫 uri，然後發起內部跳轉再匹配 location, 或者直接做30x重定向返回客戶端。rewrite 模塊的指令有 break, if, return, rewrite, set 等，這些都是我們常用到的。

return 指令返回後，Http 請求將在 return 的階段終止，後續階段將無法進行，所以許多模塊得不到執行。

1、將 regex 指定的 url 替換成 replacement 這個新的 url,可以使用正則表達式及變數提取。

2、當 replacement 以 http:// 或者 https:// 或者 $schema 開頭，則直接返回 302 重定向

3、替換後的 url 根據 flag 指定的方式進行處理

if 指令的條件表達式:

location 匹配是在 FIND_CONFIG 階段進行的，我們需要掌握 location 的匹配規則和匹配順序。

有一個簡單總結如下：

即：

realip 模塊默認沒有被編譯進 Nginx 的，我們需要在源碼編譯階段使用–with-http_realip_mole，將 realip 模塊編譯進來後方可使用。接下來，我們做個簡單測試，首先准備一個 server 塊如下：

首先，我們將 real_ip_recursive 設置為 off，然後做一次請求:

這里返回的是頭部參數 X-Forwarded-For 中最後一個 ip，如果將 real_ip_recursive 設置為 on，此時，由於 set_real_ip_from 中設置218.19.206.164為信任的方向代理 ip，那麼 Nginx 會往前找一位，認為 1.1.1.1 是用戶的真實ip。

我們寫一個簡單配置如下：

先測試if指令，當請求方法為 POST 時，我們能得到 『post request!』 這樣的字元串輸出。GET 請求時候，針對 404 情況，會跳轉到/403.html，我們准備一個 403.html 頁面，裡面寫上』403, forbidden!』 這一行內容，開始下面的 Http 請求:

如果我們打開 return 405 這行指令，則 error_page 將不會生效，連同後面的 location 匹配也不會生效。無論我們發送如何請求，都會返回405的錯誤信息。這是因為 server 中的 return 指令是在 SERVER_REWRITE中執行的，而 location 匹配則是在下一個階段 FIND_CONFIG 中執行的，所以上一個階段在 return 後，根本不會進入後面的階段執行。

首先，我們准備環境，首先是新建一個目錄 third（全路徑為/root/test/third），再該目錄下新建一個文件 3.txt, 裡面只有一行內容 『hello, world』。接下來，我們准備一個 server 塊，加到 Http 指令塊中:

上述配置中，要打開 rewrite_log指令，這樣我們可以看到 rewrite 指令的相應日誌，方便查看結果。

當我們在 /second 配置中，使用 break 時，請求命令:

如果是不使用 break 標識，則請求結果如下:

首先是 /first/3.txt 請求在 /first 中匹配，並被替換為 /second/3.txt， last 標識表示將繼續進行匹配，在 /second 中，uri 又被 rewrite 成 /third/3.txt, 如果後面跟了 break 標識，表示 rewrite 到此結束，不會執行後面的 return 指令，直接請求靜態資源 /third/3.txt,得到其內容』hello, world』;如果是沒有 break 標識，則會在執行 return 指令後直接返回，並不會繼續執行下去，最後返回』second!'字元串。

我們按照這樣的 location 規則，進行匹配實驗，結果如下：

這里介紹了 Nginx 處理 Http 請求的 11 個階段，並重點介紹了 前三個階段POST_READ、REWRITE以及FIND_CONFIG以及這些階段中涉及到的模塊和指令。前面講到的指令都是 Nginx 中的高頻指令，必須要熟練掌握。

Ⅲ Nginx，一看就會

Nginx("engine x") 是一個高性能的 HTTP 和反向代理伺服器,特點是佔有內存少，並發能力強，事實上 nginx 的並發能力確實在同類型的網頁伺服器中表現較好，中國大陸使用 nginx 網站用戶有：雀改網路、京東、新浪、網易、騰訊、 淘寶等。

1.1 WEB 伺服器

Nginx 可以作為靜態頁面的 web 伺服器，同時還支持 CGI 協議的動態語言，比如 perl、php

等。但是不支持 java。Java 程序只能通過與 tomcat 配合完成。Nginx 專為性能優化而開發，性能是其最重要的考量,實現上非常注重效率 ，能經受高負載的考驗,有報告表明能支持高達 50000個並發連接數。

1.2 反向代理

1.正向代理，代理客戶端，客戶端需要配置代理

2.反向代理，代理服務端，客戶端無感知

1.3 負載均衡

Nginx 的非同步框架可以處理很大的並發請求，把這些並發請求 hold 住之後就可以分發給後台服務端(backend servers，也叫做服務池， 後面簡稱 backend)來做復雜的計算、處理和響應，這種模式的好處是相當多的：隱藏業務主機更安全，節約了公網 IP 地址，並且在業務量增加的時候可以方頃碧判便地擴容後台伺服器。

這時候集群的概念產生了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的服器，也就是我們所說的負載均衡。

1.4 動靜分離

為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的伺服器來解析，加快解析速度。降低原來單個伺服器的壓力。

Nginx官網

2.1 相關安裝包

pcre-8.37.tar.gz openssl-1.0.1t.tar.gz zlib-1.2.8.tar.gz nginx-1.11.1.tar.gz

2.2 安裝流程

2.1.1.安裝 pcre 解壓縮 pcre-xx.tar.gz 包

進入解壓縮目錄，執行./configure

如果提示，需要提前安裝 gcc++，進入安裝光碟目錄的軟體包(/media/CentOSXX/Package)執行

rpm -ivh libstdc+ devel-4.4.7-17.el6.x86_64.rpm

rpm -ivh gcc-c+ 4.4.7-17.el6.x86_64.rpm

./configure 完成後，回到 pcre 目錄下執行 make，再執行 make install

2.2.2.安裝 openssl

解壓縮 openssl-xx.tar.gz 包。

進入解壓縮目錄，執行./config

make && make install

2.2.3.安裝 zlib 解壓縮 zlib-xx.tar.gz 包。

進入解壓縮目錄，執行./configure。

make && make install

2.2.4.安裝 nginx

解壓縮 nginx-xx.tar.gz 包。

進入解壓縮目錄，執行./configure。

make && make install

查看開放的埠號

firewall-cmd --list-all

設置開放的埠號

firewall-cmd --add-service=http –permanent

sudo firewall-cmd --add-port=80/tcp --permanent

重啟防火牆

firewall-cmd –reload

2.3 Nginx 啟動

命令

啟動命令：在/usr/local/nginx/sbin 目錄下執行 ./nginx

關閉命令: 在/usr/local/nginx/sbin 目錄下執行 ./nginx -s stop

重新載入命令: 在/usr/local/nginx/sbin 目錄下執行 ./nginx -s reload·

設置 nginx 為自啟動服務

修改慧差 linux 啟動腳本/etc/rc.d/rc

加入 :/usr/local/nginx/sbin/nginx

nginx 安裝目錄下，其默認的配置文件都放在conf 目錄下，而主配置文件nginx.conf 也在其中，後續對 nginx 的使用基本上都是對此配置文件進行相應的修改。

根據上述文件，我們可以很明顯的將 nginx.conf 配置文件分為三部分

第一部分：全局塊

從配置文件開始到 events 塊之間的內容，主要會設置一些影響 nginx 伺服器整體運行的配置指令，主要包括配置運行 Nginx 伺服器的用戶（組）、允許生成的 worker process 數，進程 PID 存放路徑、日誌存放路徑和類型以及配置文件的引入等。

比如上面第一行配置的：worker_processes 1;

這是 Nginx 伺服器並發處理服務的關鍵配置，worker_processes 值越大，可以支持的並發處理量也越多，但是會受到硬體、軟體等設備的制約。

第二部分：events 塊

events 塊涉及的指令主要影響 Nginx 伺服器與用戶的網路連接，常用的設置包括是否開啟對多 work process 下的網路連接進行序列化，是否允許同時接收多個網路連接，選取哪種事件驅動模型來處理連接請求，每個 word process 可以同時支持的最大連接數等。

上述例子就表示每個 work process 支持的最大連接數為 1024.

這部分的配置對 Nginx 的性能影響較大，在實際中應該靈活配置。

第三部分：http 塊

這算是 Nginx 伺服器配置中最頻繁的部分，代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這里。

需要注意的是：http 塊也可以包括 http 全局塊、server 塊。

http 全局塊

http 全局塊配置的指令包括文件引入、MIME-TYPE 定義、日誌自定義、連接超時時間、單鏈接請求數上限等。

server 塊

這塊和虛擬主機有密切關系，虛擬主機從用戶角度看，和一台獨立的硬體主機是完全一樣的，該技術的產生是為了節省互聯網伺服器硬體成本。

每個 http 塊可以包括多個 server 塊，而每個 server 塊就相當於一個虛擬主機。

而每個 server 塊也分為全局 server 塊，以及可以同時包含多個 locaton 塊。

全局 server 塊

最常見的配置是本虛擬機主機的監聽配置和本虛擬主機的名稱或 IP 配置。

location 塊

一個 server 塊可以配置多個 location 塊。

這塊的主要作用是基於 Nginx 伺服器接收到的請求字元串（例如 server_name/uri-string），對虛擬主機名稱（也可以是 IP 別名）之外的字元串（例如 前面的 /uri-string）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能，還有許多第三方模塊的配置也在這里進行。

案例配置如下：

location 指令說明

該指令用於匹配 URL，語法如下：

= ：用於不含正則表達式的 uri 前，要求請求字元串與 uri 嚴格匹配，如果匹配

成功，就停止繼續向下搜索並立即處理該請求。

~：用於表示 uri 包含正則表達式，並且區分大小寫。

~*：用於表示 uri 包含正則表達式，並且不區分大小寫。

^~：用於不含正則表達式的 uri 前，要求 Nginx 伺服器找到標識 uri 和請求字

符串匹配度最高的 location 後，立即使用此 location 處理請求，而不再使用 location

塊中的正則 uri 和請求字元串做匹配。

注意：如果 uri 包含正則表達式，則必須要有 ~ 或者 ~* 標識。

案例配置如下：

在 linux 下有 Nginx、LVS、Haproxy 等等服務可以提供負載均衡服務，而且 Nginx 提供了幾種分配方式(策略)：

輪詢（默認）

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

weight

weight 代表權重，默認為 1，權重越高被分配的客戶端越多指定輪詢幾率，weight 和訪問比率成正比，用於後端伺服器性能不均的情況。

ip_hash

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

fair（第三方）

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

動靜分離從目前實現角度來講大致分為兩種：

1.一種是純粹把靜態文件獨立成單獨的域名，放在獨立的伺服器上，也是目前主流推崇的方案；

2.另外一種方法就是動態跟靜態文件混合在一起發布，通過 nginx 來分開。

通過 location 指定不同的後綴名實現不同的請求轉發。通過 expires 參數設置，可以使瀏覽器緩存過期時間，減少與伺服器之前的請求和流量。具體 Expires 定義：是給一個資源設定一個過期時間，也就是說無需去服務端驗證，直接通過瀏覽器自身確認是否過期即可，所以不會產生額外的流量。此種方法非常適合不經常變動的資源。（如果經常更新的文件，不建議使用 Expires 來緩存），我這里設置 3d，表示在這 3 天之內訪問這個 URL，發送一個請求，比對伺服器該文件最後更新時間沒有變化，則不會從伺服器抓取，返回狀態碼304，如果有修改，則直接從伺服器重新下載，返回狀態碼 200。

master-workers 的機制的好處

首先，對於每個 worker 進程來說，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開銷，

同時在編程以及問題查找時，也會方便很多。其次，採用獨立的進程，可以讓互相之間不會

影響，一個進程退出後，其它進程還在工作，服務不會中斷，master 進程則很快啟動新的

worker 進程。當然，worker 進程的異常退出，肯定是程序有 bug 了，異常退出，會導致當

前 worker 上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。

需要設置多少個 worker

Nginx 同 redis 類似都採用了 io 多路復用機制，每個 worker 都是一個獨立的進程，但每個進

程里只有一個主線程，通過非同步非阻塞的方式來處理請求， 即使是千上萬個請求也不在話

下。每個 worker 的線程可以把一個 cpu 的性能發揮到極致。所以 worker 數和伺服器的 cpu

數相等是最為適宜的。設少了會浪費 cpu，設多了會造成 cpu 頻繁切換上下文帶來的損耗。

連接數 worker_connection

這個值是表示每個 worker 進程所能建立連接的最大值，所以，一個 nginx 能建立的最大連接數，應該是 worker_connections * worker_processes。當然，這里說的是最大連接數，對於HTTP 請 求 本 地 資 源 來 說 ， 能 夠 支 持 的 最 大 並 發 數 量 是 worker_connections * worker_processes，如果是支持 http1.1 的瀏覽器每次訪問要佔兩個連接，所以普通的靜態訪問最大並發數是： worker_connections * worker_processes /2，而如果是 HTTP 作 為反向代理來說，最大並發數量應該是 worker_connections *

worker_processes/4。因為作為反向代理伺服器，每個並發會建立與客戶端的連接和與後端服務的連接，會佔用兩個連接。

注意：此部分屬於高級技術，近幾日會將下面的知識點補充完畢。

8.1 Keepalived+Nginx 高可用集群（主從模式）

8.2 Keepalived+Nginx 高可用集群（雙主模式）

Ⅳ nginx如何配置代理

nginx源碼： https://trac.nginx.org/nginx/browser

nginx官網： http://www.nginx.org/

... #全局塊

events { #events塊

...

}

http #http塊

{

}

1、全局塊：全局模塊影響nginx的全局指令，一般有運行nginx伺服器的用戶，nginx進程pid存放路勁，日誌存放路徑，配置文件引入，允許生成worker，process數。

2、events塊：配置影響nginx伺服器或與用戶的網路連接， ，有每個進程的最大連接數，選取哪種事件驅動模型處理連接請求，是否允許同時接受多個連接，開啟多個網路連接序列化。

3、http塊：可以嵌套多個server，配置代理，緩存

4、server塊：配置虛擬主機參數，一個http中有多個server

5、location塊：配置請求的路由。

########### 每個指令必須有分號結束。#################

error_log log/error.log debug; #制定日誌路徑，級別。這個設置可以放入全局塊，http塊，server塊，級別以此為：

debug|info|notice|warn|error|crit|alert|emerg

events {

} http {

}

四、nginx的簡單命令

五、配置解析

server {

1、location 支持配置項目的絕對路徑

2、假設我們的後台API地址是以API開頭，location ^~ /user/ 代表nginx將會攔截請求地址中包含"/user/"字樣的請求，洞敗其實這就是我們的ajax請求路徑，攔截到請求之後根據寫法會分成兩種情況把這個請求轉發到 下面 proxy_pass 的地址上。

舉個例子納逗顫:

a、如上圖，如果proxy_pass 的URL以 / 結尾 ，那麼請求轉發的時候 將 不會 帶上 匹配到的 /api/ ，也就是說如果 登錄請求 URL是 localhost:80/user/login，proxy_pass URL 是 http://a.xx.com:8080/platform/， Nginx將會 把這個請求轉發成 http://a.xx.com:8080/platform/user/login

b、如果proxy_pass 的URL不以 / 結尾 ，那麼請求轉發的時候 將 會帶上 匹配到的 /user/ ，也就是說如果 登錄請求 URL是 localhost:60001/user/login，proxy_pass URL 是 http://a.xx.com:8080/platform/， Nginx將會 把這個請求轉發成 http://a.xx.com:8080/user/login

3、一般我們登錄之後伺服器會通過Set-Cookie把token寫回到我們本地，如果不設置 proxy_cookie_path 的話，伺服器Set-Cookie命令會失效，本地存不了cookie，從而導致token丟失。

這里proxy_cookie_path有一點需要注意的是 如果 proxy_pass URL 是 http://a.xx.com:8080/user/ 這種情況 proxy_cookie_path應該設置成 /platform/ / (注意兩個斜杠之間有空格)。

如果 proxy_pass URL 是 http://a.xx.com:8080/這種情況 proxy_cookie_path應該設置成 / / (注意兩個斜杠指盯之間有空格)

語法規則：location [=| | *|^~] /uri/ { … }

Ⅳ 跟我學Nginx，server 配置塊介紹

本文將介紹 http 配置塊下面的 server 配置塊。

在 nginx 中，一個 server 配置塊代表了一個虛擬機主機。

虛擬主機使用的是特殊的軟硬體技術，它把一台運行在網際網路上的伺服器主機分成多台 「虛擬」 的主機，每台虛擬主機都可以是一個獨立的網擾隱站，可以具有獨立的域名，具有完整的 Internet 伺服器功能（WWW、FTP、Email 等等），同一台主機上的虛擬主機之間是完全獨立的。

從網站訪問者來看，每一台虛擬主機和一台獨立主機完全一樣。

利用虛擬主機，不用為每個要運行的網站提供一台單獨的 Nginx 伺服器或單獨運行一組 Nginx 進程。虛擬主機提供了在同一台伺服器、同一組 Nginx 進程上運行多個網站的功能。

在 Nginx 配置文件（nginx.conf）中，一個最簡化的虛擬主機配置如下：

上面配置中，server 配置塊配置了一個監聽州段 8080 埠的虛擬主機。其中其他參數如下：

Nginx 通過 listen 指令指定的值監聽網路請求，可以是 IP 協議的形式，也可以是 UNIX 域套接字。如果不設置 listen 指令，Nginx 在以超級用戶運行時則監聽 80 埠，以非超級用戶運行時則監聽 8000 埠。

listen 指令的指令值還針對監聽方式提供了豐富的參數，如下所示：

用法示例：

server_name 指令主要用於配置基於名稱的虛擬主機，server_name 指令在接到客戶請求後的匹配順序分別為：

（1）准確的 server_name 匹配，例如：

（2）以 * 通配符開始的字元串：

（3）以 * 通配符結束的字元串：

（4）匹配正則表達式：

Nginx 將按照上面1、2、3、4順序對 server_name 進行匹配緩跡廳，只要有一項匹配 server_name 後就會停止繼續匹配。

該指令用來指定日誌文件的存放路徑、格式（把定義的 log_format 跟在後面）和緩存大小；如果不想啟用日誌則access_log off ;

location 指令的作用是根據用戶請求的 URI 來執行不同的操作，也就是根據用戶請求的網站 URL 匹配 location 配置塊，匹配成功就執行 location 配置塊中定義的相關操作。示例用法：

關於更多 server 配置塊的介紹將在後續章節娓娓道來。

對了，跟 Aapche 一樣，Nginx 也可以配置多種類型的虛擬主機：

（1）基於IP的虛擬主機

（2）基於域名的虛擬主機

（3）基於埠的虛擬主機

關於怎樣配置基於IP、域名和埠的虛擬主機後續章節將進行介紹。

Ⅵ nginx 配置詳解是什麼

Nginx配置文件詳解：

Nginx的主配置文件是nginx.conf，這個配置文件一共由三部分組成，分別為全局塊、events塊和http塊。在http塊中，又包含http全局塊、多個server塊。

每個server塊中，可以包含server全局塊和多個location塊。在同一配置塊中嵌套的配置塊，各個之間不存在次序渣正哪關系。

配置文件支持大量可配置的指令，絕大多數指令不是特定屬於某一個塊的。同一個指令放在不同層級清游的塊中，其作用域也不同，一般情況下，高一級塊中的指令可以作用於自身所在的塊和此塊包含的所有低層級塊。

如果某個指令在兩個不同層級的塊中同時出現，則採用「就近原則」，即以較低層級塊中的配置為准。比如，某指令同如碼時出現在http全局塊中和server塊中，並且配置不同，則應該以server塊中的配置為准。

全局塊：

全局塊是默認配置文件從開始到events塊之間的一部分內容，主要設置一些影響Nginx伺服器整體運行的配置指令，因此，這些指令的作用域是Nginx伺服器全局。

通常包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數、Nginx進程PID存放路徑、日誌的存放路徑和類型以及配置文件引入等。