> 技术文档 > nginx学习

nginx学习


文章目录

  • 0,前置知识
    • 0.1域名分级体系
    • 0.2DNS 域名解析
    • 0.3软负载与硬负载
  • 1,nginx安装(Linux)
  • 2,nginx概述
    • 2.1介绍
    • 2.2应用场景
  • 3,基于nginx配置/使用nginx
    • 3.1存放html静态资源
    • 3.2正向代理&反向代理
    • 3.3负载均衡策略
      • (1)轮询配置
      • (2)权重配置
      • (3)故障转移配置
    • 3.4基于nginx解决跨域问题
    • 3.5动静分离
  • 4,部署项目
  • 配置文件
    • server块
      • listen指令
      • server_name指令
    • location块
      • 示例 1:无标识(标准 URI 匹配)
      • 示例 2:`=`(精确匹配)
      • 示例 3:`^~`(优先匹配,跳过正则)
      • 示例 4:`~`(区分大小写的正则匹配)
      • 示例 5:`~*`(不区分大小写的正则匹配)
    • 了解
      • 全局块
      • events块
      • http块

0,前置知识

0.1域名分级体系

  • 顶级域名(TLD) :域名系统最高级别,位于最右侧。分通用顶级域名(gTLD,如.com、.org、.net )、国家及地区顶级域名(ccTLD,如.cn 、.us 、.uk )。
  • 一级域名(SLD) :紧接顶级域名左侧,是注册者选的名称,对应网站核心主题 / 服务,如example.com里的 example 。
  • 二级域名 :在顶级域名之下,表网站具体内容 / 服务,可建子站点,如www.example.com里的 www ,还有mail.example.com 、blog.example.com这类子站点形式。
  • 三级及更低级别域名 :在二级域名左侧,用于细分域名,如subdomain.example.com里的 subdomain ,实际应用中一般不超四到五级,方便管理和阅读。

0.2DNS 域名解析

DNS(域名系统)是互联网中用于将域名转换为 IP 地址的关键服务,它使得用户可以通过易记的域名(如www.baidu.com)访问服务器,而无需记住复杂的 IP 地址(如188.8.8.8)。

域名解析流程:

当客户端(如浏览器)输入域名访问网站时,解析过程遵循以下步骤:

  1. 查询本地 host 文件(windows:C:\\Windows\\System32\\drivers\\etc linux:/etc/hosts)

    客户端首先检查本地hosts文件,查看是否有该域名与 IP 的对应记录。

    • 若存在记录,直接使用该 IP 地址发起请求;
    • 若不存在,进入下一步。
  2. 向运营商 DNS 服务器请求
    本地无记录时,客户端会向网络运营商(如电信、联通)的 DNS 服务器发送解析请求,由运营商服务器返回对应的 IP 地址。

  3. 建立连接
    客户端获取 IP 后,通过该 IP 地址与服务器建立连接,完成请求与响应。

0.3软负载与硬负载

  • 软负载:基于服务器上的特定软件(如 Nginx)实现负载均衡。
  • 硬负载:基于固定硬件(如 F5)实现负载均衡。

1,nginx安装(Linux)

解压压缩包

将压缩包解压到/usr/local/nginx目录下

tar -zxvf /usr/local/src/nginx-1.25.2.tar.gz -C /usr/local/nginx

执行完下面三步后,Nginx 就被安装到了 /usr/local/nginx,之后可以通过 /usr/local/nginx/sbin/nginx 命令启动 Nginx 服务。

cd /usr/local/nginx/nginx-1.25.2./configure --prefix=/usr/local/nginx # 指定安装目录make && make install

常用命令

进入 Nginx 的 sbin 目录。

