A little awkward, wrong place of official documents, official documents in real https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/
Basic functions are divided into two parts
Controlling NGINX Processes at Runtime——移步https://www.cnblogs.com/haon/p/10962160.html
Creating NGINX Plus and NGINX Configuration Files——移步https://www.cnblogs.com/haon/p/10961838.html
This article will explain more detailed nginx.conf
Start
nginx.conf divided into three parts
Directives Directive
Ordinary instruction such as:
user nobody;
error_log logs/error.log notice; worker_processes 1;
Feature-Specific Configuration Files special configuration files
Recommend splitting stored at /etc/nginx/conf.d, loaded with include content
ex:
include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;
Here I do not understand, what saved, include take what
Contexts content body
The communication is divided into different types
events
- connection processhttp
- http communicationmail
- smtp communication?stream
- tcp and udp communication
Communication may be directed to a plurality of instruction blocks server (virtual server), a communication scheme determining useable instructions in the server
user nobody; # a directive in the 'main' context events { # configuration of connection processing } http { # Configuration specific to HTTP and affecting all virtual servers server { # configuration of HTTP virtual server 1 location /one { # configuration for processing URIs starting with '/one' } location /two { # configuration for processing URIs starting with '/two' } } server { # configuration of HTTP virtual server 2 } } stream { # Configuration specific to TCP/UDP and affecting all virtual servers server { # configuration of TCP virtual server 1 } }
There is also talk about the case of nested context, did not understand, first reserved
Inheritance
In general, a child context – one contained within another context (its parent) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the proxy_set_header
directive.