Nginx基础详解3（nginx.conf核心代码讲解、常用命令解析、Nginx日志切割）

害羞的白菜

已于 2024-10-01 23:35:35 修改

阅读量1.2k

点赞数 20

分类专栏： Nginx基础入门详解文章标签： nginx java 服务器笔记运维 centos linux

于 2024-09-26 21:26:47 首次发布

本文链接：https://blog.youkuaiyun.com/2301_78053665/article/details/142567603

版权

Nginx基础入门详解专栏收录该内容

5 篇文章

订阅专栏

续Nginx基础详解2（首页解析过程、进程模型、处理Web请求机制、nginx.conf语法结构）-优快云博客

8.3.1.2mime.type文件的查看，include导入该文件的原因

8.3.2access_log

8.3.3sendfile与tcp_nopush

8.3.4Keepalive_timeout

8.4.6error_page下的root

8.5模块之间的关系和概括

8.5.1三个模块之间的关系

8.6实验，自己创建一个**.conf并且导入到nginx.conf文件中，**.conf文件必须包含至少两个网页，可以实现互相跳转

9.Nginx日志切割

9.1创建时间计划完成对日志的自动轮转

8.nginx.conf核心代码

在上一节我们学到了Nginx分成的几个模块。类似于“洋葱模型”一样，一层一层的包裹住，下面我们进入nginx.conf进行代码的学习。

#user nobody;
worker_processes 1;

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;

events {
worker_connections 1024;
}

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

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

#access_log logs/access.log main;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;

server {
listen 80;
server_name localhost;

#charset koi8-r;

#access_log logs/host.access.log main;

location / {
root html;
index index.html index.htm;
}

#error_page 404 /404.html;

# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;

# location / {
# root html;
# index index.html index.htm;
# }
#}

# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;

# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;

# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;

# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;

# location / {
# root html;
# index index.html index.htm;
# }
#}
}

上方代码为nginx的默认界面的代码，现在我们就可以对其核心代码进行讲解了

8.1错误日志

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

为了方便理解，我们按空格作为分隔符，将上面的代码分成三列

8.1.1第一列：

#error_log：

表示Nginx运行时的错误日志。我们在最初在生成Makefile文件前就已经写好了错误日志的存放位置，在Nginx基础详解1（单体部署与集群部署、负载均衡、正反代理、nginx安装）-优快云博客这篇文章内的3.3.3章节中，我们有一段专门声明了错误日志的存放位置（如下图）。而nginx.conf将日志文件默认注释也是有原因的（如下代码块）

灵活性：默认配置允许用户根据自己的需求来设置日志路径。不同的部署环境可能有不同的日志存储策略。

安全性：避免在默认配置中写入具体的日志路径，可以防止在某些情况下日志被写入到不安全的位置。

简化配置：对于大多数用户来说，可能不需要立即自定义日志文件的位置，因此默认情况下不设置可以减少配置的复杂性。

避免冲突：在某些情况下，如果 Nginx 被安装在不同的环境或者由不同的包管理器安装，可能会有预设的日志路径。默认注释掉可以避免与这些预设路径发生冲突。

易于识别：当用户查看配置文件时，被注释掉的 error_log 指令可以作为一个明显的提示，告诉用户需要根据自己的环境来设置日志路径。

8.1.2第二列：

logs/error.log;

表示错误日志的存放位置。

logs：这是一个目录名，通常位于 Nginx 的安装目录下，用于存放日志文件。
error.log：这是日志文件的名称，用于记录 Nginx 运行时的错误信息。

如果想要更改错误日志的存放路径也是可以的

在 Nginx 的配置文件中，你可以这样设置错误日志的路径：】

绝对路径

error_log /var/log/nginx/error.log;

你看，这不就是和我们上述的手动配置的log-path=/var/log/nginx/error.log路径一样了吗？
所以说某些步骤我们已经是配置好了的，这里再更改成上面的路径就是画蛇添足了