cd /usr/local/nginx/sbin 
命令 作用说明 场景举例 ./nginx -v 查看 Nginx 版本信息,确认当前安装的 Nginx 版本 调试环境、排查版本兼容性问题时用 ./nginx -t 检查 Nginx 配置文件语法是否正确,避免因配置错误导致服务启动失败 修改 nginx.conf 后,重启前执行 ./nginx 启动 Nginx 服务,默认加载 conf/nginx.conf 配置文件 初次启动、服务异常停止后重启 ./nginx -s stop 快速停止 Nginx 服务(暴力终止进程,可能丢失未完成的连接 / 操作 ) 紧急故障处理,需快速停服务时 ./nginx -s quit 优雅停止 Nginx 服务(等待当前连接处理完毕后再退出,推荐生产环境用 ) 常规升级、维护时,平稳停服务 ./nginx -s reload 重新加载 Nginx 配置文件(无需重启服务,动态应用新配置 ) 修改配置后,平滑更新规

防火墙相关命令:

# 临时开放80端口(重启防火墙后失效)sudo firewall-cmd --zone=public --add-port=80/tcp# 永久开放80端口(需要重新加载规则)sudo firewall-cmd --zone=public --add-port=80/tcp --permanent# 重新加载防火墙规则,使设置生效sudo firewall-cmd --reload# 验证是否已开放sudo firewall-cmd --zone=public --list-ports | grep 80

2,nginx概述

2.1介绍

定义:高性能的 HTTP 和反向代理 web 服务器,还提供 IMAP/POP3/SMTP 服务,由伊戈尔・赛索耶夫开发,2004 年发布首个公开版本。

特点:稳定性好、功能丰富、配置示例多、系统资源消耗低,并发能力强,百度、京东等知名企业均有使用。

2.2应用场景

  • 反向代理:转发客户端请求到真实服务器,保障真实服务安全。
  • 负载均衡:对集群节点实现负载均衡和故障转移,算法有轮询、权重等。
  • 微服务网关入口:可实现微服务网关集群。
  • 静态服务器:比 Tomcat 性能高,用于存放静态资源,推荐后续存放于 CDN。
  • 保护网站:结合 lua 实现请求限流。

3,基于nginx配置/使用nginx

3.1存放html静态资源

基于 Nginx 存放 Html 静态资源的配置,核心是通过server_name区分不同域名,结合locationroot指令指定静态资源的存放目录,实现 “不同域名对应不同业务静态资源” 的映射。以下是具体配置逻辑和示例:

  1. 按业务拆分域名:为不同业务(如会员、订单)分配独立域名(如member.boyatop.cnorder.boyatop.cn),便于管理和访问。
  2. 指定资源目录:通过root指令设置静态资源的根目录(通常为 Nginx 安装目录下的html文件夹,或自定义路径),index指令指定默认访问的首页文件(如index.html)。
  3. 绑定域名与目录:通过server_name匹配请求的域名,将请求路由到对应的server块,从而访问该块中location指定的静态资源目录。

如果是本地测试,自己瞎编一个域名即可,然后修改对应的hosts文件;如果是公网,则需购买域名。

如果不使用server_name域名,可以使用端口号来区分。

举例:

#访问:http://member.boyatop.cnserver { listen 80; server_name member.boyatop.cn; location / { root html/member; # 根目录为Nginx安装目录下的html/member index index.html; # 默认访问index.html }}----------无域名,端口号区分-------------# 露西亚(使用8081端口)访问:http://ip:8081server { listen 8081; # 监听8081端口,与订单业务区分 location / { root html/luxiya; # 会员静态资源目录 index index.html; }}# 赛琳娜(使用8082端口)访问:http://ip:8082server { listen 8082; # 监听8082端口 location / { root html/selena; # 订单静态资源目录 index index.html; }}

拼接公式root指定的目录 + location匹配的路径 + 请求的文件名

root 和 alias指令

