大型网站nginx服务器管理全集3

9、nginx 会话保持

nginx会话保持主要有以下几种实现方式。

1、ip_hash

ip_hash使用源地址哈希算法,将同一客户端的请求总是发往同一个后端服务器,除非该服务器不可用。

ip_hash语法:

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

ip_hash简单易用,但有如下问题:
当后端服务器宕机后,session会丢失;
来自同一局域网的客户端会被转发到同一个后端服务器,可能导致负载失衡;
不适用于CDN网络,不适用于前段还有代理的情况。

使用sticky_cookie_insert启用会话亲缘关系,这会导致来自同一客户端的请求被传递到一组服务器的同一台服务器。与ip_hash不同之处在于,它不是基于IP来判断客户端的,而是基于cookie来判断。因此可以避免上述ip_hash中来自同一局域网的客户端和前段代理导致负载失衡的情况。
语法:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    sticky_cookie_insert srv_id expires=1h domain=3evip.cn path=/;
}

说明:
expires:设置浏览器中保持cookie的时间
domain:定义cookie的域
path:为cookie定义路径

3、jvm_route方式

   jvm_route是通过session_cookie这种方式来实现session粘性。将特定会话附属到特定tomcat上,从而解决session不同步问题,但是无法解决宕机后会话转移问题。如果在cookie和url中并没有session,则这只是个简单的round-robin负载均衡。

  jvm_route的原理

  • 一开始请求过来,没有带session的信息,jvm_route就根据round robin的方法,发到一台Tomcat上面
  • Tomcat添加上session信息,并返回给客户
  • 用户再次请求,jvm_route看到session中有后端服务器的名称,他就把请求转到对应的服务器上

  暂时jvm_route模块还不支持fair的模式。jvm_route的工作模式和fair是冲突的。对于某个特定用户,当一直为他服务的Tomcat宕机后,默认情况下它会重试max_fails的次数,如果还是失败,就重新启用round robin的方式,而这种情况下就会导致用户的session丢失。

4、使用后端服务器自身通过相关机制保持session同步,如:使用数据库、redis、memcached 等做session复制

10、nginx 实现动静分离

为了加快网站的解析速度,可以把动态页面和静态页面由不同的服务器来解析,加快解析速度。降低原来单个服务器的压力。 在动静分离的tomcat的时候比较明显,因为tomcat解析静态很慢,其实这些原理的话都很好理解,简单来说,就是使用正则表达式匹配过滤,然后交个不同的服务器。

1、准备环境

准备一个nginx代理 两个http 分别处理动态和静态。

  location / {
            root   /var/www/html/upload;
            index  index.php index.htm;
        }
2、本地配置
  location ~ .*\.(html|gif|jpg|png|bmp|swf|jpeg)$ {
            root   /var/www/html/move;
            index  index.php;
        }
  location ~ \.php$ {
            root   /var/www/html/static;
            index  index.html;
        }
3、代理配置
  location ~ .*\.(html|gif|jpg|png|bmp|swf|jpeg)$ {
                proxy_pass http://172.17.14.2:80;
        }
  location ~ \.php$ {
                proxy_pass http://172.17.14.3:80;
        }
4、配置项说明

location / 的作用

定义了请求代理的时候nginx去/var/www/html/upload 下寻找index.php 当他找到index.php的时候匹配了下面的正则 location ~ .php$。

location ~ .php$ 的作用

以php结尾的都以代理的方式转发给web1(172.17.14.2),http1 去处理,这里http1要去看自己的配置文件 在自己的配置文件中定义网站根目录 /var/www/html/upload 找.index.php 然后处理解析返回给nginx 。

location ~ .*.(html|gif|jpg|png|bmp|swf|jpeg)$ 的作用

以html等等的静态页面都交给web2(172.17.14.3)来处理 ,web2 去找自己的网站目录 然后返回给nginx 。

两个 web 放的肯定是一样的目录,只不过每个服务器的任务不一样。

代理本身要有网站的目录,因为最上面的 location / 先生效 如果没有目录 会直接提示找不到目录 不会再往下匹配。

11、nginx 防盗链问题

1、nginx 防止网站资源被盗用模块
ngx_http_referer_module

如何区分哪些是不正常的用户?

​ HTTP Referer是Header的一部分,当浏览器向Web服务器发送请求的时候,一般会带上Referer,

