Shulou(Shulou.com)06/02 Report--

Editor to share with you how to configure the inheritance model of Nginx. I hope you will get something after reading this article. Let's discuss it together.

To understand the inheritance model of nginx, you first need to know that nginx operates with multiple configuration blocks. In nginx, such blocks are called contexts, for example, configuration instructions placed in the server context reside in the server {} block, just as instructions placed in the http context reside in the http {} block.

There are six possible contexts in nginx, and here is the order from top to bottom:

Global.

Http.

Server.

If.

Location.

Nested Location.

If in location.

Limit_except.

The default inheritance model is that instructions inherit only downward. Never turned sideways, never. This includes situations where you internally rewrite requests from one location to another-every instruction in the first location is forgotten, and only the second location instruction applies to the location context. In terms of inheritance behavior, there are four types of configuration directives in nginx:

Normal directive-one value per context, such as "root" or "index".

Array directive-there are multiple values per context, such as "access_log" or "fastcgi_param"

Action directive-not just something configured, such as "rewrite" or "fastcgi_pass"

Try_files instruction.

The Normal instruction is by far the most common instruction, following the default inheritance model without any surprises. Let's look at an example configuration that shows the behavior.

Server {root / home/user/public_html; location / app {root / usr/share; # This results in / usr/share/app # Full URI is ALWAYS appended. } location / app2 {/ / Server context root applies here. }}

Array instructions are much like normal instructions because they follow the standard inheritance model, which always inherits and replaces any instruction specified in a higher context. It may be confusing to assume that you add to the array. The behavior of the Array instruction is that if multiple instructions are defined in the same context, they will be added to the value, but if multiple instructions are defined in different contexts, the lower context will replace the higher context. This means that if you want it to exist in multiple contexts, you sometimes need to define a value doubly. An example of this situation.

Server {access_log / var/log/nginx/access.log; include fastcgi.conf; location ~ ^ / calendar/.+\ .php ${access_log / var/log/nginx/php-requests.log; # If this executes then server context one never does. Fastcgi_param ENV debug; # This * overwrites* the higher context array. Include fastcgi.conf # Therefore we include it in * this* context again. }}

The Action instruction is where it starts to get interesting. They are limited to one context and never inherit downward, but they can be specified in multiple contexts and, in some cases, will be executed for each context. The rewrite directive is an action directive that allows two contexts to be executed in the server and location context.

Server {rewrite ^ / booking (. *) / calendar$1 permanent; # Always executes. Location / calendar {rewrite ^ / index.php; # Can execute in addition to and does not replace server context rewrites. }}

Of course, it's not that simple. There are three possible contexts within a location, a nested location, an if, and a limit_except. The behavior of an instruction actually depends entirely on the module that defines it. If allowed in this context, all normal and array instructions will inherit correctly. When it comes to action instructions, the story is a little different. Usually they do not inherit to nested locations, but ultimately depend on the expectations of the module, and it can vary based on instructions. Nginx documents are not used here, so you have to give it a try and see if nginx complains. To better measure, let's give an example of the most common behavior and how it affects rewriting:

Server {location / calendar {rewrite ^ / static.php; # Executes unless inner location matches. Location. Php$ {fastcgi_pass backend; # Outer location context rewrite is not executed. }}}

The try_files instruction is roughly the same as every other operation instruction mentioned above, except that if placed in the server context, nginx actually creates a pseudo location, which is the least specific location possible. This means that if the request matches the defined location, the try_files instruction will not be executed. This means that if you have location / defined, you have a location that matches every possible request, so try_files will never actually be executed. So, if possible, always place the try_files in the location context rather than the server context

Server {try_files $uri / index.php; # This never executes. Location / {# Whatever here, or empty. } location ~. Php$ {# If this location executes then try_files still does not execute. # Even if location / did not exist. }} after reading this article, I believe you have a certain understanding of "the method of Nginx configuration inheritance model". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.