Nginx配置文件详解

共计 10245 个字符，预计需要花费 26 分钟才能阅读完成。

下面我们来分析 nginx 配置文件的组成：

一. 简要介绍：

1.nginx 的配置文件分为两个部分：

核心配置段：Main 配置段

对应协议配置段：如 http{…}

2. 配置指令以分号结尾，语法格式：

directive value1 [value2……]:

支持使用变量：

模块内置变量

自定义变量

set var_name value

3. 主配置段指令的类别：

用于调试，定位问题的配置；

正常运行必备配置；

优化性能的配置；

事件相关配置：主控进程以 root 启动，worker 进程是以普通用户运行

二. 主配置段文件详解：

A. 正常运行的必备配置；

1.user USERNAME[GROUPNAME]

指定运行 worker 进程的用户和组；

user nginx nginx;

2.pid /path/to/pid_file

指定 pid 文件

3.worker_rlimit_nofile  #;

指定一个进程所能打开最大文件句柄数；

4.worker_rlimit_sigpending  #;

指定每个用户能够发往 worker 进程的信号的数量；

B. 优化性能相关配置：

1.worker_processes 1;

启动的 worker 线程个数；通常为物理 CPU 核心数减 1；

2.worker_cpu_affinity cpumask……;

绑定启动的 worker 进程到指定的 CPU 上；

CPU 个数 < 进程数，服务器需要发生进程切换；nginx 工作在一个进程响应多个请求的模型下，多个 worker 进程在没有请求的情况下工作在睡眠态，只有有请求到达后内核调用 worker 进程到 CPU 中执行，这样就会造成上下文切换和进程会在 CPU 上制造缓存，执行完成后 worker 进程会退出 CPU 进入睡眠态，缓存失效，而后来进入的 worker 进程会重新生成缓存，造成服务器性能降低。

可以在系统启动时将除了系统启动的其他 CPU 隔离出来，绑定 worker 进程到指定 CPU 上，CPU 的使用权就是特定的 worker 进程，可以大大提高服务器性能。

cpumask：CPU 掩码

0001

0010

0100

1000

如：

worker_cpu_affinity 0000001 00000010 00000100

3.timer_resolution t;

时间解析度，值大些好，越小越精致，但是消耗大，在 x86_64 系统上可以不设置；

指的是每一次内核调用返回时都会使用 gettimeoutday() 系统调用来更新 nginx 的缓存时钟，time_resolution 定义每隔多久 gettimeoutday 更新一次缓存；更新越频繁系统压力越大；

4.worker_priority nice;

让 worker 以指定 nice 值工作,-20~19

nice 值越高就会优先获取 CPU 资源；

nginx 默认状态下的 nice 值为 0：

[root@www ~]# ps axo pid,command,nice |grep nginx

4530 nginx: master process /usr/  0

4532 nginx: worker process        0

4613 grep nginx                    0

C. 事件相关配置：

1.accept_mutex [on|off]

mutex: 互斥锁，是否打开 nginx 的内部负载均衡锁

内部调度用户请求到各 worker 时用的负载均衡锁，打开时表示让多个 worker 进程轮流的，序列化的响应新请求；

2.lock_file  /path/to/lock_file;

锁文件

3.accept_mutex_delay  #ms;

内部的负载均衡锁在接收请求时的请求延迟，一个 worker 进程为了等待获取互斥锁要等待的时间延迟；

4.use [epoll|rgsig|select|poll]

指明定义使用何种事件模型的; 建议让 nginx 自动选择

5.worker_connections  #;

每个 worker 进程所能响应的最大并发请求数

D. 用于调试定位问题：

1.deamon [off|on]

是否以守护进程模式启动 nginx，发生问题时关闭所有信息发送到前台

2.master_process [on|off]

是否以 master/worker 模式来运行 nginx，发生问题时关闭，只启动 master, 让所有请求直接发送给 master 执行响应；

3.error_log  /path/to/error_log  level;

