Nginx's configuration system

Nginx's configuration system

Nginx's configuration system consists of a master profile and some other secondary profiles. These profiles are plain text files, all in the conf directory under the Nginx installation directory.

Lines in the # start with , or # that have a few spaces or TABs before them, and then follow , are considered comments, i.e. they are only meaningful to the user who edited the view file, and the program's actual contents are ignored when reading those comment lines.

Because files other than the main profile nginx.conf are used in some cases, only the main profile is used in any case. So here we use the main configuration file as an example to explain Nginx's configuration system.

In nginx.conf, there are several configuration items. E ach configuration item consists of two parts, the configuration instruction and the instruction parameter. The instruction parameter is the configuration value corresponding to the configuration instruction.

An overview of the instructions

A configuration instruction is a string that can be enclosed in single or double quotes, or not. But if the configuration instruction contains spaces, be sure to cause them.

The instruction parameters

The parameters of the instruction are separated from the instruction using one or more spaces or TAB characters. T he parameters of an instruction consist of one or more TOKEN strings. ToKEN strings are separated by spaces or TAB keys.

ToKEN strings are divided into simple strings or composite configuration blocks. A composite configuration block is a bunch of content enclosed in braces. There may be several additional configuration instructions in a composite configuration block.

If the parameters of a configuration instruction are all made up of simple strings, that is, they do not contain composite configuration blocks, then we say that the configuration instruction is a simple configuration item, otherwise it is called a complex configuration item. For example, this is a simple configuration item:

    error_page   500 502 503 504  /50x.html;

For simple configurations, the end of the configuration item ends with a sign. F or complex configuration items, which contain multiple TOKEN strings, simple TOKEN strings are generally placed in front, composite configuration blocks are generally at the end, and there is no need to add a sign. For example, this complex configuration item:

        location / {
            root   /home/jizhao/nginx-book/build/html;
            index  index.html index.htm;
        }

The instruction context

Configuration information in nginx.conf classifys them logically, i.e. into multiple scopes, or configuration instruction contexts. Different scopes contain one or more configuration items.

Several instruction contexts currently supported by Nginx:

• Main: Some parameters that Nginx does not run with specific business functions, such as http service or email service agent, such as number of work processes, identity to run, etc.
• http: Some configuration parameters related to the provision of the http service. For example: whether to use keyalive ah, whether to use gzip for compression, etc.
• Server: Several virtual hosts are supported on the http service. E ach virtual host has a corresponding server configuration item that contains the configuration associated with the virtual host. When you provide a proxy for a mail service, you can also establish several servers, each distinguished by the address of the listening.
• Location: A series of configuration items corresponding to certain URLs in the http service.
• mail: When implementing email-related SMTP/IMAP/POP3 agents, some configuration items are shared (because multiple agents may be implemented and work on multiple listening addresses).

The instruction context, which may contain the situation. F or example, usually the http context and the mail context must appear in the main context. I n one context, another type of context may be contained multiple times. For example, if the http service supports multiple virtual hosts, multiple server contexts appear in the http context.

Let's look at an example configuration:

    user  nobody;
    worker_processes  1;
    error_log  logs/error.log  info;

    events {
        worker_connections  1024;
    }

    http {  
        server {  
            listen          80;  
            server_name     www.linuxidc.com;  
            access_log      logs/linuxidc.access.log main;  
            location / {  
                index index.html;  
                root  /var/www/linuxidc.com/htdocs;  
            }  
        }  

        server {  
            listen          80;  
            server_name     www.Androidj.com;  
            access_log      logs/androidj.access.log main;  
            location / {  
                index index.html;  
                root  /var/www/androidj.com/htdocs;  
            }  
        }  
    }

    mail {
        auth_http  127.0.0.1:80/auth.php;
        pop3_capabilities  "TOP"  "USER";
        imap_capabilities  "IMAP4rev1"  "UIDPLUS";

        server {
            listen     110;
            protocol   pop3;
            proxy      on;
        }
        server {
            listen      25;
            protocol    smtp;
            proxy       on;
            smtp_auth   login plain;
            xclient     off;
        }
    }

In this configuration, all five configuration instruction contexts mentioned above exist.

The configuration instructions that exist in the main context are as follows:

• user
• worker_processes
• error_log
• events
• http
• mail

The instructions that exist in the http context are as follows:

• server

The instructions that exist in the context of mail are as follows:

• server
• auth_http
• imap_capabilities

The configuration instructions that exist in the context of the server are as follows:

• listen
• server_name
• access_log
• location
• protocol
• proxy
• smtp_auth
• xclient

The instructions that exist in the context of the location are as follows:

• index
• root

Of course, here are just a few examples. Specific configuration instructions, and what context they can appear in, need to refer to Nginx's usage documentation.