或者，如果你使用相对路径：

error_log logs/error.log;

8.1.3第三列：

notice

info

notice和info代表着日志的级别，和Linux的进程一样，日志也是有级别的，级别越高出现的问题越严重

讲到这里，和同学们稍微普及一下日志的相关知识：

日志的级别共分为8个级别

debug：最详细的日志级别，包括所有信息，用于调试目的。在生产环境中通常不推荐使用，因为它可能会产生大量的日志数据。

info：记录一般信息，包括启动、配置加载、连接处理等信息。比 notice 级别更详细。

notice：记录正常运行时的重要事件，如启动、关闭、配置错误等。

warn：记录潜在的问题，但不一定影响服务的运行。这些信息表明可能需要注意或调查的问题。

error：记录错误事件，这些事件可能会影响服务的运行，但服务通常仍能继续运行。

crit：记录严重错误事件，这些事件可能会使服务无法正常运行。

alert：记录需要立即采取行动的严重问题，如系统崩溃或严重的配置错误。

emerg：记录紧急情况，如系统崩溃或严重的硬件故障。

自上而下问题逐渐严重，但是记录逐渐变少，像emerg仅记录最严重的情况，而debug基本上所有的信息都会记录。

8.2 #pid

#pid logs/nginx.pid;

#pid：表示声明了pid，后面就是pid的存储位置了

logs/nginx.pid; ：表示nginx的pid的存储位置，我们也是在配置的时候提前写过关于pid的配置路径。

我们可以进入该路径进行简单的查看

8.3http模块（要点）

因为http模块占了整个nginx.conf配置文件的大多数，所以我们现在先拣出来重要的几条进行讲解

8.3.1include语句

include语句用于导入其他配置文件，我们将写好的配置文件装载到计算机的某一路径下，使用

include 配置文件所在路径

8.3.1.1自定义文件的导入

例如：我在/usr/local/nginx/conf下写了一个zhangsan.conf的配置文件，在nginx.conf中对其进行导入，因为nginx.conf和zhangsan.conf都是在同一级的目录下，所以我们可以直接写成

include zhangsan.conf

自定义的文件进行导入时，需要注意的是

配置文件必须是conf结尾
配置文件的路径必须正确否则可能出现读不到的情况
配置文件必须能让nginx有权限去读到
用include的位置尽量在server的括号内

8.3.1.2mime.type文件的查看，include导入该文件的原因

那么导入的mime.type文件里面有什么内容呢？为什么nginx的默认配置文件中没有将include mime.type注释掉呢？我们可以一起来瞧一瞧其中的内容

在/usr/local/nginx/conf下进行查看

cat mime.type

如下图

我们发现有一个types的请求块，内部有我们需要请求的一些资源的类型，导入这个文件，就可以方便我们的nginx识别来自客户端的请求的类型（可以识别静态资源、动态资源，静态动态资源的分类我们上一篇已经讲过了）

将这些种类写成一个配置文件进行导入，最大的一个好处就是最大限度地提高了nginx.con的可读性,因为我们后期如果频繁的查看nginx.conf的配置文件，写成一个包导入会很方便。大家可以用自己的centos虚拟机去看一眼mime.type中包含的资源类型，非常多，如果不使用include单独提取并导入的话那么nginx.conf就会又臭又长。

8.3.2access_log

该文件用于记录请求的数量，我们开启了一台服务器之后，nginx会接收来自客户机的请求，每接收一个，access_log文件都会被记录一次。

验证一下吧：

1.找到access_log记录的位置

vim /var/log/nginx/access.log

2.记住最后nginx接收请求的时间，一会要用

[23/Sep/2024:15:39:50...]

3.访问nginx服务器，在浏览器多刷新几次页面再来看这个文件

我们发现时间改了！变成了【26/Sep/2024：18......】说明我们的access_log就是记录客户机请求的！实验成功！