告诉服务器我是从哪个页面链接过来的,服务器借此可以获得一些信息用于处理,例如防止未经允许

的网站盗链图片、文件等。因此HTTP Referer头信息是可以通过程序来伪装生成的,所以通过Referer

信息防盗链并非100%可靠,但是,它能够限制大部分的盗链情况。

2. 防盗链配置

配置要点:

# 日志格式添加"$http_referer"
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                         '$status $body_bytes_sent "$http_referer" '
                         '"$http_user_agent" "$http_x_forwarded_for"';
# valid_referers 使用方式                         
Syntax: 	valid_referers none | blocked | server_names | string ...;
Default: 	—
Context: server, location
  • none : 允许没有http_refer的请求访问资源;
  • blocked : 允许不是http://开头的,不带协议的请求访问资源;
  • server_names : 只允许指定ip/域名来的请求访问资源(白名单);
[root@localhost ~]# vim /etc/nginx/conf.d/nginx.conf
location / {
        root   /var/www/html/xulei.com;
        index  index.html index.htm;
     
        valid_referers none blocked *.xulei.com 192.168.95.134;
        if ($invalid_referer) {
            return 403;
        }
    }

[root@localhost ~]# vim /etc/nginx/conf.d/nginx.conf
location ~ .*\.(gif|jpg|png|jpeg)$ {
         root  /var/www/html/images;
         
         valid_referers none blocked xulei.com 192.168.95.134;
         if ($invalid_referer) {
            return 403;
         }
}
  • 页面配置
xulei.com
[root@localhost ~]# vim /var/www/html/index.html                           
<html>
<head>
    <meta charset="utf-8">
    <title>xulei.com</title>
</head>
<body style="background-color:red;">
    <img src="http://192.168.95.134/xulei.jpg"/>
</body>
</html>
3、 重载nginx服务
[root@localhost ~]# nginx -s reload -c /etc/nginx/nginx.conf
4、 测试防盗链
4.1、不带http_refer
[root@localhost ~]# curl -I http://192.168.95.134/xulei.jpg
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 30 Nov 2018 18:26:10 GMT
Content-Type: image/jpeg
Content-Length: 68227
Last-Modified: Thu, 30 Nov 2018 17:46:19 GMT
Connection: keep-alive
ETag: "5a2043eb-10a83"
Accept-Ranges: bytes
4.2、带非法http_refer
[root@localhost ~]# curl -e "http://www.baidu.com" -I http://192.168.95.134/xulei.jpg
HTTP/1.1 403 Forbidden
Server: nginx/1.14.1
Date: Thu, 30 Nov 2018 18:25:52 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
4.3 带合法http_refer
[root@localhost ~]# curl -e "http://192.168.95.134" -I http://192.168.95.134/xulei.jpg
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 30 Nov 2018 18:27:30 GMT
Content-Type: image/jpeg
Content-Length: 68227
Last-Modified: Thu, 30 Nov 2018 17:46:19 GMT
Connection: keep-alive
ETag: "5a2043eb-10a83"
Accept-Ranges: bytes
5、其他配置
5.1、匹配域名

完全防盗

location ~ .*\.(gif|jpg|png|jpeg)$ {
    valid_referers 192.168.95.134 *.baidu.com *.google.com;
    if ($invalid_referer) {
        rewrite ^/ http://192.168.95.134/fdl.jpg
        #return 403;
    }
    root  /var/www/html/images;
}

直接访问图片链接可以下载

location ~* \.(gif|jpg|png|bmp)$ {
       valid_referers none blocked  *.xulei.com  ~xulei  ~\.google\./ ~\.baidu\./;
       if ($invalid_referer) {
           return 403;
           #rewrite .* http://xulei.com/403.jpg;
    }
}

以上所有来自 xulei.com 和域名中包含google和baidu的站点都可以访问到当前站点的图片,如果来源域名不在这个列表中,那么$invalid_referer等于1,在if语句中返回一个403给用户,这样用户便会看到一个403的页面,如果使用下面的rewrite,那么盗链的图片都会显示403.jpg。如果用户直接在浏览器输入你的图片地址,那么图片显示正常,因为它符合none这个规则。

12、nginx 地址重写 rewrite

1、什么是Rewrite

