nginx 配置随笔

配置文件结构

 

一份简单的nginx配置，了解nginx配置文件的结构

user www www;
worker_processes auto;
worker_rlimit_nofile 65535;

error_log logs/error.log;
pid logs/nginx.pid;

events {    
    worker_connections 65535;    
    use epoll;
}

http {    
    charset utf-8;
    client_header_buffer_size 8k;
    client_max_body_size 50m;
    client_body_timeout 10s;
    client_header_timeout 5s;
    large_client_header_buffers 8 4k;

    server_tokens off;     
    server_name_in_redirect off;
    server_names_hash_bucket_size 128;

    include mime.types;
    default_type application/octet-stream;

    log_format main '$http_host [$time_local] "$request" request_length '
                    '$status $body_bytes_sent $request_time "$http_referer" '
                    '"$http_user_agent"';
    upstream backend {
        server 127.0.0.1:80;    
    }    

    server {
        listen 80 default_server;
        server_name _ ;
        root /data0/www/htdocs/default;
        access_log /data0/www/logs/default-access_log main; 
        error_log /data0/www/logs/default-error_log;
        rewrite ^/(.*) http://www.qfedu.com/$1 permanent;
        location / {
            include fastcgi_params;
            fastcgi_pass 127.0.0.1:8998
        ｝
    ｝
｝

踢掉里面的基础指令，应该是如下形式：

user www www;
worker_processes auto;
worker_rlimit_nofile 65535;
...
...

events {
    ...
}

http {
    ...
    upstream {
        ...
    }
    server {
        ...
        location / {
            ...
        }
    }
}

我们发现 Nginx 配置文件的结构包含 events 、http、upstream、server、location 这 5 大块。另外我们发现一些指令不包含在这 5 块中， 我们称他们为main指令。每块具体意义如下:

各个模块作用：

main模块:         主要控制nginx子进程的所属用户/用户组、派生子进程数、错误日志位置/级别、pid位置、进程对应cpu、进程能够打开的文件描述符数目等。

events模块:      控制nginx处理连接的方式。

http模块:          是nginx处理http请求的主要配置模块，有关http的相关都在这个块中进行配置。

upstream模块: 包含在http块中，是nginx做反向代理和负载均衡的配置块，可以配置多个。

server模块:       包含在http块中，是nginx中虚拟主机的配置块，可以配置多个。

location模块:    包含在server块中，是server中对应的目录级别的控制块，可以配置多个。

---

基础配置指令

 

1、配置运行nginx 的用户和组

user user [group]

user, 指定可以运行Nginx 服务器的用户

group, 可选项，指定运行Nginx 服务器的用户组

2、配置运行生产的worker process 数

worker_processes number | auto;

numbers, 指定Nginx 进程最多可以产生worker process 数,默认情况 numbers = 1

auto, 设置此值，Nginx 将自动检测CPU核心数，并将worker process 数量设置成等同CPU核心数量

3、配置nginx 打开最大文件数

worker_rlimit_nofile number;

number, 设置 worker 进程打开最大文件数

4、配置nginx最大连接数

worker_connections numbers;

numbers 设置一个 worker 进程的最大网络连接数

5、配置nginx 进程PID 存放路径

pid /path/file;

6、配置错误日志的存放路径

error_log file|stderr [debug|info|notice|warn|error|crit|alert|emerg];

从语法结构上看，Nginx服务器的日志支持输出到某个固定的文件file或者输出到标准错误输出stderr; 日志的级别是

可选项，由低到高为debug(需要在编译的时候使用--with-debug 开启debug开关)到 emerg。需要注意的是，设置某

一级别后，比这一级别高的日志也会被记录。比如设置warn级别后，基本为warn 及 error、crit、alert 和 emerg

的日志都会被记录下来。

例如:

error_log logs/error.log error;

 

配置文件引入指令

include file；

file, 要引入的配置文件，它支持相对路径

在一些情况下，我们可能将其他的Nginx 配置或第三方模块的配置引入到当前的主配置文件中，此时可以使用此指令。

此指令可以放在配置文件的任意地方。

 

---

 

优化配置指令

 

1、针对CPU的nginx 配置优化指令

处理器已经进入了多核时代。多核的意思是一个处理器集成了两个或者多个计算引擎，也就是计算机可以并发的处理更

多的事情。在Nginx配置中，有两个关于进程的指令，worker_processes 和worker_cpu_affinity，它们可以针对多

核CPU进行配置优化。

 

A）worker_processes 指令

worker_processes 指令是用来指定Nginx工作进程数。官方默认设为1，但是为了让多核CPU能够更好的处理并行任

务，可以将该值设置大一些，最好这个值是机器CPU的倍数。当然，并不是越大越好，Nginx 进程太多会增加主进程

master调度负担，也可能影响系统的IO效率。

auto 参数可以自动根据操作系统CPU核心数量去开启等同的Nginx工作进程数，这样就不需要手动去设置Nginx 的工作

进程数量。

Example:

worker_processes 4;

worker_processes auto;

 

B）worker_cpu_affinity 指令

worker_cpu_affinity 指令用来为每个进程分配工作内核(CPU)。这个指令的设置方法有些麻烦。

我们这里遵循一个规则去设定，就可以很简单。

规则: cpu有多少个核，就有几位数，1代表使用，0代表不使用。

Example:

# 两核CPU，开启两个进程

worker_processes 2;

worker_cpu_affinity 01 10;

 

# 两核CPU，开启八个进程

worker_processes 8;

worker_cpu_affinity 01 10 01 10 01 10 01 10;

 

# 8核CPU，开启8个进程

worker_processes 8;

worker_cpu_affinity 10000000 01000000 00100000 00010000 00001000 00000100 00000010 00000001;

 

# 8核CPU，开启2个进程

worker_processes 2;

worker_cpu_affinity 10101010 01010101;

# 10101010表示一个进程绑定到了第2,4,6,8内核，01010101表示另一个进程绑定到了1,3,5,7内核

 

以上配置可以看出，当CPU的核心数量越多的时候，配置的参数也就越长。在 1.9.10 版本后，Nginx中提供了auto 参数，来解决工作进程自动绑定CPU的行为。

worker_processes auto;

worker_cpu_affinity auto;

 

2、针对网络相关的配置指令

A)keepalive_timeout 指令

该指令用于设置Nginx服务器与客户端保持连接的超时时间。

这个指令支持两个选项，中间用空格隔开。 第一个选项指定客户端连接保持活动的超时时间，在这个时间之后，服务器

会关闭此连接；第二个选项，指定了使用Keep-Alive 消息头保持存活的有效时间，如果不设置他，Nginx服务器不会向

客户端发送Keep-Alive 消息头以保持与客户端某些浏览器(如Mozilla,Konqueror等)的连接。设置这个选项后，客户

端就可以在超时时间后关闭连接，而不需要服务器关闭了。指令的设置示例:

keepalive_timeout 60 30;

B)send_timeout 指令

该指令用于设置Nginx 服务器响应客户端的超时时间，这个超时时间仅针对客户端和服务器端建立连接之后。如果在指

定的时间内，客户端没有收到任何内容，这个连接将会被断开。注意此超时时间不是服务器端响应客户端的总时间。指

令的设置示例:

send_timeout 10s;

C)client_header_buffer_size 指令

