nginx 구성 파일은 지시문으로 구성됩니다. 명령어는 단순 명령어와 블록 명령어의 두 가지 형태로 나뉩니다.
A simple command는 명령 이름, 매개변수 및 후행 세미콜론(;)으로 구성됩니다. 예: listen 80 backlog 4096; 여기서 "listen"은 명령 이름 "80"입니다. "backlog" "와 "4096"은 모두 매개변수이고, ";"는 명령의 끝을 나타냅니다.
Block command는 명령 이름, 매개변수 및 중괄호({})로 구성됩니다. 예: location /imag {}, 여기서 "location"은 명령 이름, "/imag"는 매개변수, "{ }" 다른 지침을 포함하고 끝을 나타내는 데 사용됩니다. 블록 명령어의 중괄호에 다른 간단한 명령어나 블록 명령어가 포함될 수 있는 경우 이 블록 명령어를 "context(컨텍스트)"라고 합니다. 가장 일반적으로 사용되는 블록 명령어는 "context" "입니다.
다른 블록 명령어에 포함되지 않은 명령어는 기본 컨텍스트에 있는 것으로 간주됩니다. 즉, 기본 컨텍스트는 nginx 구성 파일의 가장 바깥쪽 컨텍스트이고 모든 명령어는 기본 컨텍스트 또는 하위 컨텍스트에 있습니다. 환경에서 주요 컨텍스트의 언어. 다음 구성 파일 예를 살펴보십시오.
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 }위 예에서 작업자_프로세스, 이벤트 및 http 지침은 기본 컨텍스트에 있고, 사용 및 작업자_연결 지침은 이벤트 컨텍스트에 있으며, 포함, 업스트림, 및 서버 명령어는 http 컨텍스트에 있으며, 두 개의 서버 명령어는 업스트림 컨텍스트에 있습니다...
nginx 소프트웨어는 다양한 기능을 가진 모듈로 구성되므로 구성 파일도 이러한 모듈 구조를 따릅니다. 전역 구성 지침 및 기능 구성 지침은 다른 기능 모듈에서 제공됩니다. 위 예의 Worker_processes 및 이벤트 명령어는 nginx의 핵심 모듈에서 제공되는 반면, http 명령어는 http 함수 모듈에서 제공되고, Proxy_pass 명령어는 http 모듈의 하위 모듈에서 제공됩니다.
nginx를 설치하면 일반적으로 사용되는 일부 기능 모듈이 기본적으로 포함됩니다. 사용자는 소스 코드 컴파일 및 설치를 통해 다른 기능 모듈을 자유롭게 선택할 수도 있습니다. nginx를 구성할 때 설명하는 기능 모듈에 대한 설명서를 찾을 수 있습니다. 이 기능 모듈에는 어떤 지침이 포함되어 있는지, 어떤 컨텍스트에서 이러한 지침을 구성해야 하는지, 설치된 다른 모듈에는 다른 지침이 포함되어 있기 때문에 컨텍스트(명령어)에서 포함된 구성 가능한 지침을 찾는 것은 신뢰할 수 없습니다. 초보자는 다른 사람의 예를 참조해야만 시작할 수 있습니다.
http 외에도 기능 모듈에는 메일(메일 프록시) 및 스트림(TCP, UDP 프록시, v1.9.0 이상)도 포함됩니다이 두 가지 기능 모듈.
구문: include file | mask;
기본값: 없음
컨텍스트: 중고에서 사용 가능한 모든
어떤 컨텍스트에서든지 다른 구성 파일의 지시어를 include 지시어가 사용되는 컨텍스트에 도입하세요. 가져온 지침은 소개의 구문 및 컨텍스트 요구 사항을 준수해야 합니다. 예:
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:;
}지정되지 않은 연결의 로그 수준은 여전히 error_log 지시어에 의해 결정됩니다.
구문: multi_accept on | off;
기본값: multi_accept off;
이벤트
뮤텍스 잠금 하나만 새로운 연결은 한 번에 처리되며, on으로 설정하면 현재 mutex lock을 획득한 작업자 프로세스에 모든 새로운 연결이 할당됩니다. kqueue 연결 처리 방법(kqueue 사용)을 사용하는 경우 이 명령은 유효하지 않습니다.
구문: use method;
기본값: None
context: events
연결 처리 방법을 지정합니다. 일반적으로 지정할 필요가 없습니다. nginx는 자동으로 가장 효과적인 방법.
연결 처리 방법은 현재 연결 풀에서 데이터를 전송/수신할 준비가 된 연결을 찾는 데 사용할 방법을 결정하는 데 사용됩니다. 일반적인 연결 처리 방법은 다음과 같습니다:
select(선택 모듈 필요), poll(폴링 모듈 필요), kqueue(macOS/FreeBSD 4.1+/OpenBSD 2.9+), epoll(Linux 2.6+), /dev/poll(Solaris 7 11 /99+, HP/UX 11.22+(이벤트 포트), IRIX 6.5.15+ 및 Tru64 UNIX 5.1A+), 이벤트 포트(Solaris 10+)
구문: worker_aio_requests number;
기본값: Worker_aio_requests 32;
컨텍스트: 이벤트
v1.1.4 및 1.0.7에 나타납니다. aio(비동기 IO) 및 epoll 연결 처리가 활성화된 경우 단일 작업자 프로세스에 대한 미해결 비동기 IO 작업의 최대 수입니다.
구문: worker_connections number;
기본값: Worker_connections 512;
Context: events
처리된 동시 연결 수입니다.
이 연결 수에는 클라이언트 연결뿐만 아니라 백엔드 서버에 대한 모든 연결이 포함됩니다. 모든 작업자 프로세스의 총 연결 수(즉, 작업자_연결 × 작업자_프로세스)는 운영 체제의 최대 열린 핸들 수(nofile) 제한을 초과할 수 없습니다. nofile 제한은 작업자_rlimit_nofile 명령어를 통해 수정할 수 있습니다.
위 내용은 Nginx 구성 파일 예제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
