preface

Location is a very core configuration in Nginx, this article focuses on the configuration of the Location and some considerations.

grammar

Here’s a simple configuration example for Location:

http { 
  server {
      listen 80;
    	server_name www.yayujs.com;
    	location / {
      	root /home/www/ts/;
	      indexindex.html; }}}Copy the code

When you visit www.yayujs.com on port 80, return the /home/www/ts/index.html file.

Let’s look at the syntax of Location:

location[= |~ | ~ * |^ ~ ] uri { ... }
Copy the code

Focus on square brackets [= | | | ~ ~ * ^ ~], including | separated said you might want to use the content of the grammar, including:

  • =Denotes an exact match, for example:
location = /test {
  return 200 "hello";
}

# /test ok
# /test/ not ok
# /test2 not ok
# /test/2 not ok
Copy the code
  • ~Represents a case-sensitive regular match, such as:
location ~ ^/test${[configuration]}# /test ok
# /Test not ok
# /test/ not ok
# /test2 not ok
Copy the code
  • ~ *Represents case-insensitive regular matching
location ~* ^/test${[configuration]}# /test ok
# /Test ok
# /test/ not ok
# /test2 not ok
Copy the code
  • ^ ~Indicates that the URI begins with a string
location^ ~ /images/ {    
	[ configuration]}# /images/1.gif ok
Copy the code

And when you don’t use this syntax, just write urIs:

/ stands for universal matching:

location/ {[configuration]}# /index.html ok
Copy the code
location /test {
    [ configuration]}# /test ok
# /test2 ok
# /test/ ok
Copy the code

Matching order

When multiple locations exist, their matching order is quoted in the official Nginx documentation as follows:

A location can either be defined by a prefix string, Or by a regular expression. The foregoing “*” modifier (for case-insensitive) has been specified Matching), or the modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.

If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.

Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.

Translation after finishing is:

Location is defined in two ways:

  • Prefix String
  • The value is the regular expression~ * 和 ~The modifier

And the order of matching location is:

  1. Check locations using the prefix string, select the longest match for locations using the prefix string, and store the results
  2. If it fits with=The URI of the modifier immediately stops matching
  3. If it fits with^ ~The URI of the modifier also stops matching immediately.
  4. The regular expression is then checked in the order in which the file is defined and stopped when a match is found
  5. When the regular expression does not match, the stored prefix string is used

To sum up:

In order, the prefix string order is not important. It is determined by the matching length, while the regular expression is determined by the definition order.

In priority, the = modifier is the highest, followed by ^~, re, and finally prefix string matching.

Let’s review with a few simple examples:

server {
    location /doc {
        [ configuration A ] 
    }
    location /docu {
        [ configuration B ] 
    }
}

Request /document to use Configuration B
/doc = /doc = /doc = /doc
Copy the code
server {
    location ~ ^/doc{[configuration A ] 
    }
    location ~ ^/docu{[configuration B ] 
    }
}

Request /document to use Configuration A
The regular expressions are in the order defined, although ~ ^/docu can also be matched
Copy the code
server {
    location^ ~ /doc {
        [ configuration A ] 
    }
    location ~ ^/docu{[configuration B ] 
    }
}

Request /document to use Configuration A
# although ~ ^/docu can also be matched, ^~ has a higher priority
Copy the code
server {
    location /document {
        [ configuration A ] 
    }
    location ~ ^/docu{[configuration B ] 
    }
}

Request /document to use Configuration B
While /document can also be matched, the re has a higher priority
Copy the code

Difference between root and alias

When we set root like this:

location /i/ {
    root /data/w3;
}
Copy the code

When requesting/I /top. GIF, /data/w3/ I /top. GIF will be returned.

When we set alias like this:

location /i/ {
    alias /data/w3/images/;
}
Copy the code

When requesting/I /top.gif, /data/w3/images/top.gif is returned.

Root: / I/root: / I/root: / I/root: / I / The last path in alias does not contain/I /.

So if you use alliAS to define a path like this:

location /images/ {
    alias /data/w3/images/;
}
Copy the code

It’s better to use root:

location /images/ {
    root /data/w3;
}
Copy the code

Root in server and location

Root can be used in both server and location, for example:

http { 
  server {
      listen 80;
    	server_name www.yayujs.com;
    	root /home/www/website/;
    	location / {
      	root /home/www/ts/;
	      indexindex.html; }}}Copy the code

If both are present, what is the priority?

In simple terms, it is the nearest principle, if the location can match, use the root configuration in location, ignore the root configuration in server, when the location cannot match, use the root configuration in server.

series

Blog Building is the only practical tutorial series I’ve written so far, explaining how to use VuePress to build a blog and deploy it on GitHub, Gitee, personal servers, etc.

  1. Build a blog with VuePress + GitHub Pages
  2. This article will teach you how to synchronize GitHub and Gitee code
  3. Can’t use GitHub Actions yet? Look at this article
  4. How does Gitee automatically deploy Pages? GitHub Actions again!
  5. A Linux command with an adequate front end

Wechat: “MQyqingfeng”, add me Into Hu Yu’s only readership group.

If there is any mistake or not precise place, please be sure to give correction, thank you very much. If you like or are inspired by it, welcome star and encourage the author.