The Nginx configuration system consists of a main configuration file and some other auxiliary configuration files. These configuration files are all plain text files, all located in the conf directory under the Nginx installation directory. (Recommended study: nginx tutorial)
Lines starting with # in the configuration file, or lines preceded by a number of spaces or TAB and then followed by #, are considered It is a comment, that is, it is only meaningful to the user who edits and views the file. When the program reads these comment lines, its actual content is ignored.
Since files other than the main configuration file nginx.conf are used under certain circumstances, only the main configuration file is used under all circumstances. So here we take the main configuration file as an example to explain the Nginx configuration system.
In nginx.conf, it contains several configuration items. Each configuration item consists of two parts: configuration instructions and instruction parameters. Instruction parameters are the configuration values corresponding to the configuration instructions.
Command Overview
The configuration command is a string, which can be enclosed in single quotes or double quotes, or not. However, if the configuration directive contains spaces, it must be quoted.
Command parameters
The parameters of the command are separated from the command by one or more spaces or TAB characters. The parameters of the instruction consist of one or more TOKEN strings. TOKEN strings are separated by spaces or TAB keys.
TOKEN string is divided into simple string or compound configuration block. A composite configuration block is a bunch of content enclosed by curly braces. A composite configuration block may contain several other configuration directives.
If the parameters of a configuration instruction are all composed of simple strings, that is, they do not contain compound configuration blocks, then we say that the configuration instruction is a simple configuration item, otherwise it is called a complex configuration item. For example, the following is a simple configuration item:
error_page 500 502 503 504 /50x.html;
For simple configuration, use a semicolon at the end of the configuration item. For complex configuration items that contain multiple TOKEN strings, the simple TOKEN string is usually placed at the front, and the composite configuration block is usually placed at the end, and there is no need to add a semicolon at the end. For example, the following complex configuration item:
location / { root /home/jizhao/nginx-book/build/html; index index.html index.htm; }
Instruction context
The configuration information in nginx.conf is classified according to its logical meaning, and It is divided into multiple scopes, or called configuration instruction context. Different scopes contain one or more configuration items.
Several command contexts currently supported by Nginx:
main: Some parameters of Nginx that have nothing to do with specific business functions (such as http service or email service proxy) at runtime , such as the number of working processes, running identity, etc.
http: Some configuration parameters related to providing http services. For example: whether to use keepalive, whether to use gzip for compression, etc.
server: Several virtual hosts are supported on the http service. Each virtual host has a corresponding server configuration item, which contains the configuration related to the virtual host. When providing a proxy for mail services, you can also establish several servers, and each server is distinguished by the listening address.
location: In the http service, a series of configuration items corresponding to certain specific URLs.
mail: Some shared configuration items when implementing email-related SMTP/IMAP/POP3 proxies (because it is possible to implement multiple proxies and work on multiple listening addresses).
Instruction context, there may be inclusion situations. For example: Usually the http context and mail context must appear in the main context. A context may contain contexts of another type multiple times. For example: if the http service supports multiple virtual hosts, then multiple server contexts will appear in the http context.
Let’s take a look at a sample 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 command contexts mentioned above exist.
The configuration directives that exist in the main context are as follows:
userworker_processeserror_logeventshttpmail
The directives that exist in the http context are as follows:
server
The directives that exist in the mail context are as follows:
serverauth_httpimap_capabilities
The configuration directives that exist in the server context are as follows:
listenserver_nameaccess_loglocationprotocolproxysmtp_authxclient
The directives that exist in the location context are as follows:
indexroot
Of course, these are just some examples. For specific configuration instructions and in what context these configuration instructions can appear, you need to refer to the Nginx usage documentation.
The above is the detailed content of What does the Nginx configuration system consist of?. For more information, please follow other related articles on the PHP Chinese website!