Nginx配置文件语法

Posted ryan16231112

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Nginx配置文件语法相关的知识,希望对你有一定的参考价值。

nginx配置语法

块配置项

块配置项由一个块配置项名和一对大括号组成。具体示例如下:

events {…
	
} 

http {
    upstream backend {
        server 127.0.0.1:8080;
    }
    gzip on;
    server {
        …
        location /webstatic {
        	gzip off;
        }
    }
}

上面代码段中的events、http、server、location、upstream等都是块配置项,块配置项之后是否如“location/webstatic{...}”那样在后面加上参数,取决于解析这个块配置项的模块,不能一概而论,但块配置项一定会用大括号把一系列所属的配置项全包含进来,表示大括号内的配置项同时生效。所有的事件类配置都要在events块中,http、server等配置也遵循这个规定。

块配置项可以嵌套。内层块直接继承外层块,例如,上例中,server块里的任意配置都是基于http块里的已有配置的。当内外层块中的配置发生冲突时,究竟是以内层块还是外层块的配置为准,取决于解析这个配置项的模块,第4章将会介绍http块内配置项冲突的处理方法。例如,上例在http模块中已经打开了“gzip on;”,但其下的location/webstatic又把gzip关闭了:gzip off;,最终,在/webstatic的处理模块中,gzip模块是按照gzip off来处理请求的。

语法格式

首先,在行首的是配置项名,这些配置项名必须是Nginx的某一个模块想要处理的,否则Nginx会认为配置文件出现了非法的配置项名。配置项名输入结束后,将以空格作为分隔符。

其次是配置项值,它可以是数字或字符串(当然也包括正则表达式)。针对一个配置项,既可以只有一个值,也可以包含多个值,配置项值之间仍然由空格符来分隔。一个配置项对应的值究竟有多少个,取决于解析这个配置项的模块。

最后,每行配置的结尾需要加上分号。

可以加“#”注释掉这一行配置。

许多模块在解析请求时都会提供多个变量(如本章后面提到的http core module、http proxy module、http upstream module等),以使其他模块的配置可以即时使用。我们在学习某个模块提供的配置说明时可以关注它是否提供变量。

基本配置

Nginx在运行时,至少必须加载几个核心模块和一个事件类模块。这些模块运行时所支持的配置项称为基本配置——所有其他模块执行时都依赖的配置项。

们按照用户使用时的预期功能分成了以下4类:

  • 用于调试、定位问题的配置项。
  • 正常运行的必备配置项。
  • 优化性能的配置项。
  • 事件类配置项(有些事件类配置项归纳到优化性能类,这是因为它们虽然也属于events{}块,但作用是优化性能)。

用于调试、定位问题的配置项

  • 是否以守护进程方式运行Nginx

    语法: daemon on|off;
    默认: daemon on;
    

    守护进程(daemon)是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示,这样一来,进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务,因此,默认都是以这种方式运行的。

  • 是否以master/worker方式工作

    语法: master_process on|off;
    默认: master_process on;
    
  • error日志设置

    语法: error_log pathfile level;
    默认: error_log logs/error.log error;
    

    pathfile参数可以是一个具体的文件,例如,默认情况下是logs/error.log文件,最好将它放到一个磁盘空间足够大的位置;pathfile也可以是/dev/null,这样就不会输出任何日志了,这也是关闭error日志的唯一手段;pathfile也可以是stderr,这样日志会输出到标准错误文件中。

    level是日志的输出级别,取值范围是debug、info、notice、warn、error、crit、alert、emerg,从左至右级别依次增大。当设定为一个级别时,大于或等于该级别的日志都会被输出到pathfile文件中,小于该级别的日志则不会输出。

  • 是否处理几个特殊的调试点

    语法: debug_points[stop|abort]
    

    用来帮助用户跟踪调试Nginx的。它接受两个参数:stop和abort。Nginx在一些关键的错误逻辑中(Nginx 1.0.14版本中有8处)设置了调试点。如果设置了debug_points为stop,那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。如果debug_points设置为abort,则会产生一个coredump文件,可以使用gdb来查看Nginx当时的各种信息。

  • 仅对指定的客户端输出debug级别的日志

    语法: debug_connection[IP|CIDR]
    

    这个配置项实际上属于事件类配置,因此,它必须放在events{...}中才有效。它的值可以是IP地址或CIDR地址.仅仅来自以上IP地址的请求才会输出debug级别的日志,其他请求仍然沿用error_log中配置的日志级别。

  • 限制coredump核心转储文件的大小

    语法: worker_rlimit_core size;
    

    当Nginx进程出现一些非法操作(如内存越界)导致进程直接被操作系统强制结束时,会生成核心转储core文件,可以从core文件获取当时的堆栈、寄存器等信息,从而帮助我们定位问题。通过worker_rlimit_core配置可以限制core文件的大小,从而有效帮助用户定位问题。

  • 指定coredump文件生成目录

    语法: working_directory path;
    

    worker进程的工作目录。这个配置项的唯一用途就是设置coredump文件所放置的目录,协助定位问题。因此,需确保worker进程有权限向working_directory指定的目录中写入文件。