​ Rewrite对称URL Rewrite,即URL重写,就是把传入Web的请求重定向到其他URL的过程。

  • URL Rewrite最常见的应用是URL伪静态化,是将动态页面显示为静态页面方式的一种技术。比如
    http://www.123.com/news/index.php?id=123 使用URLRewrite 转换后可以显示为 http://www.123
    .com/news/123.html对于追求完美主义的网站设计师,就算是网页的地址也希望看起来尽量简洁明快。
    理论上,搜索引擎更喜欢静态页面形式的网页,搜索引擎对静态页面的评分一般要高于动态页面。所
    以,UrlRewrite可以让我们网站的网页更容易被搜索引擎所收录。

  • 从安全角度上讲,如果在URL中暴露太多的参数,无疑会造成一定量的信息泄漏,可能会被一些不法分子
    利用,对你的系统造成一定的破坏,所以静态化的URL地址可以给我们带来更高的安全性。

  • 实现网站地址跳转,例如用户访问360buy.com,将其跳转到jd.com。例如当用户访问xulei.com的
    80端口时,将其跳转到443端口。

2、Rewrite 相关指令
  • Nginx Rewrite 相关指令有 if、rewrite、set、return
2.1、if 语句
  • 应用环境
server,location
  • 语法
if (condition) { … }
if 可以支持如下条件判断匹配符号
~ 					正则匹配 (区分大小写)
~* 				    正则匹配 (不区分大小写)
!~                  正则不匹配 (区分大小写)
!~*		            正则不匹配  (不区分大小写)
-f 和!-f 		    用来判断是否存在文件
-d 和!-d 		    用来判断是否存在目录
-e 和!-e 		    用来判断是否存在文件或目录
-x 和!-x 		    用来判断文件是否可执行

在匹配过程中可以引用一些Nginx的全局变量
$args				请求中的参数;
$document_root	    针对当前请求的根路径设置值;
$host				请求信息中的"Host",如果请求中没有Host行,则等于设置的服务器名;
$limit_rate			对连接速率的限制;
$request_method		请求的方法,比如"GET"、"POST"等;
$remote_addr		客户端地址;
$remote_port		客户端端口号;
$remote_user		客户端用户名,认证用;
$request_filename   当前请求的文件路径名(带网站的主目录/usr/local/nginx/html/images /a.jpg)
$request_uri		当前请求的文件路径名(不带网站的主目录/images/a.jpg)
$query_string		与$args相同;
$scheme				用的协议,比如http或者是https
$server_protocol	请求的协议版本,"HTTP/1.0"或"HTTP/1.1";
$server_addr 		服务器地址,如果没有用listen指明服务器地址,使用这个变量将发起一次系统调用以取得地址(造成资源浪费);
$server_name		请求到达的服务器名;
$document_uri 		与$uri一样,URI地址;
$server_port 		请求到达的服务器端口号;
2.2、Rewrite flag

rewrite 指令根据表达式来重定向URI,或者修改字符串。可以应用于server,location, if环境下每行rewrite指令最后跟一个flag标记,支持的flag标记有:

last 			    相当于Apache里的[L]标记,表示完成rewrite
break 				本条规则匹配完成后,终止匹配,不再匹配后面的规则
redirect 			返回302临时重定向,浏览器地址会显示跳转后的URL地址
permanent 		    返回301永久重定向,浏览器地址会显示跳转后URL地址

redirect 和 permanent区别则是返回的不同方式的重定向,对于客户端来说一般状态下是没有区别的。而对于搜索引擎,相对来说301的重定向更加友好,如果我们把一个地址采用301跳转方式跳转的话,搜索引擎会把老地址的相关信息带到新地址,同时在搜索引擎索引库中彻底废弃掉原先的老地址。使用302重定向时,搜索引擎(特别是google)有时会查看跳转前后哪个网址更直观,然后决定显示哪个,如果它觉的跳转前的URL更好的话,也许地址栏不会更改,那么很有可能出现URL劫持的现像。在做URI重写时,有时会发现URI中含有相关参数,如果需要将这些参数保存下来,并且在重写过程中重新引用,可以用到 () 和 $N 的方式来解决。

2.3、Rewrite匹配参考示例
示例1:
# http://www.xulei.com/a/1.html ==> http://www.xulei.com/b/2.html
location /abc {
    rewrite .* /b/2.html permanent;
    #return 301 /b/2.html;
}

例2:
# http://www.xulei.com/2019/a/1.html ==> http://www.xulei.com/2018/b/2.html
location /2019 {
     rewrite ^/2019/(.*)$ /2018/$1 permanent;
}

