本文介绍如何将NGINX配置做为Web服务器,并包括如下部分:html
在高层次上,将NGINX配置做为Web服务器有一些问题须要了解,定义它处理哪些URL以及如何处理这些URL上的资源的HTTP请求。 在较低层次上,配置定义了一组控制对特定域或IP地址的请求的处理的虚拟服务器。nginx
用于HTTP流量的每一个虚拟服务器定义了称为位置的特殊配置实例,它们控制特定URI集合的处理。 每一个位置定义了本身的映射到此位置的请求发生的状况。 NGINX能够彻底控制这个过程。 每一个位置均可以代理请求或返回一个文件。 此外,能够修改URI,以便将请求重定向到另外一个位置或虚拟服务器。 此外,能够返回特定的错误代码,也能够配置特定的页面以对应于每一个错误代码。正则表达式
NGINX配置文件必须至少包含一个服务器指令来定义虚拟服务器。 当NGINX处理请求时,它首先选择提供请求的虚拟服务器。
虚拟服务器由http
上下文中的服务器指令定义,例如:后端
http { server { # Server configuration } }
能够将多个server
指令添加到http
上下文中以定义多个虚拟服务器。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语法用于正则表达式; 在它们以前使用波浪号(〜
)。 此示例说明了一个确切的名称。tcp
server { listen 80; server_name example.org www.example.org; ... }
若是匹配主机头几个名称,则NGINX经过按如下顺序搜索名称并使用其找到的第一个匹配来选择一个:测试
*.example.org
mail.*
若是主机头字段与服务器名称不匹配,则NGINX会将请求路由到请求到达端口的默认服务器。 默认服务器是nginx.conf
文件中列出的第一个服务器,除非您将listen_server
参数包含在listen
指令中以明确指定服务器为默认值。fetch
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; }
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和前缀字符串彻底匹配。若是找到彻底匹配,则搜索中止。^~
(插入符号)修饰符预先添加最长匹配前缀字符串,则不会检查正则表达式。=
修饰符的典型用例是/
(正斜杠)的请求。 若是请求/
是频繁的,则指定=/
做为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
)。
可使用配置文件中的变量,使NGINX进程的请求根据定义的状况而有所不一样。 变量是在运行时计算的命名值,用做指令的参数。 一个变量由它的名字开头的$
(美圆)符号表示。 变量根据NGINX的状态定义信息,例如正在处理的请求的属性。
有许多预约义的变量,如核心HTTP变量,您可使用set
,map
和geo
指令定义自定义变量。 大多数变量在运行时计算的,并包含与特定请求相关的信息。 例如,$remote_addr
包含客户端IP地址,$uri
保存当前的URI值。
一些网站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
上下文中。
能够经过使用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
指令不执行。有时您须要重写或更改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指令可防止写入错误消息。 由于丢失的文件可被正确地处理,但这不是必需的。