搜尋
首頁運維NginxNginx Web伺服器設定區塊有哪些?

Nginx Web伺服器設定區塊有哪些?

Jun 29, 2020 pm 04:44 PM
nginx網頁伺服器

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快速入門教學

#設定區塊通常包含一個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指令可防止写入错误消息。 因为丢失的文件可被正确地处理,但这不是必需的。

以上是Nginx Web伺服器設定區塊有哪些?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
NGINX單元與其他應用程序服務器NGINX單元與其他應用程序服務器Apr 24, 2025 am 12:14 AM

NGINXUnit優於ApacheTomcat、Gunicorn和Node.js內置HTTP服務器,適用於多語言項目和動態配置需求。 1)支持多種編程語言,2)提供動態配置重載,3)內置負載均衡功能,適合需要高擴展性和可靠性的項目。

NGINX單元:架構及其工作原理NGINX單元:架構及其工作原理Apr 23, 2025 am 12:18 AM

NGINXUnit通過其模塊化架構和動態重配置功能提高了應用的性能和可管理性。 1)模塊化設計包括主控進程、路由器和應用進程,支持高效管理和擴展。 2)動態重配置允許在運行時無縫更新配置,適用於CI/CD環境。 3)多語言支持通過動態加載語言運行時實現,提升了開發靈活性。 4)高性能通過事件驅動模型和異步I/O實現,即使在高並發下也保持高效。 5)安全性通過隔離應用進程提高,減少應用間相互影響。

使用NGINX單元:部署和管理應用程序使用NGINX單元:部署和管理應用程序Apr 22, 2025 am 12:06 AM

NGINXUnit可用於部署和管理多種語言的應用。 1)安裝NGINXUnit。 2)配置它以運行不同類型的應用,如Python和PHP。 3)利用其動態配置功能進行應用管理。通過這些步驟,你可以高效地部署和管理應用,提升項目效率。

NGINX與Apache:Web服務器的比較分析NGINX與Apache:Web服務器的比較分析Apr 21, 2025 am 12:08 AM

NGINX更适合处理高并发连接,而Apache更适合需要复杂配置和模块扩展的场景。1.NGINX以高性能和低资源消耗著称,适合高并发。2.Apache以稳定性和丰富的模块扩展闻名,适合复杂配置需求。

NGINX單元的優勢:靈活性和性能NGINX單元的優勢:靈活性和性能Apr 20, 2025 am 12:07 AM

NGINXUnit通過其動態配置和高性能架構提升應用的靈活性和性能。 1.動態配置允許在不重啟服務器的情況下調整應用配置。 2.高性能體現在事件驅動和非阻塞架構以及多進程模型上,能夠高效處理並發連接和利用多核CPU。

NGINX與Apache:性能,可伸縮性和效率NGINX與Apache:性能,可伸縮性和效率Apr 19, 2025 am 12:05 AM

NGINX和Apache都是強大的Web服務器,各自在性能、可擴展性和效率上有獨特的優勢和不足。 1)NGINX在處理靜態內容和反向代理時表現出色,適合高並發場景。 2)Apache在處理動態內容時表現更好,適合需要豐富模塊支持的項目。選擇服務器應根據項目需求和場景來決定。

終極攤牌:nginx vs. apache終極攤牌:nginx vs. apacheApr 18, 2025 am 12:02 AM

NGINX適合處理高並發請求,Apache適合需要復雜配置和功能擴展的場景。 1.NGINX採用事件驅動、非阻塞架構,適用於高並發環境。 2.Apache採用進程或線程模型,提供豐富的模塊生態系統,適合複雜配置需求。

nginx行動:示例和現實應用程序nginx行動:示例和現實應用程序Apr 17, 2025 am 12:18 AM

NGINX可用於提升網站性能、安全性和可擴展性。 1)作為反向代理和負載均衡器,NGINX可優化後端服務和分擔流量。 2)通過事件驅動和異步架構,NGINX高效處理高並發連接。 3)配置文件允許靈活定義規則,如靜態文件服務和負載均衡。 4)優化建議包括啟用Gzip壓縮、使用緩存和調整worker進程。

See all articles

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

mPDF

mPDF

mPDF是一個PHP庫,可以從UTF-8編碼的HTML產生PDF檔案。原作者Ian Back編寫mPDF以從他的網站上「即時」輸出PDF文件,並處理不同的語言。與原始腳本如HTML2FPDF相比,它的速度較慢,並且在使用Unicode字體時產生的檔案較大,但支援CSS樣式等,並進行了大量增強。支援幾乎所有語言,包括RTL(阿拉伯語和希伯來語)和CJK(中日韓)。支援嵌套的區塊級元素(如P、DIV),

VSCode Windows 64位元 下載

VSCode Windows 64位元 下載

微軟推出的免費、功能強大的一款IDE編輯器

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

PhpStorm Mac 版本

PhpStorm Mac 版本

最新(2018.2.1 )專業的PHP整合開發工具

ZendStudio 13.5.1 Mac

ZendStudio 13.5.1 Mac

強大的PHP整合開發環境