而上图中日志的格式又正好对应了nginx.conf中access_log上面的log_format文件！变量与实参之间是一一对应的。

$remote_addr：客户端的 IP 地址。
$remote_user：认证的用户名。
$time_local：本地时间。
$request：请求的完整原始行。
$status：请求的 HTTP 状态码。
$body_bytes_sent：发送给客户端的响应体的字节数。
$http_referer：HTTP referer 头部的值。
$http_user_agent：HTTP user-agent 头部的值。
$http_x_forwarded_for：HTTP x-forwarded-for 头部的值，通常用于记录原始请求的 IP 地址，当使用了代理或负载均衡器时。

8.3.3sendfile与tcp_nopush

sendfile默认为on打开状态，表示文件传输打开“性能状态”文件的传输速率会提高。

tcp_nopush默认为关闭状态，与sendfile相互配合，只有sendfile为打开状态时no_push才会起到相应的作用，表示为nginx发送数据包需累计到一定大小再发送，而具体的大小并没有一个固定的数据包大小阈值，因为它依赖于操作系统的内核行为。

不需要理解的太深奥，总的来说，tcp_nopush 可以优化大文件的传输性能，通过累积一定量的数据再发送，减少网络传输的次数，从而提高效率。类比外卖点餐，外卖小哥会一次性从某个热门餐厅一次性取走他的外卖，而不是一个一个地去取，这样确实会提高效率。

8.3.4Keepalive_timeout

客户端与nginx连接的超时时间我们使用Keepalive进行设置，默认状态下为0，但是在默认配置下还有一行Keepalive_timeout = 65是打开的。因为http本质是一种无状态协议，客户端发送请求的时候服务端会去相应，在连续的65s没有相应到请求的时候连接就会断开，如果客户端向Server发送了多个请求的话每个请求都需要独立的取进行连接、传输数据。Keepalived就会告诉Web服务器处理完一个连接之后保持打开Tcp连接（后面到吞吐量的地方还会讲一遍，这种方式也被称作长连接，会提高Web服务器的吞吐量）同一个连接在来请求的话就不需要再次创建连接了，客户端的请求会直传到相应的Web服务器上，好处就是节省了开销。如果不想使用长连接则可以将Keepalive_timeout = 65删除即可。

8.3.5gzip

gzip的好处就是对于接收的资源进行压缩，可以有效的节约服务器带宽的开销，缺点是打开该项之后也会消耗更多的Cpu性能

我对gzip的建议就是：

如果你服务器的硬盘配置好、空间大就不用开；
如果你的CPU核多、性能好、速度快也可以开。

反之就需要慎重考虑是否打开该选项了

8.4Server模块

8.4.1listen

listen 指令告诉 Nginx 监听哪个端口的传入请求。这里，80 是 HTTP 默认端口，这意味着服务器将接受发送到这个端口的 HTTP 请求。

8.4.2server_name

server_name 指令用于指定服务器的域名。在这个例子中，localhost 表示服务器将响应来自本地主机的请求。通常，你会将这个值设置为你的域名，如 example.com。

server可以填写的内容

locolhost：当 server_name 设置为 localhost 时，它表示该虚拟主机仅响应来自本地主机的请求。
ip地址：可以是自己的IP地址，也可以服务器的IP地址
域名（已备案的，如果是自己做实验的域名那无所谓，但是需要改自己的本机hosts文件）

8.4.3location模块

这一行开始了一个新的 location 块，它定义了服务器如何处理对根 URL (/) 的请求。

8.4.3.1root

root 指令指定了文件服务的根目录。在这里，html 表示服务器将从当前 Nginx 配置目录下的 html 子目录中查找并提供文件。

8.4.3.2index

index 指令定义了目录的默认首页文件。如果请求一个目录而不是一个具体的文件，Nginx 会查找并尝试提供这些文件。这里，index.html 和 index.htm 是列出的默认首页文件。