例3:
# http://www.xulei.com/a/1.html ==> http://jd.com
if ( $host ~* xulei.com ) {
	rewrite .*	http://jd.com permanent;
}

例4:
# http://www.xulei.com/a/1.html ==> http://jd.com/b/2.html
if ( $host ~* xulei.com ) {
	rewrite  .*	 http://jd.com$request_uri permanent;
}

例5: 在访问目录后添加/  (如果目录后已有/,则不加/)
# http://www.xulei.com/test/
# $1: /a/b
# $2: c
# http://$host$1$2/
if (-d $request_filename) {
    rewrite ^(.*)([^/])$ http://$host$1$2/ permanent;
}

例6:
# http://www.xulei.com/login/xulei.html ==>  http://www.xulei.com/reg/login.php?user=xulei

location /login {
           rewrite ^/login/(.*)\.html$ /reg/login.php?user=$1;
        }

例7:
#http://www.xulei.com/xulei/11-22-33/1.html  ==>  http://www.xulei.com/xulei/11/22/33/1.html
location /xulei {
            rewrite ^/xulei/([0-9]+)-([0-9]+)-([0-9]+)(.*)$ /xulei/$1/$2/$3$4 permanent;
        }

2.4、set 指令

set 指令是用于定义一个变量,并且赋值

  • 应用环境:
server,location,if
  • 应用示例
例8:
#http://alice.xulei.com ==> http://www.xulei.com/alice
#http://jack.xulei.com ==> http://www.xulei.com/jack

[root@localhost html]# mkdir jack alice
[root@localhost html]# echo jack.... > jack/index.html
[root@localhost html]# echo alice... > alice/index.html

a. DNS实现泛解析
*   		IN      A			    网站IP

b. nginx Rewrite
if ($host ~* "^www.xulei.com$" ) {
      break;
  }

if ($host ~* "^(.*)\.xulei\.com$" ) {
      set $user $1;
      rewrite .* http://www.xulei.com/$user permanent;
  }
2.5、return 指令

return 指令用于返回状态码给客户端

  • 应用环境:
server,location,if
  • 应用示例:
例9:如果访问的.sh结尾的文件则返回403操作拒绝错误
location ~* \.sh$ {
	return 403;
	#return 301 http://www.xulei.com;
}

例10:80 ======> 443
server {
        listen      80;
        server_name  www.xulei.com xulei.com;
        return     301  https://www.xulei.com$request_uri;
        }
server {
        listen      443 ssl;
        server_name  www.xulei.com;
        ssl  on;
        ssl_certificate      /usr/local/nginx/conf/cert.pem;
        ssl_certificate_key  /usr/local/nginx/conf/cert.key;
        location / {
            root html;
            index index.html index.php;
        }
    }

[root@localhost html]# curl -I http://www.xulei.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.1
Date: Tue, 26 Jul 2026 15:07:50 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://www.xulei.com/
3、last,break详解

在这里插入图片描述

[root@localhost html]# mkdir test
[root@localhost html]# echo 'break' > test/break.html
[root@localhost html]# echo 'last' > test/last.html
[root@localhost html]# echo 'test...' > test/test.html

http://192.168.10.33/break/break.html
http://192.168.10.33/last/last.html

注意:

  • last 标记在本条 rewrite 规则执行完后,会对其所在的 server { … } 标签重新发起请求;

  • break 标记则在本条规则匹配完成后,停止匹配,不再做后续的匹配;

  • 使用 alias 指令时,必须使用 last;

  • 使用 proxy_pass 指令时,则必须使用break。

4、Nginx 的 https ( rewrite )
 server {
        listen       80;
        server_name  *.vip9999.top vip9999.top;

        if ($host ~* "^www.vip9999.top$|^vip9999.top$" ) {
                return 301 https://www.vip9999.top$request_uri;
        }

        if ($host ~* "^(.*).vip9999.top$" ) {
                set $user $1;
                return 301 https://www.vip9999.top/$user;
        }

    }

    # Settings for a TLS enabled server.
    server {
        listen       443 ssl;
        server_name  www.vip9999.top;

        location / {
                root      /usr/share/nginx/html;
                index     index.php index.html;
        }

        #pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        location ~ \.php$ {
            root           /usr/share/nginx/html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
        }
        ssl on;
        ssl_certificate cert/214025315060640.pem;
        ssl_certificate_key cert/214025315060640.key;
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;
        }