正常运行的配置项

  • 定义环境变量

    语法: env VAR|VAR=VALUE
    例如: env TESTPATH=/tmp/;
    

    这个配置项可以让用户直接设置操作系统上的环境变量。

  • 嵌入其他配置文件

    语法: includepathfile;
    例如: include mime.types;
    

    include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中,它的参数既可以是绝对路径,也可以是相对路径(相对于Nginx的配置目录,即nginx.conf所在的目录)

  • pid文件的路径

    语法: pid path/file;
    默认: pid logs/nginx.pid;
    

    保存master进程ID的pid文件存放路径。默认与configure执行时的参数“--pid-path”所指定的路径是相同的,也可以随时修改,但应确保Nginx有权在相应的目标中创建pid文件,该文件直接影响Nginx是否可以运行。

  • Nginx worker进程运行的用户及用户组

    语法: user username[groupname];
    默认: user nobody nobody;
    

    user用于设置master进程启动后,fork出的worker进程运行在哪个用户和用户组下。当按照“user username;”设置时,用户组名与用户名相同。

  • 指定Nginx worker进程可以打开的最大句柄描述符个数

    语法: worker_rlimit_nofile limit;
    

    设置一个worker进程可以打开的最大文件句柄数。

  • 限制信号队列

    语法: worker_rlimit_sigpending limit;
    

    设置每个用户发往Nginx的信号队列的大小。也就是说,当某个用户的信号队列满了,这个用户再发送的信号量会被丢掉。

优化性能的配置项

  • worker进程个数

    语法: worker_processes number;
    默认: worker_processes 1;
    

    每个worker进程都是单线程的进程,它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用,那么,有多少CPU内核就应该配置多少个进程;反之,如果有可能出现阻塞式调用,那么需要配置稍多一些的worker进程。

  • 绑定Nginx worker进程到指定的CPU内核

    语法: worker_cpu_affinity cpumask[cpumask...]
    例如:
    worker_processes 4;
    worker_cpu_affinity 1000 0100 0010 0001;
    
  • SSL硬件加速

    语法: ssl_engine device;
    

    如果服务器上有SSL硬件加速设备,那么就可以进行配置以加快SSL协议的处理速度。用户可以使用OpenSSL提供的命令来查看是否有SSL硬件加速设备

  • 系统调用gettimeofday的执行频率

    语法: timer_resolution t;
    

    默认情况下,每次内核的事件调用(如epoll、select、poll、kqueue等)返回时,都会执行一次gettimeofday,实现用内核的时钟来更新Nginx中的缓存时钟。在早期的Linux内核中,gettimeofday的执行代价不小,因为中间有一次内核态到用户态的内存复制。当需要降低gettimeofday的调用频率时,可以使用timer_resolution配置。例如,“timer_resolution100ms;”表示至少每100ms才调用一次gettimeofday。

    但在目前的大多数内核中,如x86-64体系架构,gettimeofday只是一次vsyscall,仅仅对共享内存页中的数据做访问,并不是通常的系统调用,代价并不大,一般不必使用这个配置。而且,如果希望日志文件中每行打印的时间更准确,也可以使用它。

  • Nginx worker进程优先级设置

    语法: worker_priority nice;
    默认: worker_priority 0;
    

    优先级由静态优先级和内核根据进程执行情况所做的动态调整(目前只有±5的调整)共同决定。nice值是进程的静态优先级,它的取值范围是–20~+19,–20是最高优先级,+19是最低优先级。因此,如果用户希望Nginx占有更多的系统资源,那么可以把nice值配置得更小一些,但不建议比内核进程的nice值(通常为–5)还要小。

事件类配置项

  • 是否打开accept锁

    语法: accept_mutex[on|off]
    默认: accept_mutext on;
    

    accept_mutex是Nginx的负载均衡锁。这把锁可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接。当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时,会大大地减小该worker进程试图建立新TCP连接的机会,以此实现所有worker进程之上处理的客户端请求数尽量接近。

  • lock文件的路径

    语法: lock_file path/file;
    默认: lock_file logs/nginx.lock;
    

    accept锁可能需要这个lock文件,如果accept锁关闭,lock_file配置完全不生效。如果打开了accept锁,并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁,这时才会用文件锁实现accept锁,这样lock_file指定的lock文件才会生效。

  • 使用accept锁后到真正建立连接之间的延迟时间

    语法: accept_mutex_delay Nms;
    默认: accept_mutex_delay 500ms;
    

    在使用accept锁后,同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁,如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到,它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。

  • 批量建立新连接

    语法: multi_accept[on|off];
    默认: multi_accept off;
    

    当事件模型通知有新连接时,尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。

  • 选择事件模型

    语法: use[kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
    默认: Nginx会自动使用最适合的事件模型。
    

    对于Linux操作系统来说,可供选择的事件驱动模型有poll、select、epoll三种。epoll当然是性能最高的一种.

  • 每个worker的最大连接数

    语法: worker_connections number;
    

以上是关于Nginx配置文件语法的主要内容,如果未能解决你的问题,请参考以下文章

Nginx配置文件详细介绍

配置使用vim编辑Nginx配置文件时语法高亮

Nginx——Nginx启动报错Job for nginx.service failed because the control process exited with error code(代码片段

Nginx——Nginx的默认配置语法(Centos7通过yum方式安装)

nginx 默认配置语法和日志的format

Nginx配置文件的通用语法