8.4.4error_page

error_page 指令用于定义一组 HTTP 错误代码应该显示的自定义错误页面。在这个例子中，当出现 500（服务器内部错误）、502（网关错误）、503（服务不可用）和 504（网关超时）错误时，Nginx 会显示 /50x.html 这个错误页面。

8.4.5location

这一行开始了一个新的 location 块，它专门用于配置 /50x.html 这个特定文件的请求。= 表示精确匹配，确保只有完全匹配 /50x.html 的请求才会应用这个块里的配置。

8.4.6error_page下的root

为了区别上面的root，我在这里特别写了是error_page下的root，注意不要混淆。

root 指令指定了文件服务的根目录。在这里，html 表示 /50x.html 文件将从 Nginx 配置目录下的 html 子目录中提供。这意味着 Nginx 会从 html 目录中寻找 50x.html 文件并将其发送给客户端。

8.5模块之间的关系和概括

http 模块：

http 模块是 Nginx 配置的第二级模块，它位于 events 和 http 模块之间。
它定义了全局性的 HTTP 相关的配置，如默认的文件根目录、日志路径、缓存设置等。
http 模块可以包含多个 server 模块，每个 server 模块定义了一个虚拟主机的配置。

server 模块：

server 模块是 Nginx 配置的第三级模块，它位于 http 模块之内。
每个 server 模块定义了一个虚拟主机的配置，包括监听端口、服务器名称、安全设置、日志文件位置等。
一个 http 模块可以包含多个 server 模块，每个 server 模块代表一个虚拟主机，可以有不同的域名或IP地址。
server 模块可以包含多个 location 模块，每个 location 模块定义了如何处理请求的特定部分。

location 模块：

location 模块是 Nginx 配置的第四级模块，它位于 server 模块之内。
location 模块定义了 URL 匹配规则和对应的处理配置，如代理设置、静态文件服务、重定向规则等。
一个 server 模块可以包含多个 location 模块，每个 location 模块代表一组 URL 匹配规则。
location 模块可以精确匹配特定的路径，也可以使用正则表达式进行更复杂的匹配。

8.5.1三个模块之间的关系

http 模块是全局性的，它为所有 server 模块提供了一个基础的配置环境。
server 模块继承了 http 模块的配置，并且可以覆盖全局配置，或者添加针对特定虚拟主机的特定配置。
location 模块继承了 server 模块的配置，并且可以进一步细化处理请求的规则。
当一个请求到达 Nginx 时，Nginx 会根据请求的域名和端口（由 server 模块定义）来确定使用哪个虚拟主机配置。
然后，Nginx 会检查该 server 模块中的所有 location 模块，找到与请求 URL 匹配的规则，并应用相应的配置来处理请求。

所以说，你想要创建一个虚拟主机，注意要创建在http的括号内，如果你想创建新的url，记住要在虚拟主机server的括号内。

8.6实验，自己创建一个.conf并且导入到nginx.conf文件中，.conf文件必须包含至少两个网页，可以实现互相跳转

我在zhangsan.conf这个文件中书写了上述的内容并且将其include到了nginx.conf文件内，接下来我们来分析一下我写的zhangsan.conf文件吧

listen:89,我取消了默认的80端口改为89端口，因为会与nginx中的server中的默认的80端口进行冲突，我在主机内添加了网页的编码格式charset utf-8，使之能够识别我的汉字，最后我将longnian.html作为了我的默认网页，而将/usr/local/nginx/html/index2.html作为了我路由的网页，这个网页需要我们手动的去自行的寻找。格式为

localhost本机IP地址:89/新的页面名称.html

在nginx.conf的server中我们不要忘记include zhangsan.conf将配置文件导入，否则都是空谈！

在sbin目录下不要忘记./nginx -t检查文件是否出错，否则都是空谈！

在sbin目录下不要忘记重新让nginx加载./nginx -s reload,否则都是空谈！

