Nginx Web服務器配置塊有哪些？

4110

nginx Web服務器配置塊有：1、設置虛擬服務器；2、配置位置；3、使用變量；4、返回特定狀態碼；5、重寫請求中的URI；6、重寫http響應；7、處理錯誤。

Nginx Web服務器配置塊有哪些？

Nginx Web服務器配置塊有：

1. 設置虛擬服務器

NGINX配置文件必須至少包含一個服務器指令來定義虛擬服務器。 當NGINX處理請求時，它首先選擇提供請求的虛擬服務器。

虛擬服務器由http上下文中的服務器指令定義，例如：

http?{ ????server?{ ????????#?Server?configuration ????} }

可以將多個server指令添加到http上下文中以定義多個虛擬服務器。

推薦教程：nginx快速入門教程

server配置塊通常包括一個listen指令，用于指定服務器偵聽請求的IP地址和端口(或unix域套接字和路徑)。IPv4和IPv6地址均被接受; 將方括號(。

下面的示例顯示了監聽IP地址127.0.0.1和端口8080的服務器的配置：

server?{ ????listen?127.0.0.1:8080; ????#?The?rest?of?server?configuration }

如果省略端口，則使用標準端口。 同樣地，如果省略一個地址，服務器將偵聽所有地址。 如果沒有包含listen指令，則“標準”端口為80/tcp，“default”端口為8000/tcp，具體取決于超級用戶權限。

如果有多個服務器與請求的IP地址和端口相匹配，則NGINX將根據服務器塊中的server_name指令測試請求的主機頭域。 server_name的參數可以是完整(精確)名稱，通配符或正則表達式。?

通配符是一個字符串，其開頭，結尾或兩者都包含星號(*); 星號匹配任何字符序列。 NGINX將perl語法用于正則表達式; 在它們之前使用波浪號(?)。 此示例說明了一個確切的名稱。

server?{ ????listen??????80; ????server_name?example.org?www.example.org; ????... }

如果匹配主機頭幾個名稱，則NGINX通過按以下順序搜索名稱并使用其找到的第一個匹配來選擇一個：

  • 確切的名字(完整準確的名稱)

  • 以星號開頭的最長通配符，例如:*.example.org

  • 以星號結尾的最長通配符，如：mail.*

  • 第一個匹配正則表達式(按照出現在配置文件中的順序)

如果主機頭字段與服務器名稱不匹配，則NGINX會將請求路由到請求到達端口的默認服務器。 默認服務器是nginx.conf文件中列出的第一個服務器，除非您將listen_server參數包含在listen指令中以明確指定服務器為默認值。

server?{ ????listen????80????default_server; ????... }

一個完整的Nginx虛擬機配置示例，這里我們演示配置兩個虛擬機，對應域名分別為：vhost1.com 和 vhost2.com，vhost1.com網站的主目錄在/data/www/vhost1，vhost2.com網站的主目錄在/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; }

2. 配置位置

NGINX可以根據請求URI向不同的代理發送流量或提供不同的文件。 這些塊是使用放置在server指令中的location指令來定義的。

例如，您可以定義三個location塊，以指示虛擬服務器向一個代理服務器發送一些請求，將其他請求發送到不同的代理服務器，并通過從本地文件系統傳遞文件來提供其余請求。

NGINX測試根據所有location指令的參數請求URI，并應用匹配location中定義的指令。 在每個location塊內，通常可能(除了一些例外)放置更多的location指令以進一步細化特定組請求的處理。

注意：在本教程文章中，單詞location是指單個location上下文。

location指令有兩種類型的參數：前綴字符串(路徑名)和正則表達式。 對于要匹配前綴字符串的請求URI，必須以前綴字符串開頭。

具有pathname參數的以下示例位置匹配以/some/path/開頭的請求URI，例如/some/path/document.html，它不匹配/my-site/some/path，因為/some/path不在該URI的開頭出現。

location?/some/path/?{ ????... }

正則表達式之前是區分大小寫匹配的波形符號(~)，或者不區分大小寫匹配的波形符號(~*)。 以下示例將包含字符串.html或.html的URI與任何位置相匹配。

location?~?.html??{ ????... }

要找到最符合URI的位置，NGINX首先將URI與前綴字符串的位置進行比較。然后用正則表達式搜索位置。

除非使用^~修飾符對正則表達式給予更高的優先級。在前綴字符串中，NGINX選擇最具體的字符串(也就是最長和最完整的字符串)。 下面給出了選擇處理請求的位置的確切邏輯：

  • 測試所有URI的前綴字符串。

  • =(等號)修飾符定義了URI和前綴字符串完全匹配。如果找到完全匹配，則搜索停止。

  • 如果^~(插入符號)修飾符預先添加最長匹配前綴字符串，則不會檢查正則表達式。

  • 存儲最長匹配的前綴字符串。

  • 根據正則表達式測試URI。

  • 斷開第一個匹配的正則表達式并使用相應的位置。

  • 如果沒有正則表達式匹配，則使用與存儲的前綴字符串相對應的位置。

=修飾符的典型用例是/(正斜杠)的請求。 如果請求/是頻繁的，則指定=/作為location指令的參數加速處理，因為搜索匹配在第一次比較之后停止。

location?=?/?{ ????... }

location上下文可以包含定義如何解析請求的指令 – 提供靜態文件或將請求傳遞給代理的服務器。 在以下示例中，匹配第一個location上下文的請求將從/data/images目錄中提供文件，并將匹配第二個位置的請求傳遞給承載 www.example.com 域內容的代理服務器。

server?{ ????location?/images/?{ ????????root?/data; ????} ????location?/?{ ????????proxy_pass?http://www.example.com; ????} }

root指令指定要在其中搜索要提供的靜態文件的文件系統路徑。 與該位置相關聯的請求URI將附加到路徑，以獲取要提供的靜態文件的全名。 在上面的示例中，要響應/images/logo.png的請求，NGINX提供服務器本地實際對應文件是：/data/images/logo.png。

proxy_pass指令將請求傳遞給使用配置的URL訪問代理服務器。然后將代理服務器的響應傳回客戶端。在上面的示例中，所有不以/images/開頭的URI的請求都將被傳遞給代理的服務器(也就是：www.example.com)。

3. 使用變量

可以使用配置文件中的變量，使NGINX進程的請求根據定義的情況而有所不同。 變量是在運行時計算的命名值，用作指令的參數。 一個變量由它的名字開頭的$(美元)符號表示。 變量根據NGINX的狀態定義信息，例如正在處理的請求的屬性。

有許多預定義的變量，如核心HTTP變量，您可以使用set，map和geo指令定義自定義變量。 大多數變量在運行時計算的，并包含與特定請求相關的信息。 例如，$remote_addr包含客戶端IP地址，$uri保存當前的URI值。

4. 返回特定狀態碼

一些網站URI需要立即返回具有特定錯誤或重定向代碼的響應，例如當頁面被暫時移動或永久移動時。 最簡單的方法是使用return指令。 例如返回未找到的404狀態碼：

location?/wrong/url?{ ????return?404; }

返回的第一個參數是響應代碼。可選的第二個參數可以是重定向的URL(代碼301,302,303和307)或在響應體中返回文本。 例如：

location?/permanently/moved/url?{ ????return?301?http://www.example.com/moved/here; }

返回指令可以包含在 location 和 server 上下文中。

重寫URI請求

可以通過使用rewrite指令在請求處理期間多次修改請求URI，該指令具有一個可選參數和兩個必需參數。 第一個(必需)參數是請求URI必須匹配的正則表達式。 第二個參數是用于替換匹配URI的URI。 可選的第三個參數是可以停止進一步重寫指令的處理或發送重定向(代碼301或302)的標志。例如：

?

location?/users/?{ ????rewrite?^/users/(.*)$?/show?user=$1?break; }

如該示例所示，用戶通過匹配正則表達式捕獲第二個參數。

您可以在location 和 server上下文中包含多個rewrite指令。 NGINX按照它們發生的順序逐個執行指令。 當選擇該上下文時，server上下文中的rewrite指令將被執行一次。

在NGINX處理一組rewrite指令之后，它根據新的URI選擇一個location上下文。 如果所選location塊包含rewrite指令，則依次執行它們。 如果URI與其中任何一個匹配，則在處理所有定義的rewrite指令之后，將搜索新location塊。

以下示例顯示了與返回指令相結合的rewrite指令。

server?{ ????... ????rewrite?^(/download/.*)/media/(.*)..*$?$1/mp3/$2.mp3?last; ????rewrite?^(/download/.*)/audio/(.*)..*$?$1/mp3/$2.ra??last; ????return??403; ????... }

此示例配置區分兩組URI。 諸如/download/some/media/file之類的URI更改為/download/some/mp3/file.mp3。由于最后一個標志，所以跳過后續指令(第二次rewrite和return指令)，但NGINX繼續處理該請求，該請求現在具有不同的URI。類似地，諸如/download/some/audio/file的URI被替換為/download/some/mp3/file.ra。 如果URI與rewrite指令不匹配，則NGINX將403錯誤代碼返回給客戶端。

有兩個中斷處理重寫指令的參數：

last – 停止執行當前服務器或位置上下文中的重寫指令，但是NGINX會搜索與重寫的URI匹配的位置，并且應用新位置中的任何重寫指令(URI可以再次更改，往下繼續匹配)。

break – 像break指令一樣，在當前上下文中停止處理重寫指令，并取消搜索與新URI匹配的位置。新位置(location)塊中的rewrite指令不執行。

5. 重寫HTTP響應

有時您需要重寫或更改HTTP響應中的內容，將一個字符串替換為另一個字符串。 您可以使用sub_filter指令來定義要應用的重寫。 該指令支持變量和替代鏈，使更復雜的更改成為可能。

例如，您可以更改引用除代理服務器之外的絕對鏈接：

location?/?{ ????sub_filter??????/blog/?/blog-staging/; ????sub_filter_once?off; }

另一個示例將方法從http://更改為http://，并從請求頭域替換本地主機地址到主機名。 sub_filter_once指令告訴NGINX在一個位置(location)內連續應用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; }

請注意，如果發生另一個sub_filter匹配，則使用sub_filter修改的響應部分將不再被替換。

處理錯誤

使用error_page指令，您可以配置NGINX返回自定義頁面以及錯誤代碼，替換響應中的其他錯誤代碼，或將瀏覽器重定向到其他URI。 在以下示例中，error_page指令指定要返回404頁面錯誤代碼的頁面(/404.html)。

error_page?404?/404.html;

請注意，此偽指令并不立即返回該錯誤(返回指令執行該操作)，而僅僅是指定發生時如何處理錯誤。 錯誤代碼可以來自代理服務器，或者在NGINX處理期間發生(例如，當NGINX找不到客戶端請求的文件時，顯示404對應的結果)。

在以下示例中，當NGINX找不到頁面時，它會將代碼301替換為代碼404，并將客戶端重定向http:/example.com/new/path.html。 當客戶端仍嘗試訪問其舊URI的頁面時，此配置非常有用。 301代碼通知瀏覽器頁面已經永久移動，并且需要在返回時自動替換舊地址。

location?/old/path.html?{ ????error_page?404?=301?http:/example.com/new/path.html; }

以下配置是在未找到文件時將請求傳遞給后端的示例。 因為在error_page指令的等號之后沒有指定狀態代碼，所以對客戶機的響應具有代理服務器返回的狀態代碼(不一定是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/; ????} }

當沒有找到文件時，error_page指令指示NGINX進行內部重定向。 error_page指令的最終參數中的$uri變量保存當前請求的URI，該URI在重定向中被傳遞。

例如，如果沒有找到/images/some/file，它將被替換為/fetch/images/some/file，并且新的搜索位置(location)開始。最后請求最終在第二個location上下文中，并被代理到http://backend/。

如果沒有找到文件，則open_file_cache_errors指令可防止寫入錯誤消息。 因為丟失的文件可被正確地處理，但這不是必需的。

? 版權聲明
THE END
互聯網運維
# http# 字符串# html# nginx# default# 正則表達式# unix# location# map# perl# mail# break
喜歡就支持一下吧
點贊10 分享