该指令用户设置Nginx 服务器允许的客户端请求头的缓冲区大小，默认是1KB。此指令的赋值可以根据系统分页大小来设

置。分页大小可以使用如下指令获得:

# getconf PAGESIZE

此指令若设置不当，经常会发生400状态码错误。此错误一大部分情况是客户端的请求头过大造成的。请求头过大，通常是

客户端cookie中写入了较大的值引起的。因此适当的增大此指令的赋值，运行Nginx服务器接受较大的请求头部，可以增

强服务器对客户端的支持能力。通常我们将此值设置成4k。指令的设置示例:

client_header_buffer_size 4k;

D)Gzip 压缩指令

在Nginx 配置文件中可以配置Gzip的使用，Gzip指令可以在http块、server块、location块中设置。

它可以对响应数据进行在线实时压缩。Gzip 主要由 ngx_http_gzip_module 模块提供，该模块包括指令如下。

E)gzip 指令

开启或者关闭Gzip功能， 默认指令设置为off, 即不启用Gzip功能。只有设置为on 时，后续介绍的指令才会有效。

gzip on | off;

F)gzip_buffers 指令

设置Gzip压缩文件使用缓存空间的大小， 语法如下:

gzip_buffers number size;

number, 指定缓存空间的数量

size, 指定缓存空间的大小