location /img/ { root /var/www/static; # root指定根目录为/var/www/static}

当客户端请求 http://domain.com/img/logo.png 时:

  • location匹配到/img/
  • 最终查找的本地文件路径 = root目录 + location匹配的路径 + 请求的文件名
    /var/www/static + /img/ + logo.png
    → 实际路径:/var/www/static/img/logo.png

拼接公式alias指定的目录 + 请求中location之后的路径 + 文件名

location /img/ { alias /var/www/static/image/; # alias指定目录为/var/www/static/image/(必须带/)}

当客户端请求 http://domain.com/img/logo.png 时:

  • location匹配到/img/,但该路径会被alias替换;
  • 最终查找的本地文件路径 = alias目录 + 请求中location之后的部分(即logo.png
    /var/www/static/image/ + logo.png
    → 实际路径:/var/www/static/image/logo.png

3.2正向代理&反向代理

什么是正向代理?

正向代理 ,是在用户端的 ,比如需要访问某些国外网站 (例如 github) 在相关部门的允许情况下 ,我们可以使用vpn。 并且vpn是在我们的用户浏览器端设置的(并不是在远端的服务器设置)。 客户端将请求发送给正向代理服务器,代理服务器转发请求到目标服务器,再将结果原路返回给客户端。

什么是反向代理?

客户端请求达到Nginx代理服务器,在通过代理服务器转发到真实服务器隐藏服务器端真实的IP信息。

正向代理与反向代理区别:正向代理隐藏用户的真实行为、反向代理隐藏真实 服务器。

反向代理案例:

 # 露西亚(使用8081端口) server { listen 8081; # 监听8081端口,与订单业务区分 location / { root html/luxiya; # 会员静态资源目录 index index.html; } } # 8083端口作为反向代理,转发到8081端口的露西亚服务 server { listen 8083; # 代理端口 location / { # 反向代理到8081端口的露西亚服务 proxy_pass http://127.0.0.1:8081; # 传递必要的请求头信息 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

3.3负载均衡策略

(1)轮询配置

轮询是 Nginx 默认的负载均衡策略,无需额外配置指令即可使用。在 Nginx 配置文件中,通过upstream块定义后端服务器组,Nginx 会自动按时间顺序将请求逐一分配到不同的后端服务器。

http { upstream backend { server backend1.example.com; server backend2.example.com; server backend3.example.com; } server { listen 80; server_name www.example.com; proxy_pass http://backend; }}-----------这里使用不同端口代替----------# 定义后端服务器组,使用轮询策略(默认)upstream backend_servers { server 127.0.0.1:8081; # 露西亚服务 server 127.0.0.1:8082; # 赛琳娜服务 # 可以添加更多服务器,Nginx会自动轮询分发请求 # 当服务器宕机时,Nginx会自动剔除}# 负载均衡入口,监听80端口server { listen 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { # 转发请求到后端服务器组 proxy_pass http://backend_servers; # 传递必要的请求头信息 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }}# 露西亚(使用8081端口)server { listen 8081; # 监听8081端口,与订单业务区分 location / { root html/luxiya; # 会员静态资源目录 index index.html; }}# 赛琳娜(使用8082端口)server { listen 8082; # 监听8082端口 location / { root html/selena; # 订单静态资源目录 index index.html; }}

(2)权重配置

通过为后端服务器设置weight参数来实现权重配置,权重与访问比率成正比,可用于后端服务器性能不均的情况。

http { upstream backend { server backend1.example.com weight=3; server backend2.example.com weight=2; server backend3.example.com weight=1; } server { listen 80; server_name www.example.com; proxy_pass http://backend; }}

(3)故障转移配置

Nginx 可通过配置健康检查等功能实现故障转移,当后端服务器宕机时自动将请求切换到其他正常服务器。

3.4基于nginx解决跨域问题

什么是跨域?

跨域是指在浏览器环境中,当一个网页的源(Origin)(源的格式为:协议://域名:端口) 与它所请求的资源的源不同时,就会产生跨域现象。例如:前端页面部署在 http://localhost:8080,后端 API 部署在 http://localhost:8081,前端调用后端接口时会跨域。

反向代理解决跨域问题

将前端页面和后端接口通过同一域名 / 端口访问,用 Nginx 的location规则转发请求到实际服务。浏览器只关心前端页面与请求的 http://www.example.com/api/getUser 是否同源。Nginx 与后端服务是否同源不影响转发,因为服务器间通信不受浏览器同源策略约束。

前端(文件名nginx-cross-study):

  跨域测试页面   

用户信息

$(function() { $(\"#fetchUser\").click(function() { // 注意:请求路径为Nginx代理后的接口(与页面同域名) $.ajax({ url: \"/api/getUser\", // 由Nginx转发到后端8080端口 type: \"GET\", dataType: \"json\", success: function(data) { $(\"#userInfo\").html(`

ID: ${data.id}

姓名: ${data.name}

信息: ${data.message}

`); }, error: function(xhr) { $(\"#userInfo\").html(\"请求失败:\" + xhr.statusText); } }); }); });

后端:

@RestControllerpublic class UserController { // 后端接口:返回用户信息 @GetMapping(\"/getUser\") public Map getUser() { Map user = new HashMap(); user.put(\"id\", 1); user.put(\"name\", \"LinuxServerUser\"); user.put(\"message\", \"来自后端Java服务的响应\"); return user; }}------------------application.yml----------server: port: 8084 # 后端服务端口 servlet: context-path: / # 根路径

nginx配置:

server { listen 80; server_name localhost; # 替换为你的服务器公网IP或域名 # 前端静态文件(user.html) location / { root html/nginx-study; index nginx-cross-study.html; } # 后端接口代理(/api路径转发到8080端口) location /api/ { # 转发到后端Java服务,去除/api前缀(注意末尾的/) proxy_pass http://127.0.0.1:8084/; # 传递请求头 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}

3.5动静分离

在Web开发中,通常来说,动态资源其实就是指那些后台资源,而静态资源就是指HTML,JavaScript,CSS,img等文件。

动静分离,说白了,就是将网站静态资源(HTML,JavaScript,CSS,img等文件)与后台应用分开部署,提高用户访问静态代码的速度,降低对后台应用服务器的请求。后台应用服务器只负责动态数据请求。

优势:分担负载,减轻web服务器的压力,适用于大负载。静态资源放置cdn,同时还可以通过配置缓存到客户浏览器中,这样极大减轻web服务器的压力。

劣势:网络环境不佳时,ajax回应很慢,导致页面出现空白,出错处理会不好看。不利于网站SEO(搜索引擎优化),增加了开发复杂度。

4,部署项目

部署一个若依项目。

流程:

1,打包前后端

#后端打jar包(可使用命令,也可以使用生命周期中的install)mvn clean package#前端打包(dist文件)进入前端目录文件下执行命令npm run build:prod

2,放置后端文件,并运行

**后端:**将打包后的jar包放到一个位置,我这里放到了/java-project(自定义建的)目录下。

运行:

#前台运行(xxx.jar指的你的jar包名)java -jar xxx.jar#后台运行nohup java -jar xxx.jar &#这样执行后,nohup会把执行结果中的日志输出到当前文件夹下面的nohup.out文件中,通常情况下我们使用以上命令即可。 #我们也可以手动指定一个参数来规定日志文件的输出地点,如:nohup java -jar xxx.jar > catalina.out 2>&1 &

3,放置前端文件

将打包后的dist文件夹下的所有文件放到nginx的html目录下,可以在html目录下自建一个文件夹,也可以放到别的地方。配置nginx配置文件的时候更改相关配置即可。我这里放到了/usr/local/nginx/html/nginx-study目录下。

4,配置nginx.conf

server { listen 80; server_name 49.232.7.34; # 替换为你的服务器公网IP或域名 # 前端 - 主配置 location / { root html/nginx-study; index index.html; try_files $uri $uri/ /index.html; } # 后端API代理(前端向后端请求时会携带prod-api) location /prod-api/ { proxy_pass http://127.0.0.1:8079/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}--------------对应的项目配置------------# 开发环境配置server: # 服务器的HTTP端口,默认为8080 port: 8079 servlet: # 应用的访问路径 context-path: /

5,其他环境

  • 确保mysql是线上数据库并已启动
  • redis线上且已经启动

try_files $uri $uri/ /index.html含义

  1. $uri
  • 含义:Nginx 的内置变量,代表当前请求的 “统一资源标识符”(不包含查询参数),即客户端实际请求的路径对应的文件。
  • 举例
    • 若用户访问 http://域名/about$uri 就是 /about,Nginx 会尝试查找服务器上对应路径的文件(如 root 目录下的 about 文件)。
    • 若用户访问 http://域名/js/app.js$uri 就是 /js/app.js,Nginx 会尝试查找 root/js/app.js 文件。
  1. $uri/
  • 含义:在当前请求的 URI 后追加一个斜杠,代表将请求视为 “目录”,尝试访问该目录下的默认首页(由 index 指令定义,通常是 index.html)。
  • 举例
    • 若用户访问 http://域名/about$uri/ 就是 /about/,Nginx 会尝试查找 root/about/ 目录,并加载该目录下的 index.html(如果存在)。
    • 若用户访问 http://域名/docs$uri/ 就是 /docs/,Nginx 会尝试查找 root/docs/index.html 文件。
  1. /index.html
  • 含义:当 $uri$uri/ 对应的文件 / 目录都不存在时,Nginx 会默认返回网站根目录下的 index.html 文件。

  • 作用:这是为单页应用(如 Vue、React)设计的关键配置,确保前端路由(如 http://域名/user/123)在刷新页面时不会出现 404 错误 —— 因为前端框架会通过自身的路由机制解析 /index.html 并渲染对应的页面。

  • 举例

    若用户访问 http://域名/user/123,而服务器上没有 user/123 文件或目录,Nginx 会直接返回 root/index.html,由前端框架处理 /user/123 这个路由。

在这里,当你刷新页面时,Nginx 会根据 try_files $uri $uri/ /index.html 规则,最终返回 html/nginx-study 目录下的 index.html 文件

配置文件

Nginx配置文件详解 - 程序员自由之路 - 博客园

Nginx的主配置文件是nginx.conf,这个配置文件一共由三部分组成,分别为全局块、events块和http块。在http块中,又包含http全局块、多个server块。每个server块中,可以包含server全局块和多个location块。在同一配置块中嵌套的配置块,各个之间不存在次序关系。

一般情况下,高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现,则采用“就近原则”,即以较低层级块中的配置为准。

#全局块#user nobody;worker_processes 1;#event块events { worker_connections 1024;}#http块http { #http全局块 include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; #server块 server { #server全局块 listen 8000; server_name localhost; #location块 location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } #这边可以有多个server块 server { ... }}

server块

listen指令

server块中最重要的指令就是listen指令,这个指令有三种配置语法。这个指令默认的配置值是:listen *:80 | *:8000;只能在server块种配置这个指令。

listen指令的配置非常灵活,可以单独制定ip,单独指定端口或者同时指定ip和端口。

listen 127.0.0.1:8000; #只监听来自127.0.0.1这个IP,请求8000端口的请求listen 127.0.0.1; #只监听来自127.0.0.1这个IP,请求80端口的请求(不指定端口,默认80)listen 8000; #监听来自所有IP,请求8000端口的请求listen *:8000; #和上面效果一样listen localhost:8000; #和第一种效果一致

server_name指令

对于name 来说,可以只有一个名称,也可以由多个名称并列,之间用空格隔开。每个名字就是一个域名,由两段或者三段组成,之间由点号“.”隔开。比如

server_name myserver.com www.myserver.com

location块

location 块是 Nginx 配置中用于精准匹配请求路径并处理对应请求的核心模块,主要作用如下:

  1. 路径匹配与请求分发
    根据客户端请求的 URI(如/api/user/static/image.jpg),通过不同的匹配规则(精确匹配、正则匹配等),将请求路由到对应的处理逻辑。例如:
    • 把静态资源请求(.js.png)转发到静态文件目录;
    • 把 API 请求(/api/*)代理到后端服务;
    • 把特定路径(/admin)限制访问权限。
  2. 功能定制与差异化处理
    在匹配到特定路径后,可配置针对性的功能:
    • 设置缓存策略(expires):对图片、CSS 等静态资源设置长缓存;
    • 配置反向代理(proxy_pass):将/api请求转发到后端 API 服务器;
    • 实现地址重定向(rewrite):将/old重定向到/new
    • 限制访问(deny/allow):禁止外部 IP 访问/admin路径。

示例 1:无标识(标准 URI 匹配)

server { server_name www.example.com; # 无标识,匹配以/member开头的请求 location /member { echo \"匹配/member及子路径\"; } # 无标识,匹配以/member/login开头的请求 location /member/login { echo \"匹配/member/login及子路径\"; }}
  • 访问http://www.example.com/member:匹配第一个location(匹配度低,但无更精确的正则匹配时生效)。
  • 访问http://www.example.com/member/login:匹配第二个location(匹配度更高)。

示例 2:=(精确匹配)

server { server_name www.example.com; # 精确匹配/member,不匹配/member/或/member?param location = /member { echo \"精确匹配/member\"; } # 无标识,匹配以/member开头的请求 location /member { echo \"匹配/member及子路径\"; }}
  • 访问http://www.example.com/member:触发第一个location(精确匹配,立即停止搜索)。
  • 访问http://www.example.com/member/:触发第二个location(非精确匹配,进入模糊匹配)。

示例 3:^~(优先匹配,跳过正则)

server { server_name www.example.com; # ^~标识,匹配以/static开头的请求,且不执行后续正则匹配 location ^~ /static { echo \"匹配/static及子路径,不检查正则\"; } # 正则匹配,以.jpg结尾的请求(但会被^~拦截) location ~* \\.jpg$ { echo \"匹配.jpg结尾的请求\"; }}
  • 访问http://www.example.com/static/1.jpg:触发第一个location^~优先匹配,跳过正则检查)。
  • 访问http://www.example.com/images/1.jpg:触发第二个location(无^~拦截,正则匹配生效)。

示例 4:~(区分大小写的正则匹配)

server { server_name www.example.com; # ~标识,区分大小写,匹配以.PHP结尾的请求 location ~ \\.PHP$ { echo \"匹配.PHP结尾(区分大小写)\"; }}
  • 访问http://www.example.com/test.PHP:匹配成功(大小写严格一致)。
  • 访问http://www.example.com/test.php:匹配失败(小写.php 不匹配大写.PHP)。

示例 5:~*(不区分大小写的正则匹配)

server { server_name www.example.com; # ~*标识,不区分大小写,匹配以.php结尾的请求 location ~* \\.php$ { echo \"匹配.php结尾(不区分大小写)\"; }}
  • 访问http://www.example.com/test.phphttp://www.example.com/test.PHP:均匹配成功(忽略大小写)。

匹配优先级总结

从高到低:=(精确匹配) > ^~(优先匹配) > ~/~*(正则匹配,按配置顺序) > 无标识(标准 URI 模糊匹配,按匹配度)。

了解

全局块

全局块是默认配置文件从开始到events块之间的一部分内容,主要设置一些影响Nginx服务器整体运行的配置指令,因此,这些指令的作用域是Nginx服务器全局。

通常包括配置运行Nginx服务器的用户(组)、允许生成的worker process数、Nginx进程PID存放路径、日志的存放路径和类型以及配置文件引入等。

# 指定可以运行nginx服务的用户和用户组,只能在全局块配置# user [user] [group]# 将user指令注释掉,或者配置成nobody的话所有用户都可以运行# user nobody nobody;# user指令在Windows上不生效,如果你制定具体用户和用户组会报小面警告# nginx: [warn] \"user\" is not supported, ignored in D:\\software\\nginx-1.18.0/conf/nginx.conf:2# 指定工作线程数,可以制定具体的进程数,也可使用自动模式,这个指令只能在全局块配置# worker_processes number | auto;# 列子:指定4个工作线程,这种情况下会生成一个master进程和4个worker进程# worker_processes 4;# 指定pid文件存放的路径,这个指令只能在全局块配置# pid logs/nginx.pid;# 指定错误日志的路径和日志级别,此指令可以在全局块、http块、server块以及location块中配置。# 其中debug级别的日志需要编译时使用--with-debug开启debug开关# error_log [path] [debug | info | notice | warn | error | crit | alert | emerg] # error_log logs/error.log notice;# error_log logs/error.log info;

events块

这一部分的指令对Nginx服务器的性能影响较大,在实际配置中应该根据实际情况灵活调整。

# 设置允许每一个worker process同时开启的最大连接数,当每个工作进程接受的连接数超过这个值时将不再接收连接# 当所有的工作进程都接收满时,连接进入logback,logback满后连接被拒绝# 只能在events块中进行配置# 注意:这个值不能超过超过系统支持打开的最大文件数,也不能超过单个进程支持打开的最大文件数# worker_connections 1024;

http块

http块是Nginx服务器配置中的重要部分,代理、缓存和日志定义等绝大多数的功能和第三方模块的配置都可以放在这个模块中。

可以在http全局块中配置的指令包括文件引入、MIME-Type定义、日志自定义、是否使用sendfile传输文件、连接超时时间、单连接请求数上限等。

# include指令,用于包含其他的配置文件,可以放在配置文件的任何地方,但是要注意你包含进来的配置文件一定符合配置规范,比如说你include进来的配置是worker_processes指令的配置,而你将这个指令包含到了http块中,着肯定是不行的,上面已经介绍过worker_processes指令只能在全局块中。# 下面的指令将mime.types包含进来,mime.types和ngin.cfg同级目录,不同级的话需要指定具体路径# include mime.types;-------------------------------------------------------------------# 配置默认类型,如果不加此指令,默认值为text/plain。# 此指令还可以在http块、server块或者location块中进行配置。# default_type application/octet-stream;-------------------------------------------------------------------#access_log:access_log 记录的是 Nginx 服务器在处理前端(如浏览器、客户端)请求过程中产生的日志,包含请求来源、请求内容、响应状态等关键信息,用于追踪用户行为、排查请求异常等。# log_format指令,用于定义日志格式,此指令只能在http块中进行配置-------------------------------------------------------------------# 开启关闭sendfile方式传输文件,可以在http块、server块或者location块中进行配置# sendfile on | off;# 设置sendfile最大数据量,此指令可以在http块、server块或location块中配置# sendfile_max_chunk size;# 其中,size值如果大于0,Nginx进程的每个worker process每次调用sendfile()传输的数据量最大不能超过这个值(这里是128k,所以每次不能超过128k);如果设置为0,则无限制。默认值为0。# sendfile_max_chunk 128k;-------------------------------------------------------------------# 配置连接超时时间,此指令可以在http块、server块或location块中配置。# 与用户建立会话连接后,Nginx服务器可以保持这些连接打开一段时间# timeout,服务器端对连接的保持时间。默认值为75s;header_timeout,可选项,在应答报文头部的Keep-Alive域设置超时时间:“Keep-Alive:timeout= header_timeout”。报文中的这个指令可以被Mozilla或者Konqueror(浏览器)识别。# keepalive_timeout timeout [header_timeout]# 下面配置的含义是,在服务器端保持连接的时间设置为120 s,发给用户端的应答报文头部中Keep-Alive域的超时时间设置为100 s。# keepalive_timeout 120s 100s服务器实际保持连接的时间为 120 秒;同时会在应答报文中告诉客户端:“建议你 100 秒内发送新请求,否则我可能关闭连接”。这种连接适用于客户端需多次请求资源的场景(如网页包含多个图片、CSS 文件),可提升访问效率。

default_type

  1. 定义默认资源类型
    MIME 类型是网络资源的媒体类型(如 text/html 对应 HTML 文件、image/jpeg 对应 JPG 图片),浏览器通过 MIME 类型识别资源并正确解析。当 Nginx 无法识别请求资源的具体类型(即未在 mime.types 文件中匹配到对应类型)时,会使用该指令指定的默认类型。
  2. 默认值与场景
    • 若不配置此指令,Nginx 默认值为 text/plain(纯文本类型)。
    • 设置为 application/octet-stream 时,浏览器会将无法识别的资源视为二进制流,通常会触发 “下载” 行为(而非直接解析显示)。例如,对于未知后缀的文件(如 .dat),浏览器会提示下载而非尝试渲染。

access_log

假设定义了如下日志格式:

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;

当用户通过浏览器访问 http://www.example.com/index.html 时,access_log 会生成一条类似如下的日志:

192.168.1.100 - - [10/Jul/2025:14:30:00 +0800] \"GET /index.html HTTP/1.1\" 200 1500 \"http://www.baidu.com\" \"Mozil

含义拆解:

  • 192.168.1.100:客户端 IP 地址($remote_addr)。
  • -:远程用户($remote_user),未登录时为 -
  • [10/Jul/2025:14:30:00 +0800]:请求时间($time_local)。
  • \"GET /index.html HTTP/1.1\":请求方法、路径、协议($request)。
  • 200:响应状态码($status,200 表示请求成功)。
  • 1500:响应数据大小($body_bytes_sent,单位字节)。
  • \"http://www.baidu.com\":请求来源页面($http_referer,即用户从百度跳转而来)。
  • \"Mozilla/5.0 ... Chrome/114.0.0.0\":客户端浏览器信息($http_user_agent)。
  • \"-\":代理 IP($http_x_forwarded_for,无代理时为 -)。

sendfile

endfile 是一种 高效的文件传输机制,由操作系统提供,用于在两个文件描述符之间直接传输数据(如从磁盘文件到网络套接字),无需经过用户空间缓冲区,从而减少数据复制和上下文切换,显著提升文件传输效率。

在 Nginx 中,sendfile on; 指令用于开启这种传输模式,主要作用如下:

  1. 减少数据拷贝次数
    传统文件传输流程:磁盘 → 内核缓冲区 → 用户空间(Nginx 进程)→ 内核网络缓冲区 → 网络。
    开启 sendfile 后:磁盘 → 内核缓冲区 → 内核网络缓冲区 → 网络(跳过用户空间,减少 2 次拷贝)。
  2. 提升静态资源传输性能
    对于 HTML、CSS、JS、图片等静态文件,sendfile 能大幅降低 CPU 占用率,提高 Nginx 处理并发请求的能力,尤其适合高流量的静态资源服务器。
  3. 配合 sendfile_max_chunk 控制传输量
    sendfile_max_chunk 128k; 时,每个 worker 进程每次调用 sendfile() 传输的数据量不超过 128KB,避免单个大文件传输占用过多系统资源,保证其他请求的响应速度。

keepalive_timeout timeout

这里的 “连接” 指的是 客户端(如浏览器)与 Nginx 服务器之间建立的 TCP 长连接(Keep-Alive 连接)

正常情况下,HTTP 协议是 “短连接”:客户端每次请求资源后,连接会被关闭。而开启长连接后,客户端与服务器在一次连接中可完成多次请求 / 响应交互,无需频繁建立和关闭连接,减少网络开销。

keepalive_timeout 配置的就是这种长连接的保持时间