nginx location配置看看文档都会,主要是记不住,写下来方便查询。主要是优先级要搞清楚,不然工程大了,匹配的莫名其妙。本文按优先级依次介绍。
总述:精确匹配(=) > 字符串打头匹配(^~) > 正则匹配(~或~*) >否定式正则匹配(!~或!~*
) > 通用匹配(/)。两种正则当中,区分大小写的优先级高,也就是不带*的优先级高
1.精确匹配
= 精确匹配
location = / { #精确匹配访问网站根目录 } location = /login { #精确匹配http://xxx.com/login }
精确匹配优先级最高,匹配是唯一的
2.以什么打头
^~ 表示以什么打头,关键在于正则的开头符 ^
location ^~ /static/ {
#以/static打头,比如 http://xxx.com/static/jQuery.js
}
3. 正则匹配,区分大小写优先于不区分大小写
~ 区分大小写的正则, ~* 不区分大小的正则
location ~ \.png { #以png结尾,比如比如 http://xxx.com/img/a.png } location ~* \.png$ { #以png或者PNG或者Png等等结尾,比如比如 http://xxx.com/img/a.pNg。如果是png结尾,会优先匹配上面一条。 }
4.排除法的正则,同样区分大小写优先于不区分大小写
!~ 区分大小写的排除法正则, !~*不区分大小的排除法正则
排除法正则是指,url与该正则不匹配,才算合格,才能进入此location。相当于正则匹配的否定写法。不建议实际工程中使用,毕竟肯定能表达的干嘛写否定式呢?很不利于排除问题。小心装逼不成,坑了自己的KPI。
location !~ \.png$ { #匹配“以png结尾”失败,进入location,那就情况多了去了,只要不以png结尾就行 } location !~* \.xhtml$ { #匹配“以png或者PNG或者PnG等等”结尾失败,进入location,那情况也多了去了,只要不是PNG的各种大小写变体就行 }
5.通用匹配
/ 通用匹配,任何请求都会匹配到。
location / {
#用来兜底的,当前面其他所有的规则都不满足条件,就归入这个通用的
}
6.另类字符串匹配
location /prefix/mid/ { # 啥也不写,不属于以上任何一种 }
首先,不建议写这种,原因有点深:对于location,分为两大类:官方英文说法是 location using literal strings 和 location using regular expressions,我们就字面翻译为字符串location和正则location.总体上字符串location优先于正则location。
字符串location不使用=或者^~,nginx会采用“最大前缀匹配”原则在字符串location里面选出匹配度最高的一个做为临时选择结果Temp,然后继续在正则location中匹配,如果匹配到某个正则location,则立即停止并且最终使用该正则location,如果没有匹配到正则location,那么就选择临时结果Temp(此结果由“最大前缀匹配”原则产生,与location编辑顺序无关)。
那么字符串location选择出了最大前缀匹配临时结果,能不能停止,不在考虑正则呢?可以。就是使用=或者^~。那就回到了上面讲的几类。
7.“@”前缀
server { listen 80; server_name localhost;location / { root html; index index.html index.htm; allow all; } #error_page 404 http://www.error.com # 直接这样是不允许的 error_page 404 = @fallback; location @fallback { proxy_pass http://www.error.com; }
}
error_page 404指令能捕获404错误,并且转发给fallback