错误日志文件及其级别；出于调试的目的，可以使用 debug 级别，但此级别只有在编译 nginx 时使用 了 –with-debug 选项才有效；

————————————– 分割线 ————————————–

CentOS 6.2 实战部署 Nginx+MySQL+PHP http://www.linuxidc.com/Linux/2013-09/90020.htm

使用 Nginx 搭建 WEB 服务器 http://www.linuxidc.com/Linux/2013-09/89768.htm

搭建基于 Linux6.3+Nginx1.2+PHP5+MySQL5.5 的 Web 服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm

CentOS 6.3 下 Nginx 性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm

CentOS 6.3 下配置 Nginx 加载 ngx_pagespeed 模块 http://www.linuxidc.com/Linux/2013-09/89657.htm

CentOS 6.4 安装配置 Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm

Nginx 安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm

Nginx 日志过滤 使用 ngx_log_if 不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm

————————————– 分割线 ————————————–

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-12/110946p2.htm

http 配置段详解：

http core 配置一个静态 web 服务器

使用的模块：

ngx_http_core_module

一个 http 的配置框架：

http {

upstream {

……后端服务器

}

server {

linsten  ip:port;# 监听端口

# 虚拟主机

location  /URL {

if …{

……

}

root “/path/to/somewhere”;  #网站目录

……

认证

}

}

server {

……

}

}

注意：

所有 http 相关配置必须位于 http，server，location，upstream，if 块中

在对应 server 块中有 listen;

配置 Nginx 为 web 服务器使用：

一. 虚拟主机配置：

1. 定义一个虚拟主机

server {

}

2. 指明监听端口，配置很复杂哦！

listen

常用格式：

listen address[:port] [default_server] ssl

完整格式：

listen address[:port] [default_server] [ssl] [spdy] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on|off] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];

backlog=number：指明 tcp 协议的 backlog 队列的大小，默认为 -1，表示不设置

后援队列

rcvbuf=size：设定监听句柄的 SO_RCVBUF 参数的值，接收缓冲大小

sndbuf=size：发送缓冲大小

对一个端口监听多个地址生效

实例：listen  172.16.31.30:8080；

3. 服务器名称，对应 http 中的主机名

server_name name[…];

后可跟多个主机名，名称可以使用通配符和正则表达式；以~ 开头

判断流程：

(1). 先做精确匹配；例如：www.linuxidc.com

(2). 左侧通配符匹配；例如:*.linuxidc.com

(3). 右侧通配符匹配；例如：www.*

(4). 正则表达式匹配；例如：~^.*\.linuxidc\.com$

(5). 最后由 listen 中的 default_server 响应

4. 允许根据用户请求的 URI 来匹配定义的各 location，匹配到时，此请求将被相应的 location 块中的配置所处理；

location [=|~|~*|^~]/uri{……}

location @name

~      #波浪线表示执行一个正则匹配，区分大小写

~*    #表示执行一个正则匹配，不区分大小写

^~    #^~ 表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录

=      #进行普通字符精确匹配

@      #”@” 定义一个命名的 location，使用在内部定向时，例如 error_page, try_files

 实例：

server {

location /images {}

location /bbs {}

location / {}

}

匹配优先级：

= 精确匹配会第一个被处理。如果发现精确匹配，nginx 停止搜索其他匹配。

普通字符匹配，正则表达式规则和长的块规则将被优先和查询匹配，也就是说如果该项匹配还需去看有没有正则表达式匹配和更长的匹配。

^~ 则只匹配该规则，nginx 停止搜索其他匹配，否则 nginx 会继续处理其他 location 指令。

最后匹配理带有 ”~” 和 ”~*” 的指令，如果找到相应的匹配，则 nginx 停止搜索其他匹配；当没有正则表达式或者没有正则表达式被匹配的情况下，那么匹配程度最高的逐字匹配指令会被使用。

location  = / {

  # 只匹配 ”/”.

  [configuration A]

}