根据该配置选项， Nginx 服务器在对响应输出数据进行Gzip压缩时需要向系统申请 number * size 大小的空间用于

存储压缩数据。

G)gzip_comp_level 指令

设置Gzip的压缩程度，包括级别1 到 级别9。 级别1标示压缩程度最低，压缩效率最高；级别9标示压缩程度最高，压缩

效率最低，最费时间。语法如下:

gzip_comp_leve level; 默认级别为 1

H)gzip_disable 指令

针对不同类型客户端发起的请求，可以选择性的关闭和开启Gzip功能。该指令从0.6.23启用，用于设置一些客户端种类。

Nginx服务器端在响应这种类型的客户端时，不使用Gzip功能响应输出数据。语法如下:

gzip_disable regex ...;

其中，regex 根据客户端的浏览器标志(UA，User-Agent) 进行设置，支持使用正则表达式。

Example:

gzip_disable MSIE [4-6]\.

该设置使用了正则表达式，其可以匹配UA字符串中抱哈MISE4、MISE5和MISE6的所有浏览器。响应这些浏览器发送的请求

时，Nginx服务器不在进行Gzip压缩。

I)gzip_http_version 指令

早期的一些浏览器或者HTTP客户端，可能不支持Gzip自解压。因此用户可能会看到乱码，所以针对不同的HTTP协议版本，

需要选择性的开启或者关闭Gzip功能。该指令用于设置开启Gzip功能的最低HTTP协议版本。 语法如下:

gzip_http_version 1.0|1.1

默认设置为1.1版本， 即只有客户端使用了1.1及以上版本的HTTP协议时，才使用Gzip功能对响应输出数据进行压缩。

从目前来看，绝大多数的浏览器都支持Gzip的自解压，一般采用默认即可。

J)gzip_min_length 指令

Gzip 压缩功能针对大数据压缩效果明显，若压缩很小的数据很可能出现越压缩数据越大的情况。因此应该根据响应结果

的大小，选择性的开启或者关闭Gzip功能。响应结果的大小通过HTTP响应头中的Content-Length指令获取。但当使用

了Chunk 编码动态时，Content-length 或不存在或被忽略，此时该指令将不起作用。语法如下:

gzip_min_length length;

当设置length 为0 时， 标示不管响应结果多大，都统统开启压缩功能。

K)gzip_types 指令

根据响应内容的MIME类型选择性的开启Gzip功能。该指令用来设置MIME类型，被设置的类型将被压缩。语法如下:

gzip_types mime-type ...;

mime-type 取值默认为text/html, 在gzip指令设置为on时，Nginx服务器会对所有的text/html 类型的页面数据进

行Gzip压缩。 该变量还可以取 "*"， 表示对所有的MIME类型的页面数据进行Gzip压缩。

L)gzip_var 指令

设置在使用Gzip功能时，是否发送带有"Vary: Accept-Encoding"头域的响应头部。该头域的主要功能是告诉接受放发

送的数据进行了压缩处理。 开启后的效果是在响应头部添加了Accept-Encoding: gzip，这对于本身不支持Gzip压缩的

浏览器是有用的。 语法如下:

gzip_vary on | off; 默认值为off

 

一个Gzip的综合实例

# 开启gzip

gzip on;

# 启用gzip压缩的最小文件，小于设置值的文件将不会压缩

gzip_min_length 1k;

# gzip 压缩级1-9，数字越大压缩的越好，但也越占用CPU时间

gzip_comp_level 2;

# 进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。

gzip_types text/plain application/javascript application/x-javascript text/css application/xml

text/javascript application/x-httpd-php image/jpeg image/gif image/png;

# 是否在http 响应头中添加Vary: Accept-Encoding，建议开启

gzip_vary on;

# 禁用IE 6 gzip

gzip_disable "MSIE [1-6]\.";