? 前面我們講到關于nginx配置文件（nginx.conf）運行，工作模式，及相關調試的等等配置語法，本小節我們將會講到怎么去配置一個基本的web，以及相關配置項的定義，虛移主機以及請求的分發的語法配置，即怎么樣構建一個完整的web server 區域。

一.怎么使用HTTP核心模塊配置一個靜態Web服務器？

靜態Web服務器的主要功能由ngx_http_core_module模塊（HTTP框架的主要成員）實現，當然，一個完整的靜態Web服務器還有許多功能是由其他的HTTP模塊實現的。本節主要討論如何配置一個包含基本功能的靜態Web服務器

如下所示,為一個基本http的配置

http?{??gzip?on;?? upstream?{??…?? }?? server???{???listen?localhost:80;?…??location?/webstatic?{??if?…?{??…????}?????root?/opt/webresource;???????…?}location?~*?.(jpg|jpeg|png|jpe|gif)$?{??…??} } server???{??????…}?? }

以上即為一個簡單的靜態web配置說明參考

所有的HTTP配置項都必須直屬于http塊、server塊、location塊、upstream塊或if塊等（HTTP配置項自然必須全部在http{}塊之內，這里的“直屬于”是指配置項直接所屬的大括號對應的配置塊），同時，在描述每個配置項的功能時，會說明它可以在上述的哪個塊中存在，因為有些配置項可以任意地出現在某一個塊中，而有些配置項只能出現在特定的塊中。

Nginx為配置一個完整的靜態Web服務器提供了非常多的功能，下面會把這些配置項分為以下8類進行詳述：虛擬主機與請求的分發、文件路徑的定義、內存及磁盤資源的分配、網絡連接的設置、MIME類型的設置、對客戶端請求的限制、文件操作的優化、對客戶端請求的特殊處理。這種劃分只是為了幫助大家從功能上理解這些配置項。下面我們為大家一一介紹相應的配置說明：

1.1虛擬主機與請求的分發配置項說明

? 由于IP地址的數量有限，因此經常存在多個主機域名對應著同一個IP地址的情況，這時在nginx.conf中就可以按照server_name（對應用戶請求中的主機域名）并通過server塊來定義虛擬主機，每個server塊就是一個虛擬主機，它只處理與之相對應的主機域名請求。這樣，一臺服務器上的Nginx就能以不同的方式處理訪問不同主機域名的HTTP請求了。

[1] 監聽端口

語法：listen address:port [ default(deprecated in 0.8.21) | default_server | [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ipv6only=[on|off] | ssl ] ];

默認：listen 80;

配置塊：server

listen參數決定Nginx服務如何監聽端口。在listen后可以只加IP地址、端口或主機名，非常靈活，例如：

listen?127.0.0.1:8000;?? listen?127.0.0.1;???#注意：不加端口時，默認監聽80端口? listen?8000;?? listen?*:8000;?? listen?localhost:8000;

如果服務器使用IPv6地址，那么可以這樣使用：

listen?[::]:8000;? listen?[fe80::1];?? listen?[:::a8c9:1234]:80;

在地址和端口后，還可以加上其他參數，例如：

listen??443?default_server?ssl;?? listen??127.0.0.1?default_server?accept_filter=dataready?backlog=1024;

下面說明listen可用參數的意義。

? default：將所在的server塊作為整個Web服務的默認server塊。如果沒有設置這個參數，那么將會以在nginx.conf中找到的第一個server塊作為默認server塊。為什么需要默認虛擬主機呢？當一個請求無法匹配配置文件中的所有主機域名時，就會選用默認的虛擬主機。

default_server：同上。

backlog=num：表示TCP中backlog隊列的大小。默認為–1，表示不予設置。在TCP建立三次握手過程中，進程還沒有開始處理監聽句柄，這時backlog隊列將會放置這些新連接。可如果backlog隊列已滿，還有新的客戶端試圖通過三次握手建立TCP連接，這時客戶端將會建立連接失敗。

rcvbuf=size：設置監聽句柄的SO_RCVBUF參數。

sndbuf=size：設置監聽句柄的SO_SNDBUF 參數。

accept_filter：設置accept過濾器，只對FreeBSD操作系統有用。

deferred：在設置該參數后，若用戶發起建立連接請求，并且完成了TCP的三次握手，內核也不會為了這次的連接調度worker進程來處理，只有用戶真的發送請求數據時（內核已經在網卡中收到請求數據包），內核才會喚醒worker進程處理這個連接。這個參數適用于大并發的情況下，它減輕了worker進程的負擔。當請求數據來臨時，worker進程才會開始處理這個連接。只有確認上面所說的應用場景符合自己的業務需求時，才可以使用deferred配置。

