A simple and useful Nginx Location configuration explanation

Preface

Location is a very core configuration in Nginx. This article focuses on the location configuration issues and some precautions.

grammar

Regarding Location, a simple configuration example:

http { 
  server {
      listen 80;
        server_name www.yayujs.com;
        location / {
          root /home/www/ts/;
          index index.html;
        }
  }
}

Roughly it means, when you visit www.yayujs.com of 80 when the port returns /home/www/ts/index.html file.

Let's look at the specific syntax of Location:

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

[ = | ~ | ~* | ^~ ] square brackets. The | represents the grammar you may use. Among them:

• = means exact match, such as:

location = /test {
  return 200 "hello";
}

# /test ok
# /test/ not ok
# /test2 not ok
# /test/2 not ok

• ~ represents case-sensitive regular matching, such as:

location ~ ^/test$ {
  [ configuration ] 
}

# /test ok
# /Test not ok
# /test/ not ok
# /test2 not ok

• ~* means case-insensitive regular matching

location ~* ^/test$ {     
    [ configuration ] 
}

# /test ok
# /Test ok
# /test/ not ok
# /test2 not ok

• ^~ means uri starts with a string

location ^~ /images/ {    
    [ configuration ] 
}

# /images/1.gif ok

And when you don't use these grammars, when you only write uri:

/ means general matching:

location / {     
    [ configuration ] 
}

# /index.html ok

location /test {
    [ configuration ] 
}

# /test ok
# /test2 ok
# /test/ ok

Match order

When there are multiple locations, their matching order refers to Nginx official document :

A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive 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.

After translation, it is:

The definition of location is divided into two types:

• Prefix string
• Regular expression, specifically the ~* with 061d2ec5976aa7 and ~ modifiers in front

And the order of matching locations is:

1. Check the locations that use the prefix string, select the longest match from the locations that use the prefix string, and store the result
2. If it matches = , the match will stop immediately
3. If it matches ^~ modifier, the matching will also stop immediately.
4. Then according to the order of the definition file, check the regular expression and stop when it matches.
5. When the regular expression fails to match, use the previously stored prefix string

To summarize again:

In terms of order, the order of the prefix string is not important, it is determined by the matching length, and the regular expression is in the order of definition.

In terms of priority, the modifier of = ^~ followed by regular, and finally the prefix string matching.

Let's review a few simple examples:

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

# 请求 /document 使用 configuration B
# 虽然 /doc 也能匹配到，但在顺序上，前缀字符串顺序不重要，按照匹配长度来确定

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

# 请求 /document 使用 configuration A
# 虽然 ~ ^/docu 也能匹配到，但正则表达式则按照定义顺序

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

# 请求 /document 使用 configuration A
# 虽然 ~ ^/docu 也能匹配到，但 ^~ 的优先级更高

server {
    location /document {
        [ configuration A ] 
    }
    location ~ ^/docu {
        [ configuration B ] 
    }
}

# 请求 /document 使用 configuration B
# 虽然 /document 也能匹配到，但正则的优先级更高

The difference between root and alias

When we set root like this:

location /i/ {
    root /data/w3;
}

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/;
}

When requesting /i/top.gif , /data/w3/images/top.gif will be returned.

At first glance, the two look similar, but a root the difference between the two. Root is directly spliced 061d2ec5976e04 + location and alias is alias instead of location , so the last path in root contains /i/ , and alias in There is no /i/ last path.

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

location /images/ {
    alias /data/w3/images/;
}

In fact, it is better to use root:

location /images/ {
    root /data/w3;
}

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/;
          index index.html;
        }
  }
}

If both appear, what is the priority?

Simply put, it is the principle of proximity. If the location can be matched, the root configuration in the location is used, and the root in the server is ignored. When the location cannot be matched, the root configuration in the server is used.

Series of articles

The blog building series is the only practical series of tutorials I have written so far, explaining how to use VuePress to build a blog and deploy it to GitHub, Gitee, personal servers and other platforms.

1. An article that takes you to build a blog with VuePress + GitHub Pages
2. An article to teach you how to synchronize GitHub and Gitee
3. still use GitHub Actions? Take a look at this
4. Gitee automatically deploy Pages? Still use GitHub Actions!
5. A Linux command sufficient for the front end

WeChat: "mqyqingfeng", add me to the only reader group in Kongyu.

If there are mistakes or not rigorous, please correct me, thank you very much. If you like or have some inspiration, star is welcome, which is also an encouragement to the author.