5、Apache 的 https ( rewrite )
[root@localhost ~]# yum -y install httpd mod_ssl
[root@localhost ~]# vim /etc/httpd/conf.d/vip9999.conf

在这里插入图片描述

13、nginx location 指令详解

Nginx 的 HTTP 配置主要包括三个区块,结构如下:

http { 						# 这个是协议级别
  include mime.types;
  default_type application/octet-stream;
  keepalive_timeout 65;
  gzip on;
    server {			 # 这个是服务器级别
      listen 80;
      server_name localhost;
        location / {  # 这个是请求级别
          root html;
          index index.html index.htm;
        }
      }
}
1、location 区段
  • location 是在 server 块中配置,根据不同的 URI 使用不同的配置,来处理不同的请求。

  • location 是有顺序的,会被第一个匹配的location 处理。

  • 基本语法如下:

location [=|~|~*|^~|@] pattern{……}
2、location 前缀含义
=    表示精确匹配,优先级也是最高的 
^~   表示uri以某个常规字符串开头,理解为匹配url路径即可 
~    表示区分大小写的正则匹配
~*   表示不区分大小写的正则匹配
!~   表示区分大小写不匹配的正则
!~*  表示不区分大小写不匹配的正则
/    通用匹配,任何请求都会匹配到
@    内部服务跳转
3、location 配置示例

1、没有修饰符 表示:必须以指定模式开始

server {
  server_name xulei.com;
  location /abc {
    ……
  }
}

那么,如下是对的:
http://xulei.com/abc
http://xulei.com/abc?p1
http://xulei.com/abc/
http://xulei.com/abcde 

2、=表示:必须与指定的模式精确匹配

server {
server_name xulei.com
  location = /abc {
    ……
  }
}
那么,如下是对的:
http://xulei.com/abc
http://xulei.com/abc?p1
如下是错的:
http://xulei.com/abc/
http://xulei.com/abcde

3、~ 表示:指定的正则表达式要区分大小写

server {
server_name xulei.com;
  location ~ ^/abc$ {
    ……
  }
}
那么,如下是对的:
http://xulei.com/abc
http://xulei.com/abc?p1=11&p2=22
如下是错的:
http://xulei.com/ABC
http://xulei.com/abc/
http://xulei.com/abcde

4、~* 表示:指定的正则表达式不区分大小写

server {
server_name xulei.com;
location ~* ^/abc$ {
    ……
  }
}
那么,如下是对的:
http://xulei.com/abc
http://xulei..com/ABC
http://xulei..com/abc?p1=11&p2=22
如下是错的:
http://xulei..com/abc/
http://xulei..com/abcde

5、^~ :类似于无修饰符的行为,也是以指定模式开始,不同的是,如果模式匹配,那么就停止搜索其他模式了。
6、@ :定义命名 location 区段,这些区段客户段不能访问,只可以由内部产生的请求来访问,如try_files或error_page等

查找顺序和优先级

1:带有“=“的精确匹配优先

2:没有修饰符的精确匹配

3:正则表达式按照他们在配置文件中定义的顺序

4:带有“^~”修饰符的,开头匹配

5:带有“~” 或“~*” 修饰符的,如果正则表达式与URI匹配

6:没有修饰符的,如果指定字符串与URI开头匹配

location 区段匹配示例