bind：綁定當前端口/地址對，如127.0.0.1:8000。只有同時對一個端口監聽多個地址時才會生效。

ssl：在當前監聽的端口上建立的連接必須基于SSL協議。

[2]?主機名稱

語法：server_name name [...];

默認：server_name "";

配置塊：server

說明：

server_name后可以跟多個主機名稱，如server_name?www.testweb.com、download.testweb.com;。

在開始處理一個HTTP請求時，Nginx會取出header頭中的Host，與每個server中的server_name進行匹配，以此決定到底由哪一個server塊來處理這個請求。有可能一個Host與多個server塊中的server_name都匹配，這時就會根據匹配優先級來選擇實際處理的server塊。server_name與Host的匹配優先級如下：

1）首先選擇所有字符串完全匹配的server_name，如www.testweb.com。

2）其次選擇通配符在前面的server_name，如*.testweb.com。

3）再次選擇通配符在后面的server_name，如www.testweb.*。

4）最后選擇使用正則表達式才匹配的server_name，如~^\.testweb\.com$。

實際上，這個規則正是7.7節中介紹的帶通配符散列表的實現依據，同時如果Host與所有的server_name都不匹配，這時將會按下列順序選擇處理的server塊。

5）優先選擇在listen配置項后加入[default | default_server]的server塊。

6）找到匹配listen端口的第一個server塊。

[3]?重定向主機名稱的處理

語法：server_name_in_redirect on | off;

默認：server_name_in_redirect on;

配置塊：http、server或者location

該配置需要配合server_name使用。在使用on打開時，表示在重定向請求時會使用server_name里配置的第一個主機名代替原先請求中的Host頭部，而使用off關閉時，表示在重定向請求時使用請求本身的Host頭部。

[4] location用法

語法：location ?【 =|^~|~*|~|@]|/uri/ { ... 】

配置塊：server

location會嘗試根據用戶請求中的URI來匹配上面的/uri表達式，如果可以匹配，就選擇location {}塊中的配置來處理用戶請求。當然，匹配方式是多樣的，下面介紹location的匹配規則。如下為一個location參考案例

location??=?/?{ #?精確匹配?/?，主機名后面不能帶任何字符串 [?configuration?A?] }

location??/?{ #?因為所有的地址都以?/?開頭，所以這條規則將匹配到所有請求 #?但是正則和最長字符串會優先匹配 [?configuration?B?] }

location?/documents/?{ #?匹配任何以?/documents/?開頭的地址，匹配符合以后，還要繼續往下搜索 #?只有后面的正則表達式沒有匹配到時，這一條才會采用這一條 [?configuration?C?] }

location?~?/documents/Abc?{ #?匹配任何以?/documents/?開頭的地址，匹配符合以后，還要繼續往下搜索 #?只有后面的正則表達式沒有匹配到時，這一條才會采用這一條 [?configuration?CC?] }

location?^~?/p_w_picpaths/?{ #?匹配任何以?/p_w_picpaths/?開頭的地址，匹配符合以后，停止往下搜索正則，采用這一條。 [?configuration?D?] }

location?~*?\.(gif|jpg|jpeg)$?{ #?匹配所有以?gif,jpg或jpeg?結尾的請求 #?然而，所有請求?/p_w_picpaths/?下的圖片會被?config?D?處理，因為?^~?到達不了這一條正則 [?configuration?E?] }

location?/p_w_picpaths/?{ #?字符匹配到?/p_w_picpaths/，繼續往下，會發現?^~?存在 [?configuration?F?] }

location?/p_w_picpaths/abc?{ #?最長字符匹配到?/p_w_picpaths/abc，繼續往下，會發現?^~?存在 #?F與G的放置順序是沒有關系的 [?configuration?G?] }

location?~?/p_w_picpaths/abc/?{ #?只有去掉?config?D?才有效：先最長匹配?config?G?開頭的地址，繼續往下搜索，匹配到這一條正則，采用 [?configuration?H?] }

location ~* /js/.*/\.js

location參數說明

參數值	表示的含義
=	表示把URI作為字符串，以便與參數中的uri做完全匹配，即精確匹配
^~	表示匹配URI時只需要其前半部分與uri參數匹配即可
~	表示匹配URI時注意字母大小寫問題。
~*	表示匹配URI時忽略字母大小寫問題。
！~	表示區分大小寫不匹配
！~*	表示不區分大小寫不匹配
@	表示僅用于Nginx服務內部請求之間的重定向，帶有@的location不直接處理用戶請求。

location的匹配優先級

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

轉載于:https://blog.51cto.com/blief/1728377

總結

以上是生活随笔為你收集整理的Nginx基础入门之nginx基础配置项介绍(2)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。