Le fichier de configuration nginx se compose de directives Les instructions sont divisées en deux formes, des instructions simples et des instructions de bloc.
Une commande simple se compose du nom de la commande, des paramètres et d'un point-virgule final (;), par exemple : écouter 80 backlog 4096;, où "écouter" est le nom de la commande, "80", "backlog" et "4096" sont tous des paramètres et ";" indique la fin de la commande.
Instruction de bloc se compose du nom de l'instruction, des paramètres et des accolades ({}), par exemple : location /imag {}, où "location" est le nom de l'instruction, "/imag" est un paramètre, "{}" est utilisé pour inclure d'autres instructions et indiquer la fin. Si les accolades dans une instruction de bloc peuvent inclure d'autres instructions simples ou instructions de bloc, alors cette instruction de bloc est appelée "contexte (contexte) ", et les instructions de bloc les plus couramment utilisées sont "Contexte".
Les instructions qui ne sont incluses dans aucune autre instruction de bloc sont considérées comme étant dans le contexte principal, c'est-à-dire que le contexte principal est le contexte le plus externe du fichier de configuration nginx. Toute instruction se trouve dans le contexte principal ou. contexte principal. Veuillez regarder l'exemple de fichier de configuration suivant :
1 # nginx.conf 2 worker_processes 2; 3 events { 4 use epoll; 5 worker_connections 1024; 6 } 7 http { 8 include mime.types; 9 upstream server_group_a {
10 server 192.168.1.1:8080;11 server 192.168.1.2:8080;12 }13 server {14 listen 80;15 server_name www.example.com;
16 location / {17 proxy_pass http://server_group_a; 18 }
19 }20 }Dans l'exemple ci-dessus, les instructions worker_processes, event et http sont dans le contexte principal, les instructions use et worker_connections sont dans le contexte de l'événement, et include Les instructions , amont et serveur sont situées dans le contexte http, et les deux instructions serveur sont situées dans le contexte amont...
le logiciel nginx est composé de modules avec diverses fonctions, le fichier de configuration suit donc également cette modularisation. Le module principal nginx fournit des instructions de configuration globale, et les instructions de configuration fonctionnelle sont fournies par d'autres modules fonctionnels. Les instructions work_processes et event dans l'exemple ci-dessus sont fournies par le module principal de nginx, tandis que l'instruction http est fournie par le module de fonction http et l'instruction proxy_pass est fournie par un sous-module du module http.
Lors de l'installation de nginx, certains modules fonctionnels couramment utilisés sont inclus par défaut. Les utilisateurs peuvent également choisir librement d'installer d'autres modules fonctionnels via la compilation et l'installation du code source. Lors de la configuration de nginx, vous pouvez trouver la documentation des modules fonctionnels. . La documentation expliquera quelles instructions ce module fonctionnel comprend et le contexte dans lequel ces instructions doivent être configurées. Cependant, il n'est pas fiable de savoir quelles instructions configurables il contient à partir du contexte (instructions), car les modules installés sont différents et. contient des instructions différentes. C'est également différent, donc la configuration de nginx nécessite une certaine expérience. Les débutants ne peuvent commencer qu'en se référant aux exemples d'autres personnes.
En plus de http, les modules fonctionnels incluent également mail (proxy mail) et stream (TCP, proxy UDP, v1.9.0 et versions ultérieures) Ces deux modules fonctionnels .
Syntaxe : include fichier | masque;
Valeur par défaut : aucun
Contexte : tout
peut être utilisé dans n'importe quel contexte pour introduire des directives dans d'autres fichiers de configuration dans le contexte de l'utilisation de la directive include. Les instructions importées doivent être conformes aux exigences de syntaxe et de contexte de l'introduction. Exemple :
http {
include mime.types;
include vhosts/*.conf;
}将mime.types和vhosts目录下以“.conf”结尾的文件引入到http语境中。
语法：deamon on | off;
默认值：deamon on
语境：main
指定nginx是否以守护进程运行。
语法：debug_points abort | stop;
默认值：无
语境：main
用于debug，判断nginx内部错误，特别是判断工作中进程的socket溢出问题。nginx代码中包含了一些调试点，如果debug_points设置为abord，当运行到调试点时会产生一个核心运行信息dump文件，当设置为stop时会停止进程。
语法：error_log file [level]
默认值：error_log logs/error.log error;
语境：main, http, mail(v1.9.0后), stream(v1.7.11后), server, location
指定日志文件和日志级别。
file可以是指定的文件，也可以是标准错误输出文件stderr、syslog服务器或内存。输出到syslog服务器使用“syslog:”前缀，输出到循环内存缓冲区使用“memory:”前缀和缓冲区大小。
level参数指定输出日志的级别，高于指定级别的日志将被输出。支持的级别从低到高依次有：debug、info、notice、warn、error、crit、alert、emerg。
指定debug级别需要编译时安装了debug模块。
语法：env variable[=value];
默认值：env TZ;
语境：main
默认情况下，nginx只会继承TZ这个环境变量，这条指令可以将环境变量传递到nginx进程中，也可以定义新的变量传递到nginx进程中。
语法：load_module file;
默认值：无
语境：main
载入动态模块。例如：
load_module module/ngx_mail_module.so;
语法：lock_file file;
默认值：lock_file logs/nginx.lock;
语境：main
nginx使用锁的机制来实现accept_mutex功能和共享内存，大多数操作系统中锁都是一个原子操作，这种情况下这条指令无效，还有一些操作系统中使用“锁文件”的的机制来实现锁，此命令用来指定锁文件前缀名。
语法：master_process on | off;
默认值：master_process on;
语境：main
是否启用worker进程，如果设置为off，则不启用worker进程，由master进程处理请求。
语法：pcre_jit on | off;
默认值：pcre_jit off;
语境：main
在解析配置文件时对正则表达式启用或禁用实时编译（PCRE JIT）。
RCRE JIT能显著提升正则表达式的处理速度。
JIT依赖PCRE库8.20以后版本，并且在编译时需要指定--enable-jit参数。也可以将PCRE库作为nginx的模块编译安装（编译nginx指定--with-pcre=参数），并在编译时指定--with-pcre-jit参数启用JIT功能。
语法：pid file;
默认值：pid nginx.pid;
语境：main
指定pid文件。pid文件存放了master进程的进程号。
语法：ssl_engine device;
默认值：无
语境：main
如果使用了硬件ssl加速设备，使用此指令指定。
语法：thread_pool name threads=number [max_queue=number];
默认值：thread_pool default threads=32 max_queue=65535;
语境：main
在使用异步IO的情况下，定义命名线程池，并设置线程池大小和等待队列大小。当线程池中所有线程都繁忙时，新任务会放在等待队列中，如果等待队列满了，任务会报错退出。
命名线程池可以定义多个，供http模块的异步线程指令（aio）调用。
此指令在v1.7.11中出现。
语法：timer_resolution interval;
默认值：无
语境：main
设置时间精度，减少worker进程调用系统时间函数的次数。默认情况下，每个核心事件都会调用gettimeofday()接口来获得系统时间，以便nginx计算连接超时等工作，此指令指定更新时间的间隔，nginx在间隔时间内只调用一次系统时间函数。
语法：user user [group];
默认值：user nobody nodoby;
语境：main
指定master启动worker进程使用的linux用户和组。如果组（group）没有指定，那么会默认用一个和user同名的组名。
语法：worker_processes number | auto
默认值：worker_processes 1
语境：main
指定worker进程的数量。进程数最好是CPU核心数或CPU核心数的倍数。当设置为auto时，nginx会尝试自动获取CPU核心数并设置。
auto参数从v1.3.8和v1.2.5版本以后支持。
语法：worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
默认值：无
语境：main
将worker进程绑定到CPU核心，每个worker进程对应一个二进制掩码，掩码的每一位对应一个CPU。默认情况下，worker不与cpu核心绑定。此指令只适用于Linux和FreeBSD。
举例：
worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;
表示有4个worker进程，第一个绑定到CPU0，第二个绑定到CPU1，以此类推，4个进程分别绑定一个CPU核心。
再例：
worker_processes 2; worker_cpu_affinity 0101 0101;
表示将第一个进程绑定到CPU0/CPU2，第二个worker进程绑定到CPU1/CPU3，这个例子适用于超线程场景，即一个核心虚拟出两个CPU线程。
值auto（v1.9.10）允许自动和可用的CPU绑定：
worker_process auto; worker_cpu_affinity auto;
掩码（mask）可用用于限制某些CPU参加绑定。例如：
worker_cpu_affinity auto 01010101;
只有CPU0/2/4/6参与绑定，其他的CPU不分配worker进程。
语法：worker_rlimit_core size;
默认值：无
语境：main
为worker进程修改系统核心转储文件（core file）的大小限制。通常提升这个值不需要重启主进程。
语法：worker_rlimit_nofile number;
默认值：无
语境：main
修改worker进程最大可打开句柄数限制。通常提升这个值不需要重启主进程。
语法：worker_shutdown_timeout time;
默认值：无
语境：main
此指令在v1.11.11中出现。用于设置安全地结束一个worker进程的超时时间。
当安全结束一个worker进程时，会停止对worker进程分配新连接，并等待他处理完当前的任务后再退出，如果设置了超时时间，超时后nginx会强制关闭worker进程的连接。
语法：working_directory directory;
默认值：无
语境：main
指定默认工作路径。主要用于worker进程导出内存转储文件，为worker进程指定的用户需要有改文件的写入权限。
语法：events { ... }
默认值：无
语境：main
作用只是开辟一个指令区块，events语境中配置的指令用于控制连接处理行为。
语法：accept_mutex on | off;
默认值：accept_mutex off;
语境：events
当启用这个参数时，会使用互斥锁交替给worker进程分配新连接，否则话所有worker进程会争抢新连接，即或造成所谓的“惊群问题”，惊群问题会使nginx的空闲worker进程无法进入休眠状态，造成系统资源占用过多。启用此参数会一定程度上导致后台服务器负载不均衡，但是在高并发的情况下，关闭此参数可以提高nginx的吞吐量。
在支持epoll的操作系统上不需要启用accept_mutex（v1.11.3后），使用了reuseport功能也不需要启用（v1.9.1后，需要操作系统支持SO_REUSEPORT socket选项，Linux 3.9+）。
在v1.11.3以前版本中，默认值为on。
语法：accept_mutex_delay time;
默认值：accept_mutex_delay 500ms;
语境：events
如果accept_mutex参数启用，当一个空闲worker进程尝试获取互斥锁时发现有另一个worker进程已经获得互斥锁并处理新连接，这个空闲的worker进程等待下一次获取互斥锁尝试的时间。而获得互斥锁的进程在处理完当前连接后，会立即尝试获取互斥锁，因此此数值较大或连接压力较小时，会造成部分worker进程总是空闲，一部分进程总是繁忙的情况。
语法：debug_connection address | network | unix:;
默认值：无
语境：events
需要debug模块支持，需确认安装时包括了debug模块，可以使用nginx -V命令确定包含--wih-debug参数。
对特定的客户发起的连接开启debugging级别日志，用于分析和拍错。可以指定IPv4或者IPv6地址（v1.3.0,v1.2.1）或一个无类网段或域名，或UNIX socket（v1.3.0,v1.2.1）。例如：
events {
debug_connection 127.0.0.1;
debug_connection localhost;
debug_connection 192.168.2.0/24;
debug_connection 2001:0db8::/32;
debug_connection unix:;
}Le niveau de journalisation des connexions non spécifiées est toujours déterminé par la directive error_log.
Syntaxe : multi_accept on off;
Valeur par défaut : multi_accept off;
Contexte : événements
Lorsqu'il est désactivé, un processus de travail ne gérera qu'une seule nouvelle connexion à la fois lorsqu'il acquiert le mutex If. set Si elle est activée, toutes les nouvelles connexions seront allouées au processus de travail qui obtient le verrou mutex actuel en même temps. Lors de l'utilisation de la méthode de traitement de connexion kqueue (utilisez kqueue), cette instruction n'est pas valide.
Syntaxe : utiliser méthode;
Valeur par défaut : Aucun
Contexte : événements
Spécifiez la méthode de traitement de la connexion, généralement il n'est pas nécessaire de spécifier, nginx utilisera automatiquement la méthode la plus efficace .
La méthode de traitement des connexions est utilisée pour déterminer la méthode à utiliser pour savoir quelles connexions sont prêtes à transmettre/recevoir des données du pool de connexions actuel. Les méthodes courantes de traitement des connexions sont :
select (nécessite le module de sélection), poll (nécessite le module de sondage), kqueue (macOS/FreeBSD 4.1+/OpenBSD 2.9+), epoll (Linux 2.6+), /dev/ poll (Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ et Tru64 UNIX 5.1A+), eventport (Solaris 10+)
Syntaxe : worker_aio_requests numéro;
Valeur par défaut : worker_aio_requests 32;
Contexte : les événements
sont apparus dans les v1.1.4 et 1.0.7. Lorsque le traitement des connexions aio (E/S asynchrones) et epoll est activé, nombre maximum d'opérations d'E/S asynchrones en attente pour un seul processus de travail.
Syntaxe : worker_connections numéro;
Valeur par défaut : work_connections 512;
Contexte : événements
Le nombre maximum de connexions simultanées qu'un seul processus de travail peut gérer.
Ce nombre de connexions inclut toutes les connexions au serveur backend, pas seulement les connexions aux clients. Le nombre total de connexions de tous les processus de travail (c'est-à-dire worker_connections × work_processes) ne peut pas dépasser la limite du nombre maximum de handles ouverts (nofile) du système d'exploitation. La limite nofile peut être modifiée via l'instruction worker_rlimit_nofile.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
redémarrage de nginx
Explication détaillée de la configuration de nginx
Explication détaillée de la configuration de nginx
Quelles sont les différences entre Tomcat et Nginx
Introduction aux fichiers de configuration php
Introduction aux plug-ins requis pour que vscode exécute Java
Comment démarrer le service MySQL
Solution aux propriétés du dossier Win7 ne partageant pas la page à onglet
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
