Nginx Web伺服器設定塊有:1、設定虛擬伺服器;2、設定位置;3、使用變數;4、回傳特定狀態碼;5、重寫請求中的URI;6、重寫HTTP響應;7、處理錯誤。
Nginx Web伺服器設定區塊有:
##1. 設定虛擬伺服器
NGINX設定檔必須至少包含一個伺服器指令來定義虛擬伺服器。當NGINX處理請求時,它首先選擇提供請求的虛擬伺服器。 虛擬伺服器由http上下文中的伺服器指令定義,例如:http { server { # Server configuration } }可以將多個server指令新增至http上下文以定義多個虛擬伺服器。
推薦教學:
#設定區塊通常包含一個listen指令,用來指定伺服器偵聽請求的IP位址和連接埠(或Unix域套接字和路徑)。 IPv4和IPv6位址均被接受; 將方括號(。
server { listen 127.0.0.1:8080; # The rest of server configuration }如果省略端口,則使用標準連接埠。 同樣地,如果省略一個位址,伺服器將偵聽所有位址。如果沒有包含listen指令,則「標準」連接埠為
80/tcp,「default」連接埠為
8000 /tcp,取決於超級使用者權限。
server { listen 80; server_name example.org www.example.org; ... }如果匹配主機頭幾個名稱,則NGINX 透過按以下順序搜尋名稱並使用其找到的第一個匹配來選擇一個:
- 確切的名字(完整準確的名稱)
- 以星號開頭的最長通配符,例如:*.example.org
- #以星號結尾的最長通配符,如:mail.*
- #第一個符合正規表示式(依照出現在設定檔中的順序)
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中文網其他相關文章!

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

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

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

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

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

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

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

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


熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

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

熱門文章

熱工具

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

VSCode Windows 64位元 下載
微軟推出的免費、功能強大的一款IDE編輯器

記事本++7.3.1
好用且免費的程式碼編輯器

PhpStorm Mac 版本
最新(2018.2.1 )專業的PHP整合開發工具

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境