nginxLocation官网文档语法介绍location[=|~|~*|^~|@]uri{...}location@name{...}一个location关键字，后面跟可选的修饰符(也就是[])中间的正则，后面是要匹配的字符，花括号里面是要进行的操作。=：表示完全匹配~：表示区分大小写的正则匹配~*：表示不区分大小写的正则匹配^~：表示URI以正则字符串开头！~：表示区分大小写的正则匹配！~*：表示Case-insensitiveregex不匹配/：通用匹配，任何请求都会匹配到匹配顺序。在多location配置的情况下，匹配顺序如下：1.首先完全匹配=location=/abcd{[…]}website.com/abcd:匹配website.com/ABCD:可能匹配也可能不匹配，取决于关于操作系统的文件系统是否区分大小写。Mac默认不区分大小写，Windows不区分大小写，Linux区分大小写。website.com/abcd?param1¶m2:匹配，忽略querystringwebsite.com/abcd/:不匹配，/website.com/abcdewithending:不匹配，所以如果你经常请求/，可以使用=来定义位置。2、其次，前缀匹配^~如果location是最匹配的，那么对于匹配到这个location的字符串，后面的正则搜索会立即停止。请注意，这不是正则表达式匹配，它旨在优先于正则表达式匹配。3、然后按照文件的顺序跟正则表达式，比如~或者~*location~^/abcd${[…]}^/abcd$这个正则表达式的意思是字符串必须以/开头，以$开头结束，中间必须是abcdwebsite.com/abcd:match(精确匹配)website.com/ABCD:nomatch，区分大小写website.com/abcd?param1¶m2:matchwebsite.com/abcd/:nomatch，无法正则匹配expressionwebsite.com/abcde:doesnotmatch,不能匹配正则表达式4.最后匹配前缀match（前缀字符串），不做任何修改。使用前缀字符串检查位置，并在使用前缀字符串长匹配的位置中选择最佳位置进行匹配。server{location/doc{[configurationA]}location/docu{[configurationB]}}/document可以匹配上面两个，但是前缀字符串的顺序并不重要，根据匹配长度来决定，所以B终于匹配上了。综上所述，匹配顺序是先=，再^~，再正则，最后前缀字符串匹配。如果上面的规则不好理解，可以看下面的伪代码函数match(uri)：rv=NULLifuriinexact_match:returnexact_match[uri]ifuriinprefix_match:ifprefix_match[uri]is'^~':returnprefix_match[uri]else:rv=prefix_match[uri]//注意这里没有return，这是最长匹配ifuriinregex_match:returnregex_match[uri]//按照文件中的顺序,find和returnrv@name@的用法用于定义命名位置。主要用于内部重定向，不能用来处理正常的请求。它的用法如下：location/{try_files$uri$uri/@custom}location@custom{#...dosomething}在上面的例子中，当试图访问url找不到对应的文件时，它会重定向到我们的自定义名称位置（在此处自定义）。请注意，其他命名位置不能嵌套在命名位置中。常用配置规则1.精确匹配#将所有请求直接转发到服务器的9090端口location=/{proxy_passhttp://127.0.0.1:9090/;}2.处理静态文件#目录匹配location^~/static/{root/webroot/static/;}#后缀匹配位置~*\.(gif|jpg|jpeg|png|css|js|ico)${root/webroot/res/;}3.转发动态请求到后端应用Server#将/account/开始的请求转发到Account服务器位置/account/{proxy_passhttp://127.0.0.1:8080/}#将/order/开始的请求转发到Order服务器位置/order/{proxy_passhttp://127.0.0.1:9090/}网址末尾的/是否需要网址末尾有/？这也是我在上手nginx时经常犯的错误。1.location中是否有/没有影响，也就是说/user/和/user是一样的，除非location中有url带$的要求，请参考前面的例子.2、URL结构为https://domain.com/形式，末尾带/不带/都不会引起重定向。因为浏览器在发起请求时默认会加上/，但是很多浏览器不会在地址栏显示/。3.如果URL的结构是https://domain.com/some-dir/，尾部如果缺少/会导致重定向。因为按照惯例，URL末尾的/表示目录，没有/表示文件。所以当访问/some-dir/时，服务器会自动到该目录下寻找对应的默认文件。如果访问/some-dir，服务器会首先查找some-dir文件。如果找不到，它会把some-dir当作一个目录，重定向到/some-dir/，并在该目录下寻找默认文件。root和aliasnginx有两种方式指定文件路径root和alias。主要区别在于nginx如何解释位置后面的uri，这将导致两者以不同的方式将请求映射到服务器文件。它们的用法和范围：[root]语法：rootpath默认值：roothtml配置段：http,server,location,if处理结果：rootpath+locationpath[alias]语法：aliaspath配置段：location处理结果：replace带有别名路径的位置路径。如果请求URI是/t/a.html，它们的行为如下：#returnthefilelocationof/www/root/html/t/a.html^~/t/{root/www/root/html/;}#返回/www/root/html/new_t/a.html的文件#丢弃location后配置的路径，将当前匹配的目录指向指定目录。location^~/t/{alias/www/root/html/new_t/;}可见，alias是目录别名的定义，root是顶级目录的定义。另外，alias后面一定要加/，否则找不到文件，root可有可无。如果root同时出现在server和location中，优先级是多少？？http{服务器{听80;服务器名称www.abc.com；根/home/www/网站/;位置/{root/home/www/ts/;索引index.html；}}}简单的说就是就近原则，如果location中有匹配，则使用location中的root配置，server中的root会被忽略。如果位置不匹配，将使用服务器中的根配置。参考资料：Nginx正则配置吃透Nginxlocation匹配一篇足够简单的NginxLocation配置讲解文章UnderstandingNginxlocationmatcheslocation和nginx中的root，你确定你真的了解他们的关系吗？你对大小写敏感了解多少