location = / {
  # 只匹配 / 的查询.
  [ configuration A ]
}
location / {
  # 匹配任何以 / 开始的查询,但是正则表达式与一些较长的字符串将被首先匹配。
  [ configuration B ]
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开始的查询并且停止搜索,不检查正则表达式。
  [ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配任何以gif, jpg, or jpeg结尾的文件,但是所有 /images/ 目录的请求将在Configuration C中处理。
  [ configuration D ]
} 
各请求的处理如下例:
	/ → configuration A
	/documents/document.html → configuration B
	/images/1.gif → configuration C
	/documents/1.jpg → configuration D
4、root 、alias 指令区别
location /img/ {
    alias /var/www/image/;
}
#若按照上述配置的话,则访问/img/目录里面的文件时,ningx会自动去/var/www/image/目录找文件
location /img/ {
    root /var/www/image;
}
#若按照这种配置的话,则访问/img/目录下的文件时,nginx会去/var/www/image/img/目录下找文件。] 
  • alias 是一个目录别名的定义,

  • root 则是最上层目录的定义。

  • 还有一个重要的区别是alias后面必须要用“/”结束,否则会找不到文件的,而root则可有可无。

14、nginx 日志配置

1、nginx 日志介绍

nginx 有一个非常灵活的日志记录模式,每个级别的配置可以有各自独立的访问日志, 所需日志模块 ngx_http_log_module 的支持,日志格式通过 log_format 命令来定义,日志对于统计和排错是非常有利的,
下面总结了 nginx 日志相关的配置 包括 access_loglog_formatopen_log_file_cachelog_not_foundlog_subrequestrewrite_logerror_log

2、access_log 指令

访问日志主要记录客户端的请求。客户端向 Nginx 服务器发起的每一次请求都记录在这里。客户端IP,浏览器信息,referer,请求处理时间,请求URL等都可以在访问日志中得到。当然具体要记录哪些信息,你可以通过log_format指令定义。

语法:

# 设置访问日志
access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
# 关闭访问日志
access_log off; 
  • path 指定日志的存放位置。
  • format 指定日志的格式。默认使用预定义的combined
  • buffer 用来指定日志写入时的缓存大小。默认是64k。
  • gzip 日志写入前先进行压缩。压缩率可以指定,从1到9数值越大压缩比越高,同时压缩的速度也越慢。默认是1。
  • flush 设置缓存的有效时间。如果超过flush指定的时间,缓存中的内容将被清空。
  • if 条件判断。如果指定的条件计算为0或空字符串,那么该请求不会写入日志。

作用域:

可以应用access_log指令的作用域分别有httpserverlocationlimit_except。也就是说,在这几个作用域外使用该指令,Nginx会报错。

基本用法:

access_log /var/logs/nginx-access.log

该例子指定日志的写入路径为/var/logs/nginx-access.log,日志格式使用默认的combined

access_log /var/logs/nginx-access.log buffer=32k gzip flush=1m

该例子指定日志的写入路径为/var/logs/nginx-access.log,日志格式使用默认的combined,指定日志的缓存大小为 32k,日志写入前启用 gzip 进行压缩,压缩比使用默认值 1,缓存数据有效时间为1分钟。

3、log_format 指令

Nginx 预定义了名为 combined 日志格式,如果没有明确指定日志格式默认使用该格式:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

如果不想使用Nginx预定义的格式,可以通过log_format指令来自定义。

语法

log_format name [escape=default|json] string ...;
  • name 格式名称。在 access_log 指令中引用。
  • escape 设置变量中的字符编码方式是json还是default,默认是default
  • string 要定义的日志格式内容。该参数可以有多个。参数中可以使用Nginx变量。

log_format 指令中常用的一些变量:

变量 含义
$bytes_sent 发送给客户端的总字节数
$body_bytes_sent 发送给客户端的字节数,不包括响应头的大小
$connection 连接序列号
$connection_requests 当前通过连接发出的请求数量
$msec 日志写入时间,单位为秒,精度是毫秒
$pipe 如果请求是通过http流水线发送,则其值为"p",否则为“."
$request_length 请求长度(包括请求行,请求头和请求体)
$request_time 请求处理时长,单位为秒,精度为毫秒,从读入客户端的第一个字节开始,直到把最后一个字符发送张客户端进行日志写入为止
$status 响应状态码
$time_iso8601 标准格式的本地时间,形如“2017-05-24T18:31:27+08:00”
$time_local 通用日志格式下的本地时间,如"24/May/2017:18:31:27 +0800"
$http_referer 请求的referer地址。
$http_user_agent 客户端浏览器信息。
$remote_addr 客户端IP
$http_x_forwarded_for 当前端有代理服务器时,设置web节点记录客户端地址的配置,此参数生效的前提是代理服务器也要进行相关的x_forwarded_for设置。
$request 完整的原始请求行,如 "GET / HTTP/1.1"
$remote_user 客户端用户名称,针对启用了用户认证的请求
$request_uri 完整的请求地址,如 "https://xulei.com/"

自定义日志格式的使用:

access_log /var/logs/nginx-access.log main

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

使用log_format指令定义了一个main的格式,并在access_log指令中引用了它。假如客户端有发起请求:https://xulei.com/,我们看一下我截取的一个请求的日志记录:

192.168.95.134 - - [20/Feb/2019:12:12:14 +0800] "GET / HTTP/1.1" 200 190 "-" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36" "-"

我们看到最终的日志记录中$remote_user$http_referer$http_x_forwarded_for都对应了一个-,这是因为这几个变量为空。

5、error_log 指令

错误日志在Nginx中是通过error_log指令实现的。该指令记录服务器和请求处理过程中的错误信息。

语法

配置错误日志文件的路径和日志级别。

error_log file [level];
Default:	
error_log logs/error.log error;

file 参数指定日志的写入位置。

level 参数指定日志的级别。level可以是debug, info, notice, warn, error, crit, alert,emerg中的任意值。可以看到其取值范围是按紧急程度从低到高排列的。只有日志的错误级别等于或高于level指定的值才会写入错误日志中。默认值是error

基本用法

error_log /var/logs/nginx/nginx-error.log

配置段:mainhttp, mail, stream, server, location作用域。

例子中指定了错误日志的路径为:/var/logs/nginx/nginx-error.log,日志级别使用默认的 error

6、open_log_file_cache 指令

每一条日志记录的写入都是先打开文件再写入记录,然后关闭日志文件。如果你的日志文件路径中使用了变量,如 access_log /var/logs/$host/nginx-access.log,为提高性能,可以使用open_log_file_cache指令设置日志文件描述符的缓存。

语法

open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];

