NGINX配置文件超详细讲解

  • 2019-09-02
  • 0
  • 0

配置文件结构

NGINX的配置文件nginx.conf位于其安装目录conf目录下。
nginx.conf由多个块组成,最外面的块是main,main包含Events和HTTP,HTTP包含upstream和多个Server,Server又包含多个location:
main(全局设置)、server(主机设置)、upstream(负载均衡服务器设置)和 location(URL匹配特定位置的设置)。

  • main块设置的指令将影响其他所有设置;
  • server块的指令主要用于指定主机和端口;
  • upstream指令主要用于负载均衡,设置一系列的后端服务器;
  • location块用于匹配网页位置。

这四者之间的关系式:server继承main,location继承server,upstream既不会继承其他设置也不会被继承。
在这四个部分当中,每个部分都包含若干指令,这些指令主要包含Nginx的主模块指令、事件模块指令、HTTP核心模块指令,同时每个部分还可以使用其他HTTP模块指令,例如Http SSL模块、HttpGzip Static模块和Http Addition模块等。

一般在nginx.conf中设置全局配置,在conf.d下面设置各类业务的子配置,因为在nginx.conf中有个include选项,包含了子配置文件include /etc/nginx/conf.d/*.conf;
nginx配置文件结构

全局配置

# 指定运行用户,默认为nginx,可根据需求设置
user  www;

# nginx进程,指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存,
# 一般设置为和cpu核数一样,或者设置auto自动
worker_processes 4; 
worker_processes auto;

# 指定全局错误日志存放位置
error_log /var/log/nginx/error.log crit;
日志输出级别有debug、info、notice、warn、error、crit可供选择,其中,debug输出日志最为最详细,而crit输出日志最少。

# 指定进程pid存放位置
pid /run/nginx.pid

# worker_rlimit_nofile用于绑定worker进程和CPU, Linux内核2.4以上可用。最大文件打开数量(连接),
# 可设置为系统优化后的ulimit -HSn的结果
worker_rlimit_nofile 51200;

# cpu亲和力配置,让不同的进程使用不同的cpu
worker_cpu_affinity 0001 0010 0100 1000 0001 00100100 1000;

events事件

# 工作模式及连接数上限
events
{
use epoll; 

# 定义Nginx每个进程的最大连接数,默认是1024
worker_connections 1024; 
}
# epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能
# 其他工作模式有:select、poll、kqueue、epoll、rtsig和/dev/poll

HTTP

# Nginx对HTTP服务器相关属性
http
{
# 文件扩展名与类型映射表
include mime.types; 

#默认文件类型
default_type application/octet-stream; 

#limit模块,可防范一定量的DDOS攻击

#用来存储session会话的状态,如下是为session分配一个名为one的10M的内存存储区,限制了每秒只接受一个ip的一次请求 1r/s

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;
include mime.types;
default_type application/octet-stream;

# 设置日志模式
log_format access '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" $http_x_forwarded_for';

# nginx访问日志存放位置
access_log /data1/logs/abc.com.log access; 

#第三方模块lua防火墙
lua_need_request_body on;
lua_shared_dict limit 50m;
lua_package_path "/application/nginx/conf/waf/nginx.lua";
init_by_lua_file "/application/nginx/conf/waf/init.lua";
access_by_lua_file "/application/nginx/conf/waf/access.lua";

# 设定请求缓存
server_names_hash_bucket_size 128;

# 指定来自客户端请求头的headerbuffer大小
client_header_buffer_size 512k;

# 指定客户端请求中较大的消息头的缓存最大数量和大小, “4”为个数,“128K”为大小,最大缓存量为4个128K;
large_client_header_buffers 4 128k;

# 设定允许客户端请求的最大的单个文件字节数;
client_max_body_size 100m;

# 隐藏响应header和错误通知中的版本号
server_tokens off;

# 设置客户端连接保持活动的超时时间。在超过这个时间之后,服务器会关闭该连接;
keepalive_timeout 60;

# 客户端请求头读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误;
client_header_timeout 10;

# 设置客户端请求主体读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误,默认值是60;
client_body_timeout 10;

# 指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间,如果超过这个时间,客户端没有任何活动,Nginx将会关闭连接。
send_timeout 10;
# 开启高效传输模式,
sendfile on;
# 将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞;

# 激活tcp_nopush参数可以允许把httpresponse header和文件的开始放在一个文件里发布,积极的作用是减少网络报文段的数量
tcp_nopush on;

# 激活tcp_nodelay,内核会等待将更多的字节组成一个数据包,从而提高I/O性能
tcp_nodelay on;

tcp_nopush:

当使用sendfile函数时,tcp_nopush才起作用,它和指令tcp_nodelay是互斥的。tcp_cork是linux下tcp/ip传输的一个标准了,这个标准的大概的意思是,一般情况下,在tcp交互的过程中,当应用程序接收到数据包后马上传送出去,不等待,而tcp_cork选项是数据包不会马上传送出去,等到数据包最大时,一次性的传输出去,这样有助于解决网络堵塞,已经是默认了。

也就是说tcp_nopush = on 会设置调用tcp_cork方法,这个也是默认的,结果就是数据包不会马上传送出去,等到数据包最大时,一次性的传输出去,这样有助于解决网络堵塞。

以快递投递举例说明一下(以下是我的理解,也许是不正确的),当快递东西时,快递员收到一个包裹,马上投递,这样保证了即时性,但是会耗费大量的人力物力,在网络上表现就是会引起网络堵塞,而当快递收到一个包裹,把包裹放到集散地,等一定数量后统一投递,这样就是tcp_cork的选项干的事情,这样的话,会最大化的利用网络资源,虽然有一点点延迟。

对于nginx配置文件中的tcp_nopush,默认就是tcp_nopush,不需要特别指定,这个选项对于www,ftp等大文件很有帮助

tcp_nodelay

TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”,Nagle化在这里的含义是采用Nagle算法把较小的包组装为更大的帧。 John Nagle是Nagle算法的发明人,后者就是用他的名字来命名的,他在1984年首次用这种方法来尝试解决福特汽车公司的网络拥塞问题(欲了解详情请参看IETF RFC 896)。他解决的问题就是所谓的silly window syndrome,中文称“愚蠢窗口症候群”,具体含义是,因为普遍终端应用程序每产生一次击键操作就会发送一个包,而典型情况下一个包会拥有一个字节的数据载荷以及40个字节长的包头,于是产生4000%的过载,很轻易地就能令网络发生拥塞,。 Nagle化后来成了一种标准并且立即在因特网上得以实现。它现在已经成为缺省配置了,但在我们看来,有些场合下把这一选项关掉也是合乎需要的。

现在让我们假设某个应用程序发出了一个请求,希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。如果我们马上发送数据,那么交互性的以及客户/服务器型的应用程序将极大地受益。如果请求立即发出那么响应时间也会快一些。以上操作可以通过设置套接字的TCP_NODELAY = on 选项来完成,这样就禁用了Nagle 算法。

另外一种情况则需要我们等到数据量达到最大时才通过网络一次发送全部数据,这种数据传输方式有益于大量数据的通信性能,典型的应用就是文件服务器。应用 Nagle算法在这种情况下就会产生问题。但是,如果你正在发送大量数据,你可以设置TCP_CORK选项禁用Nagle化,其方式正好同 TCP_NODELAY相反(TCP_CORK和 TCP_NODELAY是互相排斥的)。


# FastCGI相关参数:为了改善网站性能:减少资源占用,提高访问速度

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

----------------------------------------------

# 开启gzip压缩功能
gzip on;

# 设置允许压缩的页面最小字节数,页面字节数从header头的Content-Length中获取。默认值是0,表示不管页面多大都进行压缩。建议设置成大于1K。如果小于1K可能会越压越大。
gzip_min_length 1k;

# 压缩缓冲区大小。表示申请4个单位为16K的内存作为压缩结果流缓存,默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果。
gzip_buffers 4 16k;

# 压缩版本(默认1.1,前端为squid2.5时使用1.0)用于设置识别HTTP协议版本,默认是1.1,目前大部分浏览器已经支持GZIP解压,使用默认即可。
gzip_http_version 1.0;

# 压缩比率。用来指定GZIP压缩比,1压缩比最小,处理速度最快;9压缩比最大,传输速度快,但处理最慢,也比较消耗cpu资源。
gzip_comp_level 9;

# 用来指定压缩的类型,无论是否指定,“text/html”类型总是会被压缩
gzip_types text/plain application/x-javascript text/css application/xml;

# vary header支持。该选项可以让前端的缓存服务器缓存经过GZIP压缩的页面,例如用Squid缓存经过Nginx压缩的数据。
gzip_vary off;

# 开启ssi支持,默认是off
ssi on;

ssi_silent_errors on;

# upstream表示负载服务器池,定义名字为backend_server的服务器池
upstream backend_server {
ip_hash;
server 172.16.244.20:81 down;
server 172.16.242.40:81 weight=1 max_fails=2 fail_timeout=30s;
}

Nginx的负载均衡模块目前支持4种调度算法,下面进行分别介绍,其中后两项属于第三方的调度方法。

  • 轮询(默认):每个请求按时间顺序逐一分配到不同的后端服务器,如果后端某台服务器宕机,故障系统被自动剔除,使用户访问不受影响;

  • Weight:指定轮询权值,Weight值越大,分配到的访问机率越高,主要用于后端每个服务器性能不均的情况下;

  • ip_hash:每个请求按访问IP的hash结果分配,这样来自同一个IP的访客固定访问一个后端服务器,有效解决了动态网页存在的session共享问题;

  • fair:比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器的响应时间来分配请求,响应时间短的优先分配。Nginx本身是不支持fair的,如果需要使用这种调度算法,必须下载Nginx的upstream_fair模块;

  • url_hash:按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,可以进一步提高后端缓存服务器的效率。Nginx本身是不支持url_hash的,如果需要使用这种调度算法,必须安装Nginx 的hash软件包。

    在HTTP Upstream模块中,可以通过server指令指定后端服务器的IP地址和端口,同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的状态有:

  • down:表示当前的server暂时不参与负载均衡;

  • backup:预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候,才会请求backup机器,因此这台机器的压力最轻;

  • max_fails:允许请求失败的次数,默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误;

  • fail_timeout:在经历了max_fails次失败后,暂停服务的时间。max_fails可以和fail_timeout一起使用。

    注意,当负载调度算法为ip_hash时,后端服务器在负载均衡调度中的状态不能是weight和backup

# 基于域名的虚拟主机
server
{
# 监听端口
listen 80;
# 指定域名
server_name www.ljcccc.com ljcccc.com;
# 设定默认首页地址
index index.html index.htm index.php; 
# 指定站点根目录,即网站程序存放目录
root /code/ljcccc; 
# 指定此虚拟主机的访问日志存放路径,最后的main用于指定访问日志的输出格式。
access_log logs/www.ixdba.net.access.log main;
# 错误页面
error_page 500 502 404 /templates/kumi/phpcms/404.html; 

# 伪静态 将www.ljcccc.com/list....html的文件转发到index.php。。。

rewrite ^/list-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /index.php?m=content&c=index&a=lists&catid=$1&types=$2&country=$3&language=$4&age=$5&startDate=$6&typeLetter=$7&type=$8&page=$9 last;

#location 标签,根目录下的.svn目录禁止访问
location ~ /.svn/ {
deny all;
}

# location 标签,符合php扩展名的请求调度到fcgi server
location ~ \.php$ {  
fastcgi_pass 127.0.0.1:9000; #抛给本机的9000端口
fastcgi_index index.php; #设定动态首页
include fcgi.conf;

# 允许访问的ip
allow 219.237.222.30 ; 
allow 219.237.222.31 ;

# 禁止其他ip访问
deny all; 
}

# 将符合js,css文件的等设定expries缓存参数,要求浏览器缓存。

location~ .*\.(js|css)?$ {
expires 30d; #客户端缓存上述js,css数据30天
}

location ~ ^/list {
# 如果后端的服务器返回502、504、执行超时等错误,自动将请求转发到upstream负载均衡池中的另一台服务器,实现故障转移。
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_cache cache_one;

#对不同的HTTP状态码设置不同的缓存时间
proxy_cache_valid 200 301 302 304 1d;
proxy_cache_valid any 1d;

#以域名、URI、参数组合成Web缓存的Key值,Nginx根据Key值哈希,存储缓存内容到二级缓存目录内

proxy_cache_key $host$uri$is_args$args;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_ignore_headers "Cache-Control" "Expires" "Set-Cookie";
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_pass http://backend_server;
add_header Nginx-Cache "$upstream_cache_status from km";
expires 1d;
}

location的匹配规则顺序

#----- 匹配规则 -----
### start ###
# 精确匹配 /login ,匹配成功后,立即结束
location  = /login {
    }

# 正则匹配,区分大小写,匹配成功后,立即结束
location ~ /images/ {
    }

# 正则匹配,不区分大小写,匹配成功后,立即结束
location ~* /images/ {
    }

# 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。
location ^~ /images/ {
    }

# 与location顺序无关
# 若完全匹配成功,就不在继续匹配,否则还会进行正则匹配
location  /blog/ {
    }

### end ###

#----- 匹配顺序 -----
### start ###
1、如果有精确匹配,会先进行精确匹配,匹配成功,立刻返回结果。
2、普通匹配与顺序无关,因为按照匹配的长短来取匹配结果。
3、正则匹配与顺序有关,因为是从上往下匹配。(首先匹配,就结束解析过程)
4、在location中,有一种通配(即 "/")的location,所有的请求,都可以匹配。

(location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (location /)

也即
(精确匹配)> (最长字符串匹配,但完全匹配) > (非正则匹配)> (正则匹配)> (最长字符串匹配,不完全匹配)> (location通配)
### end ###
-----------------------ssl(https)相关------------------------------------
server {
listen 443; #监听端口
server_name localhost;

# gbk,utf-8,gb2312,gb18030 可以实现多种编码识别
charset utf-8;
# 开启ssl 
ssl on; 
ssl_certificate  /etc/nginx/ssl/2256064_ljcccc.com.pem; #服务的证书
ssl_certificate_key /etc/nginx/ssl/2256064_ljcccc.com.key; #服务端key

ssl_session_timeout 5m; #session超时时间
ssl_verify_client on; # 开户客户端证书验证
ssl_protocols SSLv2 SSLv3 TLSv1; #允许SSL协议
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; #加密算法
ssl_prefer_server_ciphers on; #启动加密算法
}

评论

还没有任何评论,你来说两句吧

提供支持 - 友情链接 - 衫小寨