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!

NGINX and Apache are both powerful web servers, each with unique advantages and disadvantages in terms of performance, scalability and efficiency. 1) NGINX performs well when handling static content and reverse proxying, suitable for high concurrency scenarios. 2) Apache performs better when processing dynamic content and is suitable for projects that require rich module support. The selection of a server should be decided based on project requirements and scenarios.

NGINX is suitable for handling high concurrent requests, while Apache is suitable for scenarios where complex configurations and functional extensions are required. 1.NGINX adopts an event-driven, non-blocking architecture, and is suitable for high concurrency environments. 2. Apache adopts process or thread model to provide a rich module ecosystem that is suitable for complex configuration needs.

NGINX can be used to improve website performance, security, and scalability. 1) As a reverse proxy and load balancer, NGINX can optimize back-end services and share traffic. 2) Through event-driven and asynchronous architecture, NGINX efficiently handles high concurrent connections. 3) Configuration files allow flexible definition of rules, such as static file service and load balancing. 4) Optimization suggestions include enabling Gzip compression, using cache and tuning the worker process.

NGINXUnit supports multiple programming languages and is implemented through modular design. 1. Loading language module: Load the corresponding module according to the configuration file. 2. Application startup: Execute application code when the calling language runs. 3. Request processing: forward the request to the application instance. 4. Response return: Return the processed response to the client.

NGINX and Apache have their own advantages and disadvantages and are suitable for different scenarios. 1.NGINX is suitable for high concurrency and low resource consumption scenarios. 2. Apache is suitable for scenarios where complex configurations and rich modules are required. By comparing their core features, performance differences, and best practices, you can help you choose the server software that best suits your needs.

Question: How to start Nginx? Answer: Install Nginx Startup Nginx Verification Nginx Is Nginx Started Explore other startup options Automatically start Nginx

How to confirm whether Nginx is started: 1. Use the command line: systemctl status nginx (Linux/Unix), netstat -ano | findstr 80 (Windows); 2. Check whether port 80 is open; 3. Check the Nginx startup message in the system log; 4. Use third-party tools, such as Nagios, Zabbix, and Icinga.

To shut down the Nginx service, follow these steps: Determine the installation type: Red Hat/CentOS (systemctl status nginx) or Debian/Ubuntu (service nginx status) Stop the service: Red Hat/CentOS (systemctl stop nginx) or Debian/Ubuntu (service nginx stop) Disable automatic startup (optional): Red Hat/CentOS (systemctl disabled nginx) or Debian/Ubuntu (syst


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SublimeText3 Chinese version
Chinese version, very easy to use

VSCode Windows 64-bit Download
A free and powerful IDE editor launched by Microsoft

EditPlus Chinese cracked version
Small size, syntax highlighting, does not support code prompt function

WebStorm Mac version
Useful JavaScript development tools

MinGW - Minimalist GNU for Windows
This project is in the process of being migrated to osdn.net/projects/mingw, you can continue to follow us there. MinGW: A native Windows port of the GNU Compiler Collection (GCC), freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality. All MinGW software can run on 64-bit Windows platforms.