Hi,大家好,我是编程小6,很荣幸遇见你,我把这些年在开发过程中遇到的问题或想法写出来,今天说一说
location nginx配置_centos静态路由配置,希望能够帮助你!!!。
location路由匹配发生在HTTP请求处理的find-config配置查找阶段,主要功能是:根据请求的URI地址匹配location路由表达式,如果匹配成功,就执行location后面的上下文配置块。
实战案例说明
本节的配置实例处于源码工程的nginx-location-demo.conf配置文件中。在运行本节的实例前,需要修改openresty-start.bat(或openresty-start.sh)脚本中的PROJECT_CONF配置文件变量的值,将其修改为nginx-location-demo.conf,然后重启OpenRestry/Nginx。
Nginx配置文件中,location配置项的语法格式如下:
location [=|~|~*|^~] 模式字符串 { ... }
按照匹配的符号不同,location路由匹配主要分成精准匹配、普通匹配、正则匹配、默认根路径匹配。下面逐一进行介绍。
1.精准匹配
精准匹配的符号标记为“=”,下面是一个简单的精准匹配location的例子。
#精准匹配 location = /lua { echo "hit location: =/Lua"; }
如果请求URI和精准匹配的模式字符串/lua完全相同,那么精准匹配通过。
在所有的匹配类型中,精准匹配的优先级最高。
运行本文的配套案例,在同时存在多个/lua匹配模式location的情况下,在浏览器中给Nginx发送http://localhost/lua的请求地址,输出的是精准匹配的结果,如图7-12所示。
2.普通匹配
普通匹配的符号标记为“^~”,下面是一个简单的普通匹配location的例子。
location ^~ /lua { echo "hit location: ^~ /lua"; }
普通匹配属于字符串前缀匹配,详细来说:如果请求路径URI头部匹配到location的模式字符串,那么匹配成功。如果匹配到多个前缀,那么最长模式匹配优先。
本文配套实例中配置了以下两个普通匹配类型的location,具体配置如下:
#普通匹配一 location ^~ /lua { echo "普通匹配: ^~ /lua"; } #普通匹配二,长一点 location ^~ /lua/long { echo "普通匹配: ^~ /lua/long"; }
在浏览器中给Nginx发送http://localhost/lua/long/path的请求地址,输出了普通匹配location的结果,如图7-13所示。
注意
普通匹配是前缀匹配,也是Nginx默认的匹配类型。也就是说,类型符号“^~”可以省略,如果location没有任何匹配类型,就为普通的前缀匹配。如果一个URI命中多个location普通匹配,则最长的location普通匹配获胜。
为了对以上结论进行论证,这里举一个例子,在配置文件中配置两个同样字符串模式的location,一个不带类型符号,一个带“^~”符号,具体如下:
#不带类型符号,默认为普通匹配 location /demo { echo "hit location: /demo "; } #带“^~”符号,普通匹配 location ^~ /demo { echo "hit location: ^~ /demo"; }
执行重启Nginx的脚本openresty-restart.bat,发现Nginx不能启动,查看error.log错误日志,报错信息如下:
... 17:33:39 [emerg] 18760#25944: duplicate location "/demo" in .../nginx-location-demo.conf:115
从错误信息可以看出,在配置文件中有两个重复的location配置。
3.正则匹配
正则匹配的类型按照类型符号的不同可以细分为以下4种:
(1)~:标准正则匹配,区分字母大小写,进行正则表达式测试,若测试成功,则匹配成功。
(2)~*:标准正则匹配,不区分字母大小写,进行正则表达式测试,若测试成功,则匹配成功。
(3)!~:反向正则匹配,区分字母大小写,进行正则表达式测试,若测试不成功,则匹配成功。
(4)!~*:反向正则匹配,不区分字母大小写,进行正则表达式测试,若测试不成功,则匹配成功。下面是一个正则匹配的例子,可以匹配以hello.php或hello.asp结尾的URL请求。
#正则匹配 location ~*hello\.(asp|php)$ { echo "正则匹配: hello.(asp|php)$ "; }
在浏览器中给Nginx发送http://localhost/1/2/hellp.php的请求地址,输出的请求结果如图7-14所示。
如果配置文件中存在多个正则匹配location,那么它们之间的规则是顺序优先的,只要匹配到第一个正则类型的location,就停止后面的正则类型的location测试。
例如,这里有两个正则匹配的location规则:\.(do|jsp)$和hello\.(do|jsp)$,具体如下:
#正则匹配类型 location ~*\.(do|jsp)$ { echo "正则匹配: .(do|jsp)$ "; } #正则匹配类型 location ~*hello\.(do|jsp)$ { echo "正则匹配: hello.(do|jsp)$ "; }
在浏览器中给Nginx发送http://localhost/1/2/hellp.do的请求地址,输出的结果是由配置在前面的location输出的,如图7-15所示。
4.默认根路径匹配
根路径的路径规则就是使用单个“/”符号,示例如下:
location / { echo "默认根路径匹配: /"; }
通过浏览器随便访问一个地址,如http://localhost/foo,使之不能匹配到其他的location,只能匹配到“/”根路径,返回的结果如图7-16所示。
表面看上去,location/{...}根路径匹配非常类似普通匹配,但实际上该规则自成一类,虽然只有唯一的一个路径,但是此类规则优先级是最低的。
最后总结一下4种location之间的匹配次序,大致如下:
(1)类型之间的优先级:精准匹配>普通匹配>正则匹配>“/”默认根路径匹配。
(2)普通匹配同类型location之间的优先级为最长前缀优先。普通匹配的优先级与location在配置文件中所处的先后顺序无关,而与匹配到的前缀长度有关。
(3)正则匹配同类型location之间的优先级为顺序优先。只要匹配到第一个正则规则的location,就停止后面的正则规则的测试。正则匹配与location规则定义在配置文件中的先后顺序强相关。
第一个应该配置的属于“/”根路由规则。“/”根路由规则可以路由到一个静态首页:
location / {
root html;
index index.html index.htm;
}
表示在请求URI匹配到“/”根路由规则时,首先Nginx会在html目录下查找index.html文件,如果没有找到,就查找index.htm文件,将找到的文件内容返回给客户端。
“/”根路由规则也可以路由到一个访问很频繁的上游服务,比如Spring Cloud微服务架构中的服务网关:
location / { proxy_pass http://127.0.0.1:7799/ ; }
这里的127.0.0.1:7799假定为Zuul网关的IP和端口,当请求匹配到“/”根路由规则时,将直接转发给上游Zuul应用网关服务器。
第二个应该配置的属于静态文件路由规则。对静态文件请求进行响应,这是Nginx作为HTTP服务器的强项。静态文件匹配规则有两种配置方式:目录匹配(前缀匹配)和后缀匹配(正则匹配),可以任选其一,也可以搭配使用。
目录匹配(前缀匹配)配置实例如下:
root /www/resources/static/; #前缀匹配 location ^~ /static/ { root /www/resources/; }
所有匹配/static/...规则的静态资源请求(如/static/img/1.png)都将路由到root指令所配置的文件目录/www/resources/static/下对应的某个文件(如/www/resources/static/img/1.png)。
后缀匹配(正则匹配)配置实例如下:
location ~*\.(gif|jpg|jpeg|png|css|js|ico)${ root /www/resources/; }
所有匹配到以上正则规则的静态资源请求(如/static/img/2.png)都将路由到root指令所配置的文件目录/www/resources/static/下对应的某个文件(如/www/resources/static/img/2.png)。
今天的分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。
上一篇
已是最后文章
下一篇
已是最新文章