location  / {

  # 匹配任何请求，因为所有请求都是以 ”/” 开始

  # 但是更长字符匹配或者正则表达式匹配会优先匹配

  [configuration B]

}

location ^~ /images/ {

  # 匹配任何以 /images/ 开始的请求，并停止匹配 其它 location

  [configuration C]

}

location ~* \.(gif|jpg|jpeg)$ {

  # 匹配以 gif, jpg, or jpeg 结尾的请求.

  # 但是所有 /images/ 目录的请求将由 [Configuration C] 处理. 

  [configuration D]

}

请求 URI 例子:

/ -> 符合 configuration A

/documents/document.html -> 符合 configuration B

/images/1.gif -> 符合 configuration C

/documents/1.jpg -> 符合 configuration D

@location 例子

error_page 404 = @error;

location @error(

proxy_pass http://error;

)

5. 设置 web 资源路径映射：用于指明请求的 URL 所对应的文档的目录路径

root path

实例：若按照这种配置的话，则访问 /images/ 目录下的文件时，nginx 会去 /www/pictures/images/ 文件目录下找文件。

location /images {

root “/www/pictures”;

}

6. 用于 location 配置段，定义路径别名

alias path

例如：若按照下面配置的话，则访问 /images/ 目录里面的文件时，ningx 会自动去 /www/pictures/ 文件目录下找文件

location /images {

alias  /www/pictures/;

}

注意：

1).alias 是一个目录别名的定义，root 则是最上层目录的定义。

2).root 是指的是 /www/pictures/images/

3).alias 后面必须要用“/”结束，否则会找不到文件的; 而 root 则可有可无.

7. 默认主页面

index file

如：index  index.html

8. 自定义错误页面

error_page  code  […] [=code] URI|@name

根据 http 状态码重定向错误页面

=code：也可以自定义状态码，以指定响应码进行响应；

=：后不加状态码，以新请求资源的响应结果来作为响应码

name：是另外一个 location 定义的名称，可能是交由后端的代理服务器请求

例如：

error_page  404 /404.html

重定向：

相对路径：对于 root 定义的根目录下

绝对路径：可以使用重定向到其他服务器的主页

9. 一个请求由多个页面来响应

try_files  path1[,path2,……] URI

如果多个页面都没响应就重定向至最后一个 URI 路径中

二. 网络连接相关配置：

1. 保持连接的超时时长，默认为 75s；

keepalive_timeout  time;

2. 在一次保持连接上允许承载的最大资源请求数；

keepalive_requests  #;

3. 为指定类型的浏览器禁用保持连接

keepalive_disable [msie6|safari|none]

4.tcp 延迟发送，会带来体验下降；对长连接是否使用 TCP_NODELAY 选项；

tcp_nodelay  on|off

5. 读取 http 请求报文首部的超时时长；

client_header_timeout  time;

6. 读取 http 请求报文 body 部分的超时时长；网速慢的用户上传慢

client_body_timeout  time;

7. 发送响应报文的超时时长；

send_timeout  time;

三. 对客户端请求进行限制：

1. 对客户端请求限制方法；

指定对范围之外的其他方法的访问控制

limit_except  METHOD  {……}

如：对指定范围外使用 GET 请求的除了允许 172.16.0.0/16 网段的主机使用，其他都拒绝。

limit_except  GET {

allow  172.16.0.0/16;

deny all;

}

2. 限制请求报文中 body 报文的上限多大；通过检测请求报文中的“Content_Length” 来判定；

client_body_max_size  SIZE;

3. 限制客户端每秒钟传输的字节数，默认为 0，表示无限制；

limit_rate  speed;

四. 对内存或磁盘资源进行分配：

1.http 请求报文的 body 部分是否存储在磁盘文件中；on 和 clean 都表示允许，on 表示请求结束后报文 body 部分暂存内容不会被删除，clean 表示请求结束后报文 body 部分会被删除；off 表示关闭此功能（不允许暂存）

