Nginx location matching rule example

1. Grammar

location [=|~|~*|^~|@] /uri/ {
 ...
}

2. Description

From the above syntax, we can see that location can be divided into three parts. Let's study them one by one.

1) [=|~|~*|^~|@]

• = : means exact match of the following URL
• ~: indicates regular matching, but case-sensitive
• ~* : Regular expression matching, case insensitive
• ^~: indicates ordinary character matching. If this option matches, only this option will be matched, and no other options will be matched. It is generally used to match directories.
• @ : "@" defines a named location, used for internal targeting, such as error_page

Several different symbols are defined above, representing different matching rules, so what is the order?

1. = prefix matches this query exactly. If found, stop searching;
2. Of all the remaining regular strings, the longest match. If the match is prefixed with ^~, the search stops;
3. Regular expressions, in the order defined in the configuration file;
4. If rule 3 produces a match, the result is used. Otherwise, the result of rule 2 is used.

Test Example 1:

location = /world {
 return 600;
}

location = /hello {
 return 600;
}

location ~ /hellowo {
 return 602;
}

location ^~ /hello {
 return 601;
}

- Request localhost/world returns 600
- Request localhost/world2 localhost/test/world returns others - Request localhost/hello returns 600
- Request localhost/hello/123 returns 601
- Request localhost/hellow returns 601
- Request localhost/hellowo returns 601
- Request localhost/test/hellowo returns 602
- Request localhost/test/hello returns other

Therefore, we can know:

• = is an exact and complete match and has the highest priority;
• When matching a regular expression, if both ~ and ^~ match the rule at the same time, ^~ takes precedence;
• ^~ This rule will not match the path after the request URL, such as /test/hello above.
• ^~ does not support regular expressions. Compared with =, it has a wider range. hellowo can be matched by ^~, but not by =.
• ~ can be matched as long as it is included in the path, such as /test/hellowo above, which returns 602

Test Example 2:

location ~ /hello {
 return 602;
}

location ~ /helloworld {
 return 601;
}

- Request localhost/world/helloworld returns 602
- Request localhost/helloworld returns 602

Adjust the order above

location ~ /helloworld {
 return 601;
}

location ~ /hello {
 return 602;
}

- Request localhost/helloworld returns 601
- Request localhost/world/helloworld returns 601
- Request localhost/helloWorld returns 602

So when the regular expression matches

• The first match is the one placed in front
• Note that if you are not case sensitive, use ~*
• Try to put exact matches first.

Test Example 3:

location ^~ /hello/ {
 return 601;
}

location /hello/world {
 return 602;
}

In this scenario, there is a routing rule that is not matched, so what is the actual test like?

- http://localhost/hello/wor returns 601
- http://localhost/hello/world returns 602
- http://localhost/hello/world23 returns 602
- http://localhost/hello/world/123 returns 602

From the above example, we can see

• When there is no match, full match takes precedence^~

2) [uri]

The main thing to fill in here is the path path that needs to be matched. According to the previous symbols, you can fill in the exact path path or a regular expression. The following mainly explains the regular expression.

• . : matches any character except newline
• ? : Repeat 0 or 1 times
• + : Repeat 1 or more times
• * : Repeat 0 or more times
• \d : matches a number
• ^ : matches the beginning of a string
• $: Introduction to matching strings
• {n} ： repeat n times
• {n,} ： repeat n times or more
• [c] ： Matches a single character c
• [az]: matches any lowercase letter az
• The content matched between the parentheses () can be referenced later by $1, and $2 represents the content in the second (). What is confusing in regular expressions is the \ escape special characters.

Routing and forwarding

Request path matching is only the first step. After the matching is completed, how to forward the request to other web services?

1. Reverse Proxy

A common usage posture is to use nginx to proxy requests and forward them to other internal web services.

Mainly achieved through prixy_pass

location ^~ /webs {
 proxy_pass http://127.0.0.1:8080/webs;
}

The meaning of the above rule is to forward all requests starting with webs to the web service on port 8080.

The above is directly forwarded to an IP address. If multiple machines provide services, you can configure it like this

## Put the following in the brackets of http as the first upstream layer test.online {
 server 120.11.11.11:8080 weight=1;
 server 120.11.11.12:8080 weight=1;
}

location ^~ /webs {
 proxy_pass http://test.online;
 proxy_redirect default;
}

2. Rewrite command

The rewrite function uses the global variables provided by nginx or the variables set by yourself, combined with regular expressions and flags to achieve URL rewriting and redirection.

rewrite can only be placed in server{}, location{}, if{}, and can only work on the string after the domain name excluding the passed parameters, such as

http://jb51.net/a/we/index.php?id=1&u=str

Only rewrite /a/we/index.php.

Syntax: rewrite regex replacement [flag];

Example:

location ^~ /hexo {
 root '/Users/yihui/GitHub/';
}

location ~ /hello {
 rewrite ^(/hello).*$ /hexo/public/index.html last;
 return 603;
}

Forward all the files starting with hello to /hexo/public/index.html

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.