1. Nginx 服务的基本配置
1.1 用于调试进程和定位问题的配置项
是否以守护进程的方式运行 nginx
- # 默认 on
- daemon on|off;
是否以 master/worker 方式工作
- # 默认 on, 指定了是否以 master-worker 进程的方式运行, 如果设置为 off, 那么所有的请求将只会由 master 进程处理
- master_process on|off;
error 日志的设置
- # 指定了 error 日志的目录和日志级别, 第二个参数用于指定目录, 第三个参数用于指定日志级别, 总共有: debug,info,notice,warn,error,crit,alert,emerg, 这些日志级别中, 从左往右优先级依次增大, 默认为 info
- error_log logs/error.log error;
是否处理几个特殊的调试点
- # 指定了调试点
- debug_points stop|abort
仅对指定的客户端输出 debug 级别的日志
debug_connection IP|CIDR
该参数主要用于 events 模块中, 针对指定的 ip 或者网段记录 debug 日志:
- events {
- debug_connection 10.224.66.14;
- debug_connection 10.224.57.0/24;
- }
需要注意的是, 在使用该参数时, 必须要确保在进行 configure 时已经加入了 --with-debug 参数, 否则不会生效;
限制 coredump 核心转储文件的大小
worker_rlimit_core size;
在 Linux 操作系统中, 如果一个进程由于错误或者收到信号而终止时, 会将进程执行时的内存内容写入一个文件(core 文件), 以作为调试之用, 这就是所谓的核心转储. 在 nginx 进程宕机时, 其就会产生核心转储文件, 而且该文件一般都有几个 G, 因而如果不限制该文件的大小, 那么很有可能会把服务器磁盘占满. 该参数的作用就是限制核心转储文件的大小的.
指定 coredump 文件生成目录
working_directory path;
该参数指定了在生成核心转储文件时, 将该文件存放的目录.
1.2 正常运行的配置项
定义环境变量
env TESTPATH=/tmp/
这个配置项可以让用户直接设置操作系统上的环境变量.
嵌入其他配置文件
include /path/file
用于将其他的配置文件引入进来, 该路径可以是绝对路径, 也可以是相对路径, 如果是相对路径, 则是基于 nginx 的配置目录而指定的.
pid 文件的路径
pid path/file
用于指定存储 nginx 的 master 进程运行所使用的进程 id 的文件的路径.
Nginx 的 worker 进程运行的用户及用户组
user username [groupName]
用于指定 worker 进程运行时所基于的用户和用户组, 默认都为 nobody, 这里如果不指定 groupName, 那么组名就与用户名一致.
指定 nginx 的 worker 进程可以打开的最大句柄描述符个数
worker_rlimit_nofile limit;
设置一个 worker 进程能够打开的最大句柄描述符个数.
限制信号队列
worker_rlimit_sigpending limit;
设置了每个用户能够发往 nginx 的信号队列的大小, 如果信号队列已满, 那么新发送的信号将会被丢弃.
1.3 优化性能的配置项
nginx 的 worker 进程的个数
worker_processes 1;
用于指定 nginx 运行时 worker 进程的个数, 在 nginx 运行时, 每个 worker 进程都是单线程运行的, 这里需要判断 worker 进程是否进行了阻塞性操作, 如果有这样的操作, 那么稍微多配置一些 worker 进程比较好, 如果没有, 那么将 worker 进程数量设置得与 CPU 数量一样能够得到更好的性能.
绑定 nginx 的 worker 进程到指定的 CPU 内核
worker_cpu_affinity cpumask [cpumask...]
将 worker 进程与指定的 CPU 进行绑定, 这样能够防止多个 worker 进程抢占同一个 CPU, 从而避免出现同步问题. 如下是一个 4 核 CPU 的配置方式:
- worker_processes 4;
- worker_cpu_affinity 1000 0100 0010 0001;
需要注意的是, worker_cpu_affinity 仅对于 Linux 系统有效.
SSL 硬件加速
ssl_engine device;
如果服务器上有 SSL 硬件加速设备, 那么就可以进行配置以加快 SSL 协议的处理速度. 用户可以使用 OpenSSL 提供的命令来查看是否有 SSL 硬件加速设备:
openssl engine -t
系统调用 gettimeofday 的执行频率
timer_resolution -t
默认情况下, 每次内核的事件调用返回时, 都会执行一次 gettimeofday, 在早期的 Linux 版本中, 获取系统时间都会有一次从内核态到用户态的数据复制, 其代价比较高, 但是在最新的 x86-64 体系架构中, gettimeofday 仅仅只是一次 vsyscall, 其仅仅只是对共享内存页中的数据的访问, 代价不大.
nginx 的 worker 进程优先级
worker_priority nice;
用于设置 nginx 的 worker 进程的优先级, 其中, nice 的默认值为 0. 在 Linux 操作系统中, 当有多个进程在竞争 CPU 执行资源时, 其就会根据每个进程设置的优先级来优先分配执行权限, 并且所分配的时间片也要高一些. 优先级的值在 - 20~+19 之间, 数值越低优先级越高, 一般建议将 nginx 的优先级设置得更低一些, 这样才能保证其执行的权限, 但是建议不要设置得比内核的进程优先级 (其值为 - 5) 还要低.
1.4 事件类配置项
是否打开 accept 锁
accept_mutex [on|off]
accept_mutex 参数用于控制是否启用负载均衡锁, 其默认值为 on, 该锁会保证各个 worker 轮流的, 序列化的与新客户端建立连接, 并且当某个 worker 的连接数达到了 worker_connections 配置的最大连接数的 7/8 时, 该锁会降低该 worker 将要新建立的连接数, 从而保证各个 worker 的负载均衡.
lock 文件的路径
lock_file path/file;
该参数指定了 lock 文件的路径. nginx 会使用操作系统提供的锁功能, 但如果操作系统不支持原子锁, 此时才会使用文件锁来实现 lock. 如果 accept_mutex 参数设置为 off, 那么该参数将不会生效.
使用 accept 锁后到真正建立连接之间的延迟时间
accept_mutex_delay Nms;
如果一个 worker 进程尝试获取锁失败了, 那么其就会等待该参数指定的时间段之后再次尝试获取锁, 该值默认为 500ms.
批量建立新连接
multi_accept [on|off];
当事件模型通知此次有新的连接建立请求时, 尽可能的对本次调度中客户端发起的的所有 TCP 请求都建立连接, 该值默认为 off.
选择事件模型
use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
nginx 所选用的事件模型, 其会自动使用最适合的模型. 在 Linux 操作系统下支持 poll,select 和 epoll 三种, 其中 epoll 的性能是最高的.
每个 worker 的最大连接数
worker_connections number;
指定了每个 worker 进程能够建立的最大连接数.
2. http 核心模块配置
2.1 监听端口
listen address:port[default(deprecated)|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv6only=[on|off]|ssl]]
这里的 IP 地址和端口号的配置非常灵活, 如果不配置端口号, 则默认为 80 端口, 而 ip 地址则可以使用通配符进行匹配, 如:
- listen 127.0.0.1:8080;
- listen *:8080;
listen 的各个参数含义如下:
default 和 default_server: 将当前 server 块作为整个 web 服务器的默认 server 块, 如果没有 server 设置了该参数, 则将 nginx.conf 中的第一个 server 块作为默认 server 块. 设置该参数的原因在于, 如果当前请求没有匹配到任意一个 server, 那么就使用第一个 server 处理请求;
backlog=num: 指定了 TCP 中的 backlog 队列的大小, 默认值为 - 1. 在 TCP 的三次握手过程中, 进程此时还没有开始处理监听句柄, 而这些请求都会放在 backlog 队列中, 当 backlog 队列满时, 客户端新的握手请求就会被拒绝;
rcvbuf=size: 设置监听句柄的 SO_RCVBUF 参数;
sndbuf=size: 设置监听句柄的 SO_SNDBUF 参数;
accept_filter: 设置 accept 过滤器, 只对 FreeBSD 操作系统有用;
deferred: 如果设置了该参数, 如果用户发起了 TCP 连接请求, 那么在三次握手成功之后内核也不会调度相应的进程处理请求, 而是在用户真正的发送了数据包之后才会将请求发送给具体的进程进行处理;
bind: 绑定当前端口 / 地址对, 如 127.0.0.1:8000, 只有同时对一个端口监听多个地址时才会生效;
ssl: 在当前监听的端口上建立的连接必须基于 SSL 协议;
2.2 主机名称
语法: server_name name [...];
默认: server_name "";
配置块: server
server_name 后可以跟多个主机名称, 在处理 HTTP 请求时, 其会将请求中的 Host 头部的主机名与 server 块中的主机名进行匹配, 如果遇到多个 server 块中的主机名匹配, 那么将会按照如下规则与其进行匹配:
首先匹配主机名完全匹配的 server 块;
然后匹配前缀使用通配符的 server 块;
接着匹配后缀使用通配符的 server 块;
最后匹配使用正则表达式的 server 块;,
如果没有找到能够匹配的主机名, 那么就会按照如下规则寻找 server 块:
优先选择在 listen 项中加入了 [default|default_server] 的 server 块;
找到匹配的 listen 端口的第一个 server 块;
2.3 server_names_hash_bucket_size
语法: server_names_hash_bucket_size size;
默认: server_names_hash_bucket_size 32|64|128;
配置块: http,server,location
server_names_hash_bucket_size 的作用主要是进行 server name 的 hash 匹配的, 在进行 hash 匹配时, 该参数指定了 hash 表的每个 bucket 占用的内存大小.
2.4 server_names_hash_max_size
语法: server_names_hash_max_size size;
默认: server_names_hash_max_size 512;
配置块: http,server,location
server_names_hash_max_size 指定了进行 server name 查找时使用的 hash 表的大小, 该值越大, 那么占用的内存越多, 但是查询的效率也越高.
2.5 重定向主机名称的处理
语法: server_name_in_redirect on|off;
默认: server_name_in_redirect on;
配置块: http,server 或者 location
该配置需要配合 server_name 使用, 在使用 on 打开时, 表示在重定向请求时, 会使用 server_name 里配置的第一个主机名代替原来请求中的 Host 头部, 而使用 off 关闭时, 表示在重定向请求时使用请求本身的 Host 头部.
2.6 location
语法: location [=|~|~*|^~|@] /uri/{...}
配置块: server
location 的主要作用是与请求中的 URI 进行匹配, 如果匹配了, 就使用 location 块中的配置来处理用户请求. 如下是 location 的匹配规则:
= 表示把 URI 作为字符串, 以便于参数中的 uri 做完全匹配. 例如:
- location = / {
- # 只有当用户请求是 / 时, 才会使用该 location 下的配置
- }
~ 表示匹配 URI 时是字母大小写敏感的;
~* 表示匹配 URI 时是字母大小写不敏感的;
^~ 表示匹配 URI 时只需要其前半部分与 uri 参数匹配即可. 例如:
- location ^~ /images/ {
- # 以 / images / 开始的请求都会匹配上
- }
@表示仅用于 nginx 服务内部请求之间的重定向, 带有 @的 location 不直接处理用户请求;
可以在 uir 参数里使用正则表达式. 如:
- location ~* \.(gif|jpg|jpeg)$ {
- # 匹配以. gif,.jpg,.jpeg 结尾的请求
- }
关于 location 的匹配需要说明的一点是, location 的匹配是有顺序的, 当一个请求匹配了多个 location 时, 实际上这个请求会被第一个 location 处理.
3. 文件路径的定义
3.1 以 root 方式设置资源路径
语法: root path;
默认: root html;
配置块: http,server,locationo,if
示例如下:
- location /download/ {
- root /opt/Web/HTML/;
- }
这种配置方式会将 / download / 开始的请求映射到 / opt/Web/HTML / 目录下, 比如某个请求为 / download/test/index.HTML, 那么 nginx 就会到服务器上查找 / opt/Web/HTML/download/test/index.HTML 文件.
3.2 以 alias 方式设置资源文件
语法: alias path;
配置块: location;
与 root 一样, alias 也是配置资源文件路径的, 但是 alias 是 location 后的路径以别名的方式替换目标路径的指定部分, 比如如下配置:
- location /conf www.yinchengyule.cn{
- alias /usr/local/nginx/conf;
- }
此时如果一个请求为 / conf/index.HTML, 那么其前缀 / conf 将会与当前 location 匹配, 并且会将 alias 参数替换请求 uri 中匹配的部分, 也就是转换后的 uri 为 / usr/local/nginx/conf/index.HTML.
3.3 访问首页
语法: index file...;
默认: index index.HTML;
配置块: http,server,location
该配置块的主要作用是将用户访问的某个地址映射到首页, 在进行首页查找时, 会按照顺序查询 index 参数后的文件, 如果存在, 则将其返回, 如果不存在, 则继续查找下一个. 比如如下示例:
- location / {
- root path;
- index /index.HTML /HTML/index.PHP /index.PHP
- }
当接收到用户的 / 请求后, 其首先会查询 / path/index.HTML 文件是否存在, 如果不存在, 则查询下一个 / path/HTML/index.PHP 是否存在, 如果存在, 则直接返回, 依此类推.
3.4 根据 http 返回码重定向页面
语法: error_page code[code...][=|=answer-code]uri|@named_location
配置块: http,server,location,if
该配置的主要作用是, 如果当前请求返回了指定的状态码, 那么就将其重定向到后面的错误页面. 如:
error_page 404 /404.HTML
error_page 502 503 504 /50x.HTML
- error_page 403 http://example.com/forbidden.html
- error_page 404 = @fetch;
需要注意的是, 即使重定向了 URI, 返回的 HTTP 状态码还是原来的状态码, 如果需要修改状态码, 可以使用 = 来修改原来的状态码, 如:
- error_page 404 =200 /empty.gif;
- error_page 404 =403 /forbidden.gif;
也可以不指定修改后的状态码, 而是由重定向后的请求决定其返回的状态码:
error_page 404 = /empty.gif;
在重定向后, 也可以不修改 URI, 而是将这个请求重定向到另一个 location 中进行处理, 比如:
- location /www.yinchengylzc.cn {
- error_page 404 @fallback;
- }
- location @fallback {
- proxy_pass http://backend;
- }
3.5 是否支持递归的使用 error_page
语法: recursive_error_pages [on|off];
默认: recursive_error_pages off;
配置块: http,server,location;
该配置主要用于控制是否支持递归的定义 error_page.
3.6 try_files
语法: try_files path1[path2]uri;
配置块: server,location
该参数的主要作用是在用户请求到达之后, 会依次尝试其后指定的各个 path 路径, 如果匹配上了, 那么就将该路径的值直接返回. 如果都没有匹配上, 那么就会使用最后的 uri 作为默认处理路径. 示例如:
- try_files /system/maintenance.HTML $uri $uri/index.HTML $uri.HTML @other
- location @other {
- www.chuancenpt.com
- proxy_pass http://backend;
- }
4. 内存及磁盘资源的分配
4.1 http 包体只存储到磁盘文件中
语法: client_body_in_file_only on|clean|off;
默认: client_body_in_file_only off;
配置块: http,server,location
当值配置为非 off 时, 用户请求的 http 包体一律存储到磁盘文件中, 即使只有 0 字节也会存储为文件. 当请求结束时, 如果配置为 on, 则这个文件不会被删除, 如果配置为 clean, 则会删除该文件.
4.2 http 包体尽量写入到一个内存 buffer 中
语法: client_body_in_single_buffer www.chuanchenpt.cn n|off;
默认: client_body_in_single_buffer off;
配置块: http,server,location
用户请求的 http 包体一律存储到内存 buffer 中, 如果存储的包体大小超过了 client_body_buffer_size 指定的大小, 那么该请求还是会存储到磁盘文件中.
4.3 存储 http 头部的内存 buffer 大小
语法: client_header_buffer_size size;
默认: client_header_buffer_size 1k;
配置块: http,server
该参数指定了用户请求的 http 头部的 size 大小, 如果请求头部大小超过了该数值, 那么就会将请求就会交由 large_client_header_buffers 参数定义的 buffer 处理.
4.4 存储超大 http 头部的内存 buffer 大小
语法: large_client_header_buffers number size;
默认: large_client_www.hxyl1618.com header_buffers 48k;
配置块: http,server
该参数主要是在用户的请求头部信息超过了 client_header_buffer_size 所能存储的大小时使用, 该参数定义了每个 header 所能传输的数据的大小, 以及最多能够传输多少个 header. 如果单个 header 大小超限, 则会返回 414(Request URI too large)状态码, 如果是 header 个数超限, 则会返回 400(Bad Request)状态码.
4.5 存储 http 包体的内存 buffer 的大小
语法: client_body_buffer_size size;
默认: client_body_buffer_size 8k/16k;
配置块: http,server,location
该参数指定了 nginx 接收用户 http 请求的包体 buffer 的大小, 如果超过了该大小, 那个请求包体将会存储到磁盘文件中.
需要注意的是, 如果用户请求的 header 中包含 Content-Length, 并且其标识的长度小于上述参数指定的长度, 那么就会自动降低此次请求所使用的 buffer 大小.
4.6 http 包体的临时存放目录
语法: client_body_temp_path dir-path[level1[level2[level3]]]
默认: client_body_temp_path client_body_temp;
配置块: http,server,location
该参数的主要作用是指定了存储 http 包体的磁盘目录, 后面的 level 表示可以有几级子目录, 这是因为如果请求比较多, 那么生成的文件就会比较多, 频繁的访问同一个目录可能会降低性能, 因而可以设置多级子目录用于文件的存放;
需要注意的是, 上述 level 参数表示的是所生成的目录名占有目标文件名字符的个数, 比如生成的目标文件名为 00000123456, 而上述参数按如下配置:
client_body_temp_path /opt/nginx/client_temp 1 2;
那么 nginx 就会截取目标文件名的最后 1 个字符作为一级目录, 倒数第二个和第三个总共两个字符作为二级目录, 最终文件将会存储在如下目录:
/opt/nginx/client_temp/6/45/00000123456
nginx 在生成目标文件时, 其文件名是以顺序递增的整数进行命名的.
4.7 connection_pool_size
语法: connection_pool_size size;
默认: connection_pool_size 256;
配置块: http,server
该参数指定了 nginx 为每个建立成功的 TCP 连接预先分配的内存池大小, size 指定的是预先分配的内存池大小.
该参数需要谨慎配置, 因为更大的配置将会消耗服务器更多的内存, 而更小的配置将会导致服务器为了扩容而进行更多次的内存分配.
4.8 request_pool_size
语法: request_pool_size size;
默认: request_pool_size 4k;
配置块: http,server
nginx 在接收到每个 http 请求时, 都会为其申请一个内存池, 该参数指定了该内存池的大小, 需要注意的是, 该内存池本质上就是从上面介绍的 connection_pool_size 内存池中进行申请;
在每次 http 请求结束时, 其就会销毁该请求申请的内存池, 而将其返还给 connection_pool_size 内存池, 而只有在此次 TCP 连接关闭时才会销毁整个连接的内存池.
5. 网络连接的设置
5.1 读取 http 头部的超时时间
语法: client_header_timeout time(默认单位: 秒);
默认: client_header_timeout 60;
配置块: http,server,location
在客户端与服务器建立连接之后, nginx 会读取客户端发来的 http 头部, 如果超过该参数指定的时间还未读取到客户端发来的字节, 就会认为其超时了, 此时就会向客户端返回 408(Request timed out)状态码.
5.2 读取 http 包体的超时时间
语法: client_body_timeout time(默认单位: 秒);
默认: client_body_timeout 60;
配置块: http,server,location
该参数主要作用是指定 nginx 读取请求包体的超时时间.
5.3 发送响应的超时时间
语法: send_timeout time;
默认: send_timeout 60;
配置块: http,server,location
这个参数主要指定了 nginx 向客户端发送响应的超时时间, 如果客户端一直没有尝试接收数据, 那么 nginx 就会关闭这个连接.
5.4 reset_timeout_connection
语法: reset_timeout_connection on|off;
默认: reset_timeout_connection off;
配置块: http,server,location
如果开启了该参数, 在连接超时后, nginx 会向客户端发送 RST 包来直接重置连接, 并且会释放服务器上关于该连接的所有缓存数据(如 TCP 滑动窗口等). 相比于正常关闭的方式, 它使得服务器能够避免产生许多处于 FIN_WAIT_1,FIN_WAIT_2,TIME_WAIT 状态的 TCP 连接.
需要注意的是, 使用 RST 重置包关闭连接会带来一些问题, 默认情况下不会开启.
5.5 lingering_close
语法: lingering_close off|on|always;
默认: lingering_close on;
配置块: http,server,location
该配置块控制 nginx 关闭用户连接的方式. always 表示关闭用户连接前必须无条件的处理连接上所有用户发送的数据. off 表示关闭连接时完全不管连接上是否有用户准备就绪的数据. on 是中间值, 一般情况下在关闭连接前都会处理连接上的用户发送的数据, 除非某些时候业务上认定这些数据是不需要的, 此时就会抛弃这些数据.
5.6 lingering_time
语法: lingering_time time;
默认: lingering_time 30s;
配置块: http,server,location
在 lingering_close 启用后, 这个配置项主要是针对大文件的传输用的, 比如当某个请求传输的数据超过了 max_client_body_size 时, nginx 就会向该客户端发送 413(Request entity too large)状态码, 但是某些客户端可能不会理会该状态码而还是继续向服务器发送数据, 此时 nginx 就会在该参数的超时时间之后直接关闭该连接.
5.7 lingering_timeout
语法: lingering_timeout time;
默认: lingering_timeout 5s;
配置块: http,server,location
在 lingering_close 启用后, nginx 在关闭连接前, 会检测用户连接上是否还有未处理的数据, 如果在该参数指定的时间之后还没有相应的数据到达, 那么就会关闭该链接.
5.8 对某些浏览器禁用 keepalive 功能
语法: keepalive_disable [msie6|Safari|none]...
默认: keepalive_disablemsie6 Safari
配置块: http,server,location
该参数主要是指定对哪些浏览器禁用 keepalive 功能, keepalive 会在客户端与服务器之间建立一个长连接, 这对于发送多个 http 请求是非常有用的, 但是对于 IE6 和以前版本, 还有 Safari 浏览器在处理 POST 请求时会有功能性问题, 因而对于这些浏览器默认是禁用的.
5.9 keepalive 超时时间
语法: keepalive_timeout time(默认单位: 秒);
默认: keepalive_timeout 75;
配置块: http,server,location
该参数主要是在一个 keepalive 连接在指定时长内没有接收到新的请求时, 将会关闭该连接.
5.10 keepalive 长连接上能够承载的最大请求数
语法: keepalive_requests n;
默认: keepalive_requests 100;
配置块: http,server,location
该参数指定了一个 keepalive 长连接上能够承载的最大连接数, 默认为 100.
5.11 tcp_nodelay
语法: tcp_nodelay on|off;
默认: tcp_nodelay on;
配置块: http,server,location
确定对 keepalive 连接是否使用 TCP_NODELAY 选项
5.12 tcp_nopush
语法: tcp_nopush on|off;
默认: tcp_nopush off;
配置块: http,server,location
在打开 sendfile 选项时, 确定是否开启 FreeBSD 系统上的 TCP_NOPUSH 或者 Linux 系统上的 TCP_CORK 功能. 打开 tcp_nopush 后, 将会在发送响应时把整个响应包头放到一个 TCP 包中发送.
6. MIME 类型的设置
6.1 MIME type 与文件扩展的映射
语法: type {...};
配置块: http,server,location
该配置项定义了 MIME type 到文件扩展名的映射. 多个扩展名可以映射到同一个 MIME type. 例如:
- types {
- text/HTML HTML;
- text/HTML conf;
- image/gif gif;
- image/jpeg jpg;
- }
6.2 默认 MIME type
语法: default_type MIME-type;
默认: default_type text/plain;
配置块: http,server,location
当找不到相应的 MIME type 与文件扩展名之间的映射时, 使用默认的 MIME type 作为 http header 的 Content-Type.
6.3 types_hash_bucket_size
语法: types_hash_max_size size;
默认: types_hash_max_size 1024;
配置块: http,server,location
nginx 使用了一个散列表来保存 MIME type 与文件扩展名之间的映射, 该参数就是指定该散列表桶的大小的.
6.4 types_hash_max_size
语法: types_hash_max_size size;
默认: types_hash_max_size 1024;
配置块: http,server,location
该参数指定了存储 MIME type 与文件扩展名的散列的最大大小, 该值越大, 散列的 key 就越稀疏, 检索速度越快, 但是会占用更多的内存; 该值越小, 占用的内存越小, 但是冲突率就会上升, 检索越慢.
7. 对客户端请求的限制
7.1 按 http 方法名限制用户请求
语法: limit_except method...{...}
配置块: location
该配置项的主要作用是限制某些方法的请求的访问, 后面的参数可取 GET,HEAD,POST,DELETE,MKCOL,COPY,MOVE,OPTIONS,PROPFIND,PROPPATCH,LOCK,UNLOCK 或者 PATCH. 示例如:
- limit_except GET {
- allow 192.168.1.0/32;
- deny all;
- }
上述配置将会限制所有的 GET 请求的访问, 而允许其他方法的请求.
7.2 http 请求包体的最大值
语法: client_max_body_size size;
默认: client_max_body_size 1m;
配置块: http,server,location
该参数指定了 http 请求的最大包体的大小, nginx 会根据请求 header 中的 Content-Length 所表示的长度来判断其与当前参数是否符合, 如果不符合, 则直接返回给客户端 413(Request too large)状态码.
7.3 对请求的限速
语法: limit_rate speed;
默认: limit_rate 0;
配置块: http,server,location,if
该配置主要是对客户端的请求进行每秒传输的字节大小进行限速, 默认为 0, 表示不限速;
针对不同的客户端, 可以使用 $limit_rate 参数执行不同的限速策略. 如:
- server {
- if ($slow) {
- set $limit_rate 4k;
- }
- }
- 7.4 limit_rate_after
语法: limit_rate_after time;
默认: limit_rate_after 1m;
配置块: http,server,location,if
该参数表示 nginx 向客户端发送的响应大小超过 limit_rate_after 指定的值之后才开始限速.
8. 文件操作的优化
8.1 sendfile 系统调用
语法: sendfile on|off;
默认: sendfile off;
配置块: http,server,location
该参数用于打开 Linux 上的 sendfile 系统调用, 在发送数据到网卡上时, 它减少了两次在用户态与内核态之间的数据拷贝过程, 而直接在磁盘读取数据之后发送到网卡上, 从而提升数据发送效率.
8.2 AIO 系统调用
语法: aio on|off;
默认: aio off;
配置块: http,server,location
该参数指定了是否在 FreeBSD 或 Linux 系统上启动内核级别的异步文件 I/O 功能, 需要注意的是, 其与 sendfile 功能是互斥的.
8.3 directio
语法: directio size|off;
默认: directio off;
配置块: http,server,location
该配置项在 FreeBSD 和 Linux 系统上使用 O_DIRECT 选项去读取文件, 缓冲区大小为 size, 通常对大文件的读取速度有优化作用. 注意, 它与 sendfile 指令是互斥的.
8.4 directio_alignment
语法: directio_alignment size;
默认: directio_alignment 512;
配置块: http,server,location
它与 directio 配合使用, 指定以 directio 方式读取文件时的对其方式. 一般情况下, 512B 已经足够了, 但对于一些高性能文件系统, 如 Linux 下的 XFS 文件系统, 可能需要设置 4KB 作为对齐方式.
8.5 打开文件缓存
语法: open_file_cache max=N[inactive=time]|off;
默认: open_file_cache off;
配置块: http,server,location
文件缓存会在内存中存储以下三种信息:
文件句柄, 文件大小和上次修改时间;
已经打开过的目录结构;
没有找到的或者没有权限操作的文件信息;
上面的配置项的三个参数的含义如下:
max: 表示内存中存储元素的最大个数. 当达到最大限制数量后, 将采用 LRU 算法从缓存中淘汰最近最少使用的元素;
inactive: 表示在 inactive 指定的时间段内没有被访问过的元素将会被淘汰. 默认时间为 60 秒;
off: 关闭缓存功能.
示例如下:
open_file_cache max=1000 inactive=20s;
8.6 是否缓存打开文件错误的信息
语法: open_file_cache_errors on|off;
默认: open_file_cache_errors off;
配置块: http,server,location
该配置项表示是否对打开文件时找不到文件或者权限错误等信息进行缓存.
8.7 不被淘汰的最小访问次数
语法: open_file_cache_min_uses number;
默认: open_file_cache_min_uses 1;
配置块: http,server,location
该参数与 open_file_cache 配合使用, 如果在指定时间内访问该文件的次数小于该参数指定的次数, 那么该文件还是会被淘汰.
8.8 检验缓存中元素有效性的频率
语法: open_file_cache_valid time;
默认: open_file_cahce_valid 60s;
配置块: http,server,location
该参数指定了每间隔多长时间检查一下缓存中数据的有效性, 默认为 60 秒.
9. 对客户端请求的特殊处理
9.1 忽略不合法的 http 头部
语法: ignore_invalid_headers on|off;
默认: ignore_invalid_headers on;
配置块: http,server
如果将其设置为 off, 那么当客户端请求中有不合法的 header 时, 就会直接响应 400(Bad Request); 如果将其设置为 on, 那么就会忽略此 header.
9.2 http 头部是否允许下划线
语法: underscores_in_headers on|off;
默认: underscores_in_headers off;
配置块: http,server
该参数指定了 http 头部中是否能够带有下划线, 默认是不允许.
9.3 对 If-Modified-Since 头部的处理策略
语法: if_modified_since [off|exact|before];
默认: if_modified_since exact;
配置块: http,server,location
If-Modified-Since 头部主要是浏览器处于性能考虑而作的一个缓存策略, 浏览器在请求过一份文件之后, 会将该文件在本地缓存, 并记录缓存时间, 在下次请求时会在 If-Modified-Since 头部中带上上次缓存的时间, 服务器在接收到该请求时, 会将服务器文件的修改时间与请求中的时间进行比较, 如果文件在这之后有过修改, 那么服务器就会正常的返回文件内容以及 200 状态码, 如果文件没有修改过, 那么说明浏览器中缓存的文件是最新的, 此时就会返回 304(Not Modified)状态码.
该配置参数有三个选项, 其含义分别如下:
off: 表示忽略用户请求中的 If-Modified-Since 头部, 在每次请求时都将文件内容返回, 此时响应状态码为 200;
exact: 将 If-Modified-Since 头部包含的时间与将要返回的文件的上次修改时间做精确比较, 如果没有匹配上, 则返回 200 和文件的实际内容, 如果匹配上了, 则表示文件内容已经是最新的, 此时就会返回 304(Not Modified)状态码, 浏览器收到后会直接读取本地缓存;
before: 这个是比 exact 更宽松的策略, 只要文件的上次修改时间在用户请求的 If-Modified-Since 头部指定的时间之前, 那么就会向客户端返回 304(Not Modified)状态码.
9.4 文件未找到时是否返回 error 日志
语法: log_not_found on|off;
默认: log_not_found on;
配置块: http,server,location
该配置的主要作用在于, 当用户请求某个文件时, 如果该文件不存在, 是否将这条信息记录在 error 日志中, 主要用于定位问题.
9.5 merge_slashes
语法: merge_slashes on|off;
默认: merge_slashes on;
配置块: http,server,location
该配置项表示是否合并相邻的 /, 例如 //test///a.txt, 在配置为 on 时, 会将其匹配为 location/test/a.txt; 如果配置为 off, 则不会匹配, URI 将仍然是 //test///a.txt.
9.6 DNS 解析地址
语法: resolver address...;
配置块: http,server,location
设置 DNS 名字解析服务器的地址, 如:
resolver 127.0.0.1 192.0.2.1;
9.7 DNS 解析的超时时间
语法: resolver_timeout time;
默认: resolver_timeout 30s;
配置块: http,server,location
次配置项表示 DNS 解析的超时时间
9.8 返回错误页面时是否在 server 中注明 nginx 版本
语法: server_tokens on|off;
默认: server_tokens on;
配置块: http,server,location
表示在返回错误页面时是否在 Server 头部中返回具体的 nginx 版本, 这主要是为了定位问题方便.
来源: http://www.bubuko.com/infodetail-3253079.html