client_body_in_file_only  on|clean|off;

2. 请求报文的 body 部分是否能存储在内核内存的 buffer 中；默认为关闭的

允许会提高性能

client_body_in_single_buffer  on|off

3. 在内存中开辟多大空间暂存请求报文 body 部分

client_body_buffer_size  SIZE;

4. 请求报文 body 暂存路径，可以指定多级目录

client_body_temp_path DIR [level1[level2[level3[level4]]]]

例如：

client_body_temp_path  /var/tmp/nginx/client    1    2

5. 接收请求报文 header 部分分配的内存中缓存的大小；

client_header_buffer_size  SIZE;

五.MIME 类型相关的配置：

1. 定义 MIME types 到文件的扩展名

types {}

例如：

types {

test/html  .html

image/jpeg  .jpg

}

2. 指明默认 MIME 类型；

default_type  MIME-TYPE

六. 文件操作优化相关配置：

1. 是否启用 sendfile() 进行网络传输；

来看一下用 sendfile() 来进行网络传输的过程：

sendfile(socket,file, len);

硬盘 >> kernel buffer (快速拷贝到 kernelsocket buffer) >> 协议栈

1、系统调用 sendfile() 通过 DMA 把硬盘数据拷贝到 kernel buffer，然后数据被 kernel 直接拷贝到另外一个与 socket 相关的 kernel buffer。这里没有 user mode 和 kernel mode 之间的切换，在 kernel 中直接完成了从一个 buffer 到另一个 buffer 的拷贝。

2、DMA 把数据从 kernelbuffer 直接拷贝给协议栈，没有切换，也不需要数据从 user mode 拷贝到 kernel mode，因为数据就在 kernel 里。

步骤减少了，切换减少了，拷贝减少了，自然性能就提升了。

sendfile  on|off

sendfile64  on |off

2. 是否启用内核级别异步 IO

aio  on|off

3. 是否启用直接 IO

是否使用 O -DIRECT 选项去请求读取文件；缓冲区大小，快速直接写入读取磁盘，与 sendfile 互斥；尽量关闭；

directio  size|off;

4.nginx 可以缓存以下三种信息：

 (1). 文件句柄，文件大小和最近一次修改时间；

 (2). 打开目录的目录结构；

 (3). 没用找到的或者没有权限操作的文件的相关信息；

open_file_cache  max=N[inactive=time] |off;

 max 表示缓存条目的最大条目上限，一旦到达上限，则会使用 LRU（最近最少使用）从缓存中删除最近最少使用的条目；

 inactive=time: 在 inactive 指定时长内没有被访问的缓存条目就会淘汰；

5. 是否缓存在文件缓存中缓存打开文件时出现找不到路径，没有权限等的错误信息；

open_file_cache_errors  on|off

6. 每隔多长时间检查一次缓存中缓存条目的有效性；默认为 60 秒；

openFile_cache_min_users time;

Nginx 的详细介绍 ：请点这里
Nginx 的下载地址 ：请点这里

下面我们来分析 nginx 配置文件的组成：

一. 简要介绍：

1.nginx 的配置文件分为两个部分：

核心配置段：Main 配置段

对应协议配置段：如 http{…}

2. 配置指令以分号结尾，语法格式：

directive value1 [value2……]:

支持使用变量：

模块内置变量

自定义变量

set var_name value

3. 主配置段指令的类别：

用于调试，定位问题的配置；

正常运行必备配置；

优化性能的配置；

事件相关配置：主控进程以 root 启动，worker 进程是以普通用户运行

二. 主配置段文件详解：

A. 正常运行的必备配置；

1.user USERNAME[GROUPNAME]

指定运行 worker 进程的用户和组；

user nginx nginx;

2.pid /path/to/pid_file

指定 pid 文件

3.worker_rlimit_nofile  #;

指定一个进程所能打开最大文件句柄数；