做完上述三步我们开始验证：

默认locolhost本机IP，弹出longnian.html页面成功，浏览器继续输入/index2.html弹出第二个页面也成功，实验结束。

9.Nginx日志切割

我们的nginx的日志默认都会保存在

/var/log/nginx（如下图）

保存到这里的原因还是我们之前写的配置文件中的那些内容（如下）

如果是这样的话就会存在一个非常重大的问题：

日志文件如果我们不去动它的话它是只增不减的，所以我们如何去让日志保持在我们都能接受的一个范围内呢？既不会因为长时间不处理影响服务器的性能，也不会因为频繁的处理导致无法恢复？

这就涉及到日志的切割（也叫做日志轮转）了，本质就是我们设置一个关于nginx访问日志和错误日志的定时计划，每到这个时间或者每隔一段时间，linux就会自动执行时间轮转的任务，清除几天前或者几个月前的日志，这样就会保证我们的服务器性能和空间。

如何进行日志切割呢？

结合bash脚本可以完成！只需要设置一个时间节点自动执行bash脚本即可。在这里我给大家写了一个脚本，用于仅保存一周内的nginx脚本（如下）

#!/bin/bash

LOG_PATH="/var/log/nginx/"

RECORD_TIME=$(date --date="yesterday" +%Y-%m-%d_%H:%M)

PID=/var/run/nginx/nginx.pid

# 移动前一天的日志文件
mv "${LOG_PATH}/access.log" "${LOG_PATH}/access.${RECORD_TIME}.log"
mv "${LOG_PATH}/error.log" "${LOG_PATH}/error.${RECORD_TIME}.log"

# 向Nginx主进程发送信号，用于重新打开日志文件
kill -USR1 $(cat $PID)

# 删除7天前的日志文件
find "${LOG_PATH}" -name "access.*.log" -mtime +7 -exec rm -f {} \;
find "${LOG_PATH}" -name "error.*.log" -mtime +7 -exec rm -f {} \;

解释一下上述代码（如下）：

定义日志路径：
LOG_PATH="/var/log/nginx/"
这行代码定义了 Nginx 日志文件的存储路径。
获取昨天的日期和时间：
RECORD_TIME=$(date --date="yesterday" +%Y-%m-%d_%H:%M)
这行代码使用 date 命令获取昨天的日期和时间，格式为 年-月-日_时:分。这个时间戳将用于日志文件的重命名。
定义 Nginx PID 文件路径：
PID=/var/run/nginx/nginx.pid
这行代码指定了 Nginx 主进程 PID 文件的路径。
移动访问日志文件：
mv "${LOG_PATH}/access.log" "${LOG_PATH}/access.${RECORD_TIME}.log"
这行代码将当前的访问日志文件 access.log 重命名为包含昨天日期时间的文件。
移动错误日志文件：
mv "${LOG_PATH}/error.log" "${LOG_PATH}/error.${RECORD_TIME}.log"
这行代码将当前的错误日志文件 error.log 重命名为包含昨天日期时间的文件。
发送信号给 Nginx 以重新打开日志文件：
kill -USR1 $(cat $PID)
这行代码首先读取 PID 文件中的进程 ID，然后向该进程发送 USR1 信号。Nginx 配置为在接收到 USR1 信号时，会重新打开日志文件，这允许新的日志条目写入新的文件，而旧的文件则保持不变。
删除7天前的访问日志文件：
find "${LOG_PATH}" -name "access.*.log" -mtime +7 -exec rm -f {} \;
这行代码使用 find 命令搜索所有名为 access.*.log 的文件（匹配访问日志文件），这些文件的修改时间超过7天（-mtime +7），然后执行 rm -f 命令删除这些文件。
删除7天前的错误日志文件：
find "${LOG_PATH}" -name "error.*.log" -mtime +7 -exec rm -f {} \;
这行代码与上一行类似，但是针对的是错误日志文件 error.*.log。