默认值: 
open_log_file_cache off;
  • max 设置缓存中最多容纳的文件描述符数量,如果被占满,采用LRU算法将描述符关闭。
  • inactive 设置缓存存活时间,默认是10s。
  • min_usesinactive时间段内,日志文件最少使用几次,该日志文件描述符记入缓存,默认是1次。
  • valid:设置多久对日志文件名进行检查,看是否发生变化,默认是60s。
  • off:不使用缓存。默认为off。

基本用法

open_log_file_cache max=1000 inactive=20s valid=1m min_uses=2;

配置段:httpserverlocation作用域中。

例子中,设置缓存最多缓存1000个日志文件描述符,20s内如果缓存中的日志文件描述符至少被被访问2次,才不会被缓存关闭。每隔1分钟检查缓存中的文件描述符的文件名是否还存在。

7、log_not_found 指令

是否在error_log中记录不存在的错误。默认是

基本语法:

log_not_found on | off;
默认值: 
log_not_found on;

配置段: http, server, location作用域。

8、log_subrequest 指令

是否在access_log中记录子请求的访问日志。默认不记录

基本语法:

log_subrequest on | off;

默认值: 
log_subrequest off;

配置段: http, server, location作用域。

9、rewrite_log 指令

ngx_http_rewrite_module模块提供的。用来记录重写日志的。对于调试重写规则建议开启,启用时将在error log中记录notice级别的重写日志。
基本语法:

rewrite_log on | off;

默认值: 
rewrite_log off;

配置段: http, server, location, if作用域。

10、nginx 日志配置总结

Nginx中通过access_logerror_log指令配置访问日志和错误日志,通过log_format我们可以自定义日志格式。如果日志文件路径中使用了变量,我们可以通过open_log_file_cache 指令来设置缓存,提升性能。其他的根据自己的使用场景定义。

详细的日志配置信息可以参考Nginx官方文档

符至少被被访问2次,才不会被缓存关闭。每隔1分钟检查缓存中的文件描述符的文件名是否还存在。

7、log_not_found 指令

是否在error_log中记录不存在的错误。默认是

基本语法:

log_not_found on | off;
默认值: 
log_not_found on;

配置段: http, server, location作用域。

8、log_subrequest 指令

是否在access_log中记录子请求的访问日志。默认不记录

基本语法:

log_subrequest on | off;

默认值: 
log_subrequest off;

配置段: http, server, location作用域。

9、rewrite_log 指令

ngx_http_rewrite_module模块提供的。用来记录重写日志的。对于调试重写规则建议开启,启用时将在error log中记录notice级别的重写日志。
基本语法:

rewrite_log on | off;

默认值: 
rewrite_log off;

配置段: http, server, location, if作用域。

10、nginx 日志配置总结

Nginx中通过access_logerror_log指令配置访问日志和错误日志,通过log_format我们可以自定义日志格式。如果日志文件路径中使用了变量,我们可以通过open_log_file_cache 指令来设置缓存,提升性能。其他的根据自己的使用场景定义。

详细的日志配置信息可以参考Nginx官方文档