4.worker_rlimit_sigpending  #;

指定每个用户能够发往 worker 进程的信号的数量；

B. 优化性能相关配置：

1.worker_processes 1;

启动的 worker 线程个数；通常为物理 CPU 核心数减 1；

2.worker_cpu_affinity cpumask……;

绑定启动的 worker 进程到指定的 CPU 上；

CPU 个数 < 进程数，服务器需要发生进程切换；nginx 工作在一个进程响应多个请求的模型下，多个 worker 进程在没有请求的情况下工作在睡眠态，只有有请求到达后内核调用 worker 进程到 CPU 中执行，这样就会造成上下文切换和进程会在 CPU 上制造缓存，执行完成后 worker 进程会退出 CPU 进入睡眠态，缓存失效，而后来进入的 worker 进程会重新生成缓存，造成服务器性能降低。

可以在系统启动时将除了系统启动的其他 CPU 隔离出来，绑定 worker 进程到指定 CPU 上，CPU 的使用权就是特定的 worker 进程，可以大大提高服务器性能。

cpumask：CPU 掩码

0001

0010

0100

1000

如：

worker_cpu_affinity 0000001 00000010 00000100

3.timer_resolution t;

时间解析度，值大些好，越小越精致，但是消耗大，在 x86_64 系统上可以不设置；

指的是每一次内核调用返回时都会使用 gettimeoutday() 系统调用来更新 nginx 的缓存时钟，time_resolution 定义每隔多久 gettimeoutday 更新一次缓存；更新越频繁系统压力越大；

4.worker_priority nice;

让 worker 以指定 nice 值工作,-20~19

nice 值越高就会优先获取 CPU 资源；

nginx 默认状态下的 nice 值为 0：

[root@www ~]# ps axo pid,command,nice |grep nginx

4530 nginx: master process /usr/  0

4532 nginx: worker process        0

4613 grep nginx                    0

C. 事件相关配置：

1.accept_mutex [on|off]

mutex: 互斥锁，是否打开 nginx 的内部负载均衡锁

内部调度用户请求到各 worker 时用的负载均衡锁，打开时表示让多个 worker 进程轮流的，序列化的响应新请求；

2.lock_file  /path/to/lock_file;

锁文件

3.accept_mutex_delay  #ms;

内部的负载均衡锁在接收请求时的请求延迟，一个 worker 进程为了等待获取互斥锁要等待的时间延迟；

4.use [epoll|rgsig|select|poll]

指明定义使用何种事件模型的; 建议让 nginx 自动选择

5.worker_connections  #;

每个 worker 进程所能响应的最大并发请求数

D. 用于调试定位问题：

1.deamon [off|on]

是否以守护进程模式启动 nginx，发生问题时关闭所有信息发送到前台

2.master_process [on|off]

是否以 master/worker 模式来运行 nginx，发生问题时关闭，只启动 master, 让所有请求直接发送给 master 执行响应；

3.error_log  /path/to/error_log  level;

错误日志文件及其级别；出于调试的目的，可以使用 debug 级别，但此级别只有在编译 nginx 时使用 了 –with-debug 选项才有效；

————————————– 分割线 ————————————–

CentOS 6.2 实战部署 Nginx+MySQL+PHP http://www.linuxidc.com/Linux/2013-09/90020.htm

使用 Nginx 搭建 WEB 服务器 http://www.linuxidc.com/Linux/2013-09/89768.htm

搭建基于 Linux6.3+Nginx1.2+PHP5+MySQL5.5 的 Web 服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm

CentOS 6.3 下 Nginx 性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm

CentOS 6.3 下配置 Nginx 加载 ngx_pagespeed 模块 http://www.linuxidc.com/Linux/2013-09/89657.htm

CentOS 6.4 安装配置 Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm

Nginx 安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm

Nginx 日志过滤 使用 ngx_log_if 不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm

————————————– 分割线 ————————————–

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-12/110946p2.htm