本文介紹如何將NGINX配置作為Web服務(wù)器,并包括以下部分:
在高層次上,將NGINX配置作為Web服務(wù)器有一些問題需要了解,定義它處理哪些URL以及如何處理這些URL上的資源的HTTP請求。 在較低層次上,配置定義了一組控制對特定域或IP地址的請求的處理的虛擬服務(wù)器。
用于HTTP流量的每個虛擬服務(wù)器定義了稱為位置的特殊配置實(shí)例,它們控制特定URI集合的處理。 每個位置定義了自己的映射到此位置的請求發(fā)生的情況。 NGINX可以完全控制這個過程。 每個位置都可以代理請求或返回一個文件。 此外,可以修改URI,以便將請求重定向到另一個位置或虛擬服務(wù)器。 此外,可以返回特定的錯誤代碼,也可以配置特定的頁面以對應(yīng)于每個錯誤代碼。
NGINX配置文件必須至少包含一個服務(wù)器指令來定義虛擬服務(wù)器。 當(dāng)NGINX處理請求時,它首先選擇提供請求的虛擬服務(wù)器。
虛擬服務(wù)器由http
上下文中的服務(wù)器指令定義,例如:
http {
server {
# Server configuration
}
}
可以將多個server
指令添加到http
上下文中以定義多個虛擬服務(wù)器。server
配置塊通常包括一個listen
指令,用于指定服務(wù)器偵聽請求的IP地址和端口(或Unix域套接字和路徑)。IPv4和IPv6地址均被接受; 將方括號(。
下面的示例顯示了監(jiān)聽IP地址127.0.0.1
和端口8080
的服務(wù)器的配置:
server {
listen 127.0.0.1:8080;
# The rest of server configuration
}
如果省略端口,則使用標(biāo)準(zhǔn)端口。 同樣地,如果省略一個地址,服務(wù)器將偵聽所有地址。 如果沒有包含listen指令,則“標(biāo)準(zhǔn)”端口為80/tcp
,“default”端口為8000/tcp
,具體取決于超級用戶權(quán)限。
如果有多個服務(wù)器與請求的IP地址和端口相匹配,則NGINX將根據(jù)服務(wù)器塊中的server_name
指令測試請求的主機(jī)頭域。 server_name
的參數(shù)可以是完整(精確)名稱,通配符或正則表達(dá)式。 通配符是一個字符串,其開頭,結(jié)尾或兩者都包含星號(*
); 星號匹配任何字符序列。 NGINX將Perl語法用于正則表達(dá)式; 在它們之前使用波浪號(?
)。 此示例說明了一個確切的名稱。
server {
listen 80;
server_name example.org www.example.org;
...
}
如果匹配主機(jī)頭幾個名稱,則NGINX通過按以下順序搜索名稱并使用其找到的第一個匹配來選擇一個:
*.example.org
mail.*
如果主機(jī)頭字段與服務(wù)器名稱不匹配,則NGINX會將請求路由到請求到達(dá)端口的默認(rèn)服務(wù)器。 默認(rèn)服務(wù)器是nginx.conf
文件中列出的第一個服務(wù)器,除非您將listen_server
參數(shù)包含在listen
指令中以明確指定服務(wù)器為默認(rèn)值。
server {
listen 80 default_server;
...
}
一個完整的Nginx虛擬機(jī)配置示例,這里我們演示配置兩個虛擬機(jī),對應(yīng)域名分別為:vhost1.com
和 vhost2.com
,vhost1.com
網(wǎng)站的主目錄在/data/www/vhost1
,vhost2.com
網(wǎng)站的主目錄在/data/www/vhost2
:
server {
listen 80;
server_name vhost1.com www.vhost1.com;
index index.html index.html;
root /data/www/vhost1;
access_log /var/log/vhost1.com.log;
}
server {
listen 80;
server_name vhost2.com www.vhost2.com;
index index.html index.html;
root /data/www/vhost2;
access_log /var/log/vhost2.com.log;
}
NGINX可以根據(jù)請求URI向不同的代理發(fā)送流量或提供不同的文件。 這些塊是使用放置在server
指令中的location
指令來定義的。
例如,您可以定義三個location
塊,以指示虛擬服務(wù)器向一個代理服務(wù)器發(fā)送一些請求,將其他請求發(fā)送到不同的代理服務(wù)器,并通過從本地文件系統(tǒng)傳遞文件來提供其余請求。
NGINX測試根據(jù)所有location
指令的參數(shù)請求URI,并應(yīng)用匹配location
中定義的指令。 在每個location
塊內(nèi),通??赡?除了一些例外)放置更多的location
指令以進(jìn)一步細(xì)化特定組請求的處理。
注意:在本教程文章中,單詞
location
是指單個location
上下文。
location
指令有兩種類型的參數(shù):前綴字符串(路徑名)和正則表達(dá)式。 對于要匹配前綴字符串的請求URI,必須以前綴字符串開頭。
具有pathname
參數(shù)的以下示例位置匹配以/some/path/
開頭的請求URI,例如/some/path/document.html
,它不匹配/my-site/some/path
,因為/some/path
不在該URI的開頭出現(xiàn)。
location /some/path/ {
...
}
正則表達(dá)式之前是區(qū)分大小寫匹配的波形符號(~
),或者不區(qū)分大小寫匹配的波形符號(~*
)。 以下示例將包含字符串.html
或.html
的URI與任何位置相匹配。
location ~ \.html? {
...
}
要找到最符合URI的位置,NGINX首先將URI與前綴字符串的位置進(jìn)行比較。然后用正則表達(dá)式搜索位置。
除非使用^~
修飾符對正則表達(dá)式給予更高的優(yōu)先級。在前綴字符串中,NGINX選擇最具體的字符串(也就是最長和最完整的字符串)。 下面給出了選擇處理請求的位置的確切邏輯:
=
(等號)修飾符定義了URI和前綴字符串完全匹配。如果找到完全匹配,則搜索停止。^~
(插入符號)修飾符預(yù)先添加最長匹配前綴字符串,則不會檢查正則表達(dá)式。=
修飾符的典型用例是/
(正斜杠)的請求。 如果請求/
是頻繁的,則指定=/
作為location
指令的參數(shù)加速處理,因為搜索匹配在第一次比較之后停止。
location = / {
...
}
location
上下文可以包含定義如何解析請求的指令 - 提供靜態(tài)文件或?qū)⒄埱髠鬟f給代理的服務(wù)器。 在以下示例中,匹配第一個location
上下文的請求將從/data/images
目錄中提供文件,并將匹配第二個位置的請求傳遞給承載 www.example.com
域內(nèi)容的代理服務(wù)器。
server {
location /images/ {
root /data;
}
location / {
proxy_pass http://www.example.com;
}
}
root
指令指定要在其中搜索要提供的靜態(tài)文件的文件系統(tǒng)路徑。 與該位置相關(guān)聯(lián)的請求URI將附加到路徑,以獲取要提供的靜態(tài)文件的全名。 在上面的示例中,要響應(yīng)/images/logo.png
的請求,NGINX提供服務(wù)器本地實(shí)際對應(yīng)文件是:/data/images/logo.png
。
proxy_pass
指令將請求傳遞給使用配置的URL訪問代理服務(wù)器。然后將代理服務(wù)器的響應(yīng)傳回客戶端。在上面的示例中,所有不以/images/
開頭的URI的請求都將被傳遞給代理的服務(wù)器(也就是:www.example.com
)。
可以使用配置文件中的變量,使NGINX進(jìn)程的請求根據(jù)定義的情況而有所不同。 變量是在運(yùn)行時計算的命名值,用作指令的參數(shù)。 一個變量由它的名字開頭的$
(美元)符號表示。 變量根據(jù)NGINX的狀態(tài)定義信息,例如正在處理的請求的屬性。
有許多預(yù)定義的變量,如核心HTTP變量,您可以使用set
,map
和geo
指令定義自定義變量。 大多數(shù)變量在運(yùn)行時計算的,并包含與特定請求相關(guān)的信息。 例如,$remote_addr
包含客戶端IP地址,$uri
保存當(dāng)前的URI值。
一些網(wǎng)站URI需要立即返回具有特定錯誤或重定向代碼的響應(yīng),例如當(dāng)頁面被暫時移動或永久移動時。 最簡單的方法是使用return
指令。 例如返回未找到的404
狀態(tài)碼:
location /wrong/url {
return 404;
}
返回的第一個參數(shù)是響應(yīng)代碼。可選的第二個參數(shù)可以是重定向的URL(代碼301
,302
,303
和307
)或在響應(yīng)體中返回文本。 例如:
location /permanently/moved/url {
return 301 http://www.example.com/moved/here;
}
返回指令可以包含在 location
和 server
上下文中。
可以通過使用rewrite
指令在請求處理期間多次修改請求URI,該指令具有一個可選參數(shù)和兩個必需參數(shù)。 第一個(必需)參數(shù)是請求URI必須匹配的正則表達(dá)式。 第二個參數(shù)是用于替換匹配URI的URI。 可選的第三個參數(shù)是可以停止進(jìn)一步重寫指令的處理或發(fā)送重定向(代碼301
或302
)的標(biāo)志。例如:
location /users/ {
rewrite ^/users/(.*)$ /show?user=$1 break;
}
如該示例所示,用戶通過匹配正則表達(dá)式捕獲第二個參數(shù)。
您可以在location
和 server
上下文中包含多個rewrite
指令。 NGINX按照它們發(fā)生的順序逐個執(zhí)行指令。 當(dāng)選擇該上下文時,server
上下文中的rewrite
指令將被執(zhí)行一次。
在NGINX處理一組rewrite
指令之后,它根據(jù)新的URI選擇一個location
上下文。 如果所選location
塊包含rewrite
指令,則依次執(zhí)行它們。 如果URI與其中任何一個匹配,則在處理所有定義的rewrite
指令之后,將搜索新location
塊。
以下示例顯示了與返回指令相結(jié)合的rewrite
指令。
server {
...
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra last;
return 403;
...
}
此示例配置區(qū)分兩組URI。 諸如/download/some/media/file
之類的URI更改為/download/some/mp3/file.mp3
。由于最后一個標(biāo)志,所以跳過后續(xù)指令(第二次rewrite
和return
指令),但NGINX繼續(xù)處理該請求,該請求現(xiàn)在具有不同的URI。類似地,諸如/download/some/audio/file
的URI被替換為/download/some/mp3/file.ra
。 如果URI與rewrite
指令不匹配,則NGINX將403
錯誤代碼返回給客戶端。
有兩個中斷處理重寫指令的參數(shù):
last
- 停止執(zhí)行當(dāng)前服務(wù)器或位置上下文中的重寫指令,但是NGINX會搜索與重寫的URI匹配的位置,并且應(yīng)用新位置中的任何重寫指令(URI可以再次更改,往下繼續(xù)匹配)。break
- 像break
指令一樣,在當(dāng)前上下文中停止處理重寫指令,并取消搜索與新URI匹配的位置。新位置(location
)塊中的rewrite
指令不執(zhí)行。有時您需要重寫或更改HTTP響應(yīng)中的內(nèi)容,將一個字符串替換為另一個字符串。 您可以使用sub_filter
指令來定義要應(yīng)用的重寫。 該指令支持變量和替代鏈,使更復(fù)雜的更改成為可能。
例如,您可以更改引用除代理服務(wù)器之外的絕對鏈接:
location / {
sub_filter /blog/ /blog-staging/;
sub_filter_once off;
}
另一個示例將方法從http://
更改為http://
,并從請求頭域替換本地主機(jī)地址到主機(jī)名。 sub_filter_once
指令告訴NGINX在一個位置(location
)內(nèi)連續(xù)應(yīng)用sub_filter
偽指令:
location / {
sub_filter 'href="http://127.0.0.1:8080/' 'href="http://$host/';
sub_filter 'img src="http://127.0.0.1:8080/' 'img src="http://$host/';
sub_filter_once on;
}
請注意,如果發(fā)生另一個sub_filter
匹配,則使用sub_filter
修改的響應(yīng)部分將不再被替換。
使用error_page
指令,您可以配置NGINX返回自定義頁面以及錯誤代碼,替換響應(yīng)中的其他錯誤代碼,或?qū)g覽器重定向到其他URI。 在以下示例中,error_page
指令指定要返回404
頁面錯誤代碼的頁面(/404.html
)。
error_page 404 /404.html;
請注意,此偽指令并不立即返回該錯誤(返回指令執(zhí)行該操作),而僅僅是指定發(fā)生時如何處理錯誤。 錯誤代碼可以來自代理服務(wù)器,或者在NGINX處理期間發(fā)生(例如,當(dāng)NGINX找不到客戶端請求的文件時,顯示404
對應(yīng)的結(jié)果)。
在以下示例中,當(dāng)NGINX找不到頁面時,它會將代碼301
替換為代碼404
,并將客戶端重定向到http:/example.com/new/path.html
。 當(dāng)客戶端仍嘗試訪問其舊URI的頁面時,此配置非常有用。 301
代碼通知瀏覽器頁面已經(jīng)永久移動,并且需要在返回時自動替換舊地址。
location /old/path.html {
error_page 404 =301 http:/example.com/new/path.html;
}
以下配置是在未找到文件時將請求傳遞給后端的示例。 因為在error_page
指令的等號之后沒有指定狀態(tài)代碼,所以對客戶機(jī)的響應(yīng)具有代理服務(wù)器返回的狀態(tài)代碼(不一定是404
)。
server {
...
location /images/ {
# Set the root directory to search for the file
root /data/www;
# Disable logging of errors related to file existence
open_file_cache_errors off;
# Make an internal redirect if the file is not found
error_page 404 = /fetch$uri;
}
location /fetch/ {
proxy_pass http://backend/;
}
}
當(dāng)沒有找到文件時,error_page
指令指示NGINX進(jìn)行內(nèi)部重定向。 error_page
指令的最終參數(shù)中的$uri
變量保存當(dāng)前請求的URI,該URI在重定向中被傳遞。
例如,如果沒有找到/images/some/file
,它將被替換為/fetch/images/some/file
,并且新的搜索位置(location
)開始。最后請求最終在第二個location
上下文中,并被代理到http://backend/
。
如果沒有找到文件,則open_file_cache_errors指令可防止寫入錯誤消息。 因為丟失的文件可被正確地處理,但這不是必需的。