nginx配置静态资源,nginx配置静态资源文件夹

目录：

• 1、nginx 在前端中的简单应用
• 2、不容错过的Nginx配置详解，一文带你搞懂Nginx
• 3、初识Nginx配置文件以及基本命令
• 4、基于Nginx设置浏览器协商缓存过程详解
• 5、详解nginx如何代理静态资源(长搜索路径优先)
• 6、【NGINX入门】3.Nginx的缓存服务器proxy_cache配置

nginx 在前端中的简单应用

Web 服务实际上又称静态资源服务，自从前后端分离后，前端的输出趋向于静态资源的形式，什么是静态资源：就是我们通常用webpack构建输出的结果，比如：

而为了提供文件在互联网中的可访问性，前端还是需要依赖 静态资源服务 ；最常用的做法就是Node服务和Nginx服务。

Node服务最常见的，就是WebpackServer, 在前端开发联调时经常用到, 启动后我们就可以通过 的形式来访问构建资源；除此之外，我给大家安利另一款Node服务库： serve , 它也能快速启动一个静态资源服务。

但在生产环境，我们一般用Nginx来处理，不是Node不好，而是Nginx已经够好了。通常整个大前端会有很多前端项目，我们都将构建结果放在一台服务器上（一般有备份机器）的某个文件夹下,然后通过安装Nginx来创建一个静态资源服务供所有前端资源的访问；比如文件夹static下有A，B，C，D四个前端项目资源, 我们通过nginx配置:

我们即可通过 访问A项目，通过 访问C项目, 从而做到一鸡多吃，这种玩法在HTTPS与HTTP2的时代特别常见。

以上就是Nginx作为Web服务的简单用法，接下来我们了解一下反向代理服务

作为一个开发者，可能经常听到 代理 两字，但很多人区分不清楚正向和反向的区别：

如上图左侧所示，正向代理是用户的主动行为，如我们fq时访问goggle所做的；右侧反向代理是我们访问的服务器行为，作为用户的我们是不能控制也无需关注的。

反向代理在服务部署中，是一种非常常见的技术，比如负载均衡、容灾、缓存。

而对于前端开发来说，反向代理多用于请求转发，来处理 跨域 问题。当我们把前端静态资源服务都指向一个域名（static.closertb.site）时，与服务端请求域名（server.closertb.site）不一致，就会造成跨域。如果服务端不配合的话，那通过nginx，前端也是可以轻松做到的，在前面的配置上，我们添加：

所以当网页发出一个请求： 时，实际请求地址是： ，这就简单实现了一个服务代理。其原理与WebpackServer的proxy相似.

以上就是Nginx的web服务和代理服务在前端开发中的两个典型使用场景, 接下来我们说点零碎又有用的

当请求 )时，将会返回服务器上的/home/static/static/a/logo.png文件，即'/home/static'+'/static/a/logo.png',其 拼接的地址是匹配字符串及其以后的

而对于alias：

当请求 )时，将会返回服务器上的/home/static/a/logo.png文件，即'/home/static'+'/a/logo.png',其 拼接的地址是除了匹配字符串以后的地址

你可能见过A这种：

也可能见过B这种

有什么区别？

两者与root 和 alias有相似之处，只不过这种差别，只适用于：

所以当收到一个请求： ) 时，配置A将会把请求代理到： ); 配置B将会把请求代理到： )

这个知识，在代理配置中真的相当重要

当我们下架一个前端服务，或者用户访问了某个根本不存在的页面，我们不希望用户看到的是404，而是将其引导到一个模糊正确的页面，这时候我可以用rewrite服务；反手一个配置，直接就将流量打到了网站首页;

另一个比较常用的，就是网站开启https，我们需要将所有http请求重定向到https：

上面同是rewrite，但还是有不一样的 ，一个是redirect（302）, 另一个是permanent（301），这两个还是有很大区别的；

web 性能优化是前端的一门学问，好的静态资源加载速度，会显著提升用户体验，而nginx作为最常用的静态资源服务器，也是有诸多渠道来帮助我们来提升静态资源加载速度，简单来讲，可以三个方面，直接上配置：

``if ( ) {

expires 365d;

add_header Cache-Control max-age=31536000;

}/pre

expires与max-age两种配置方式都可以达到告诉浏览器资源一年以后过期的目的，更多关于http缓存的可以 看这一篇文章 ；

不容错过的Nginx配置详解，一文带你搞懂Nginx

Nginx是一个高性能的HTTP和反向代理服务器，特点是占用内存少，并发能力强，事实上Nginx的并发能力确实在同类型的网页服务器中表现好。Nginx专为性能优化而开发，性能是其最重要的考量，实现上非常注重效率，能经受高负载的考验，有报告表明能支持高达50000个并发连接数。

需要客户自己在浏览器配置代理服务器地址。

例如：在大陆访问，我们需要一个代理服务器，我们通过代理服务器去访问谷歌，这个过程就是正向代理。

反向代理，客户端对代理是无感知的，因为客户端不需要任何配置就可以访问，我们只需要将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，在返回给客户端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址。

单个服务器解决不了，我们增加服务器的数量，然后将请求分发到各个服务器上，将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上，将负载分发到不同的服务器，也就是我们说的负载均衡。

为了加快网站的解析速度，可以把动态页面和静态页面由不同的服务器来解析，加快解析速度。降低原来单个服务器的压力。

进入到下面的目录，然后使用命令

配置文件所在位置：/usr/local/nginx/conf/nginx.conf

由全局块+events块+http块组成

从配置文件开始到events之间的内容，主要会设置一些影响Nginx服务器整体运行的配置指令，主要包括配置运行Nginx服务器的用户（组）、允许生成的worker process数，进程pid存放路径、日志存放路径和类型以及配置文件的引入等。

events块设计的指令主要影响Nginx服务器与用户的网络连接，常用的设置包括是否开启对多work process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个work process可以同时支持的最大连接数等。下面的例子表示每个work process支持的最大连接数为1024。这部分配置对Nginx的性能影响较大，在实际中应该灵活配置。

Nginx服务器配置中最频繁的部分，代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里，http块又包括http全局块和server块。

http全局块配置的指令包括文件引入、MIME-TYPE定义、日志自定义、连接超时时间、单链接请求数上限等。

这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。

每个http块可以包括多个server块，而每个server块就相当于一个虚拟主机。

每个server块也可以分为全局server块，以及可以同时包含多个location块。

最常见的配置时本虚拟主机的监听配置和本虚拟主机的名称或IP配置。

一个server块可以配置多个location块。

这块的主要作用是基于Nginx服务器接收到的请求字符串（例如server_name/uri-string），对虚拟主机名称（也可以是IP别名）之外的字符串（例如前面的/uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。

访问，访问到的是Tomcat的主页面。

Nginx+JDK8+Tomcat

访问：，看到的是Tomcat的首页。

根据访问的路径跳转到不同的服务器中去。

访问 直接跳到

访问 直接跳到

Nginx+JDK8+配置两个Tomcat，Tomcat的配置不再讲述。

访问跳到了页面。

访问跳到了页面。

假如Nginx代理服务器Server的配置为：192.168.71.167:9001，跳到：127.0.0.1:8080，访问者的IP为：192.168.71.200:20604。

通过访问，实现负载均衡的效果，平均分摊到8080和8081端口中。

Nginx+JDK8+2台Tomcat，一台8080，一台8081。

访问：，8080和8081交替访问。

1 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2 weight

weight代表权重，默认为1，权重越高被分配的客户端越多。

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

3 ip_hash

每个请求按访问IP的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题，示例如下：

4 fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

访问图片：

访问页面：

访问目录：（因为设置了autoindex on;）

两台机器，每台机器都装有keepalived+Nginx+Tomcat。

主备keepalived服务器中只有master一台机器会出现VIP地址，否则会出现脑裂问题。

【提示】脚本要加+x的执行权限：chmod +x chk_nginx.sh

在Nginx里把虚拟IP配置进去即可。

一个Nginx是由一个master进程和多个worker进程组成的。

客户端发送请求到Master，然后给worker，再由这些work争抢处理这个请求。

1 可以使用nginx -s reload进行热部署方式；

2 每个worker是独立的进程，如果有其中的一个worker出现了问题，其他worker独立的继续进行争抢，实现请求的过程，不会造成服务的中断；

Nginx和Redis类似，都采用了io多路复用机制。每个worker进程都可以把CPU发挥到极致，一般来说worker数和服务器的CPU数相等是最为适宜的。

发送请求：访问静态资源占用2个连接，反向代理占用4个连接。

【温馨提示】

初识Nginx配置文件以及基本命令

配置文件名为 nginx.conf ，Linux放在目录： /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中；Windows放在 安装目录\conf 中。 依据实际安装情况决定

nginx由配置文件中指定的指令控制模块组成。 指令分为 简单指令 和 块指令 ：

简单指令 由空格分隔的名称和参数组成，并以分号 ; 结尾；

块指令 具有与简单指令相同的结构，但是是以大括号 { 和 } 包围的一组附加指令。 如果块指令在大括号内部有其他指令，则称为上下文(例如： events ， http ， server 和 location )；

配置文件中放置在任何上下文之外的伪指令都被认为是主上下文。 events 和 http 指令驻留在主上下文中， server 在 http 中的，而 location 在 server 块中。一个配置文件一个 http ，一个及以上个 server ，一个 server 运行一个工作进程并代表一个虚拟服务器；

# 号所在的一行被视为注释；

几个顶级指令将适用于不同流量类型的指令组合在一起：

对于大多数指令，在子上下文中定义的上下文将继承父级中包含的伪指令的值，要覆盖从父进程继承的值，子上下文中需要包含该指令（即子上下文要显式声明）。

打开配置文件(如 /usr/local/nginx/conf/nginx.conf )，默认的配置文件已经包含了服务器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的服务器块：

每个 server 上下文都可以指定要监听的端口、server_name，当nginx决定哪个服务器处理请求后，它会根据服务器块内部定义的location指令的参数测试请求头中指定的URI， 比如如下配置，系统中创建 /data 目录及其子目录 /www ：

第一个 location 块指定与请求中的URI比较 / 前缀。 对于匹配请求，URI将被添加到 root 指令中指定的路径(即 /data/www )，形成本地文件系统中的请求文件路径。 如果有几个匹配的location块，nginx将选择具有最长前缀来匹配location块。 上面第一个 location 块提供最短的前缀长度为1，因此只有当所有其他location块不能提供匹配时，才会使用该块。第二个 location ,将是以 /images/ 的请求来匹配，位置 / 也匹配这样的请求，但具有较短前缀，也就是 /images/ 比 / 长。

这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的服务器 的工作配置， 端口 80 和 server_name localhost 可以省略，它们为默认值 。 响应以/images/开头的URI的请求，服务器将从 /data/images 目录发送文件。 例如，响应 请求，nginx将发送服务上的 /data/images/logo.png 文件。 如果文件不存在，nginx将发送一个指示 404 错误的响应。 不以 /images/ 开头的URI的请求将映射到 /data/www 目录。 例如，响应 请求时，nginx将发送 /data/www/about/example.html 文件。

反向代理应该是Nginx做的最多的一件事了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。

通过向nginx配置文件添加一个server块来定义代理服务器，其中包含以下内容：

这将是一个监听端口 8080 的简单服务器，并将所有请求映射到本地文件系统上的 /data/up1 目录。 请注意，root指令位于server块上下文中，当选择用于服务请求的 location 块不包含自己的 root 指令时，将使用此root指令。创建 /data/up1 目录然后可以将一个静态网页比如 index.html 文件放入其中，然后访问 即可访问该文件。

目前为止，还是配置的静态资源访问，并不是代理服务器，然后增加或修改现有 location 上下文，改为如下：

当用户访问 时，会返回 服务器的的资源。

location 上下文后面的参数，可以是正则表达式，如果是正则表达式，前面要加 ~ ，比如：

以上配置表示，nginx接收到所有以.gif，.jpg或.png结尾的URI，相应的请求将映射到/data/images目录。当nginx选择一个location块来提供请求时，它首先检查指定前缀的location指令，记住具有最长前缀的location，然后检查正则表达式。 如果与正则表达式匹配，nginx会选择此location，否则选择之前记住的那一个。

要找到最符合URI的位置，NGINX首先将URI与前缀字符串的位置进行比较。然后用正则表达式搜索位置。除非使用^~修饰符对正则表达式给予更高的优先级。在前缀字符串中，NGINX选择最具体的字符串(也就是最长和最完整的字符串)。 下面给出了选择处理请求的位置的确切逻辑：

测试所有URI的前缀字符串。 = (等号)修饰符定义了URI和前缀字符串完全匹配。如果找到完全匹配，则搜索停止。如果 ^~ (插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。存储最长匹配的前缀字符串。根据正则表达式测试URI。断开第一个匹配的正则表达式并使用相应的位置。如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。

= 修饰符的典型用例是 / (正斜杠)的请求。 如果请求/是频繁的，则指定 = / 作为location指令的参数加速处理，因为搜索匹配在第一次比较之后停止。

要启动nginx，请运行可执行文件。 当nginx启动后，可以通过使用-s参数调用可执行文件来控制它。 使用以下语法：

信号(signal)的值可能是以下之一：

当主进程收到要重新加载配置的信号，它将检查新配置文件的语法有效性，并尝试应用其中提供的配置。 如果这是成功的，主进程将启动新的工作进程，并向旧的工作进程发送消息，请求它们关闭。 否则，主进程回滚更改，并继续使用旧配置。 老工作进程，接收关闭命令，停止接受新连接，并继续维护当前请求，直到所有这些请求得到维护。 之后，旧的工作进程退出。

两者在 location 中，指定一个路径，其中使用 alias 做如下配置：

若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件

若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。alias是一个目录别名的定义，root则是最上层目录的定义，指的是 /var/www/image/img/ 。还有一个重要的区别是alias后面必须要 / 结束，否则会找不到文件，而root则可有可无。

另外对于index，含义如下

这样，当用户请求 / 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到 /index.html ；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块。

参考地址1

参考地址2:B站

基于Nginx设置浏览器协商缓存过程详解

一、强缓存与协商缓存的区别

强缓存：浏览器不与服务端协商直接取浏览器缓存

协商缓存：浏览器会先向服务器确认资源的有效性后才决定是从缓存中取资源还是重新获取资源

二、协商缓存运作原理

现在有一个这样的业务情景：后端的静态资源会不定时地发生更新，而因为浏览器默认使用强缓存，会默认从浏览器缓存中取到过时的资源。

现在我们希望浏览器每次获取资源的时候都向后端确认资源是否更新，就要设置浏览器使用协商缓存

那么后端如何判断资源是否更新了呢？这时就要用到Etag和Last-Modified两项响应头。

每次收到一个静态资源的请求时，后端都将资源的最后修改时间（Last-Modified）、根据资源内容计算出来的Etag放在响应头给前端。

前端收到响应后将这两项缓存起来，然后在下次请求同样资源的时候，将这两项的内容放到If-Modified-Since和If-None-Match这两项请求头中。

服务端收到这两项后，会与资源当前生成的Etag和Last-Modified做比较，如果两者都一致，说明资源没有更新，服务端会返回304空响应；否则，说明资源有更新，服务端会将完整的资源内容返回

实现

那么如何实现这样一个复杂的过程呢？其实很简单，只要使用nginx作为静态资源的服务器，再在响应头加上Cache-Control:no-cache就可以了。

下面来分步骤实现一下

1. 使用nginx作为静态资源的服务器

在nginx的配置中，将对静态资源的请求映射到资源的磁盘路径上

http {

  server {

  listen 80;

  ...

  location /picture/ {

    alias D:/luozixi/tcp_test/picture/;

    # alias是重定义路径

    # 比如访问127.0.0.1/picture/1_new.gif，则会映射为访问D:/luozixi/tcp_test/picture/1_new.gif

    # web应用根本不会收到请求，picture的请求都被nginx处理了

    # alias是替换，root是拼接

    autoindex on;

    }

  }

}

2. 重新加载nginx配置

3. 此时，请求静态资源的时候nginx会自动在response头中加上Etag和Last-Modified两项

4. 但是这时发现，如果不配置Cache-Contrl: no-cache，浏览器在下次请求这个资源的时候不会将请求发向后端，而是直接从缓存中获取资源

5. 在nginx中配置

location /picture/ {

  add_header Cache-Control no-cache;

  alias D:/luozixi/tcp_test/picture/;

}

6.清除浏览器缓存后第一次发起请求，会得到一个正常的200 Response，而且响应头里已经有了Cache-Control: no-cache，表示使用协商缓存

7.再次发起请求后，会发现请求头已经带上了If-Modified-Since和If-None-Match两项

8.服务端（nginx）收到这两项后，会与资源当前生成的Etag和Last-Modified做比较，如果两者都一致，说明资源没有更新，服务端会返回304空响应；否则，说明资源有更新，服务端会将完整的资源内容返回

另外，服务器验证If-Modified-Since的方式只是简单的字符串比较，即使资源的Last-Modified比If-Modified-Since要早，服务端仍认为资源有更新

9.浏览器在收到304响应后，会从浏览器缓存中取资源。因此速度非常块

三、no-cache与no-store的区别

no-cache表示不缓存过期资源，缓存会向服务器进行有效处理确认之后处理资源

而no-store才是真正的不进行缓存。

详解nginx如何代理静态资源(长搜索路径优先)

web服务器重要的的任务之一就是服务静态资源文件，比如网站的图片，还有一些静态的HTML页面，本文的例子还是来自于Nginx官网。在这个用例中我们要配置两个静态资源路径，来处理外部的静态资源请求。我们会更改配置文件中，server块下http下的location。

首先需要创建/data/www目录，然后将index.html文件，文件的内容并不重要，本例只是指引我们观察nginx如何找到和发送静态资源。然后在创建一个/data/images目录，并放置一些图片文件。

下一步打开配置文件，默认的配置文件中已经包含了一些server块，大多数已经注释掉了，官网让我们把server块都注释掉，重写写一个新的空的server块，但注意，一定不要将http注释掉，nginx通过识别它才能知道我们需要处理的是http请求。

通常，配置文件可能会包含多个server块，这些server块可以由端口号区分，也可以由server names来区分。当nginx决定由哪一个server去处理请求的时候，nginx会根据server块中location参数去测试请求头中指定的URI

现在在server块中添加location块

该location块指定了URI请求的根目录前缀，"/"。对于请求来讲，URI被添加在root路径具体指向的目标路径，如果存在的多个匹配的位置块，nginx将选择前缀最长的位置块（可能是因为更加具体）。上方的location块提供的已经是最短前缀了，也就是说，server块中所有的location块如果都没有匹配到，则该location块将会被采用。

官网的说法真的非常绕，我觉得思路就是， nginx首先会优先去具体的location块匹配资源（规则是参数越长，越优先查找），如果都查不到就去根路径查。

我们再加一个location块

这个location块会匹配以/images/开始的请求，但上一个(location块 location / 也会匹配该内容，记得吗，Nginx会先匹配长路径location块)

现在为了看的更加清楚，在加过这两部分内容之后的配置文件应该长这样

重新加载nginx之后，配置会更新，使用：

现在该配置文件已经生效了，配置在监听80端口的本地服务器上，我们可以在本地访问 ，在此之后例如 这样的请求， Nginx会映射到location /images/去，如果请求的资源不存在，Nginx将返回404页面，404页面是可以定制的，一般企业也会定制属于自己的404页面。

后续的内容我还打算针对一些常见场景，记录以下nginx的配置文件针对不同场景和需求该如何去写，以及为什么这么写。Nginx一些模块的详细介绍不打算专门写，大家如果有需求可以看官方文档。

【NGINX入门】3.Nginx的缓存服务器proxy_cache配置

本文介绍NGINX缓存机制，配置和参数说明。

如图所示，nginx缓存，可以在一定程度上，减少源服务器的处理请求压力。因为静态文件（比如css，js， 图片）中，很多都是不经常更新的。nginx使用proxy_cache将用户的请求缓存到本地一个目录。下一个相同请求可以直接调取缓存文件，就不用去请求服务器了。毕竟，IO密集型服务的处理是nginx的强项。

Nginx的缓存加速功能是由proxy_cache（用于反向代理和静态缓存）和fastcgi_cache（PHP动态缓存）两个功能模块完成。

Nginx缓存特点：

先上个例子：

因为我是在一台服务器上做试验，所以用了两个端口 80 和 90 进行模拟两台服务器之间的交互。

接下来讲一下配置项：

这里我设置了 图片 、 css 、 js 静态资源进行缓存。

当用户输入 域名时，解析得到 ip:port 的访问地址。 port 默认为80。所以页面请求会被当前server截取到，进行请求处理。

当解析到上述文件名结尾的静态资源，会到缓存区获取静态资源。

如果获取到对应资源，则直接返回数据。

如果获取不到，则将请求转发给 proxy_pass 指向的地址进行处理。

这里直接处理 90 端口接受到的请求，到服务器本地目录 /mnt/blog 下抓取资源进行响应。

细心的读者应该发现，我在第二段例子里，留了个彩蛋 add_header wall "hey!guys!give me a star." 。

add_header 是用于在报头设置自定义的信息。

所以，如果缓存有效的话，那么静态资源返回的报头，一定会带上这个信息。

（1）Nginx系列教程（3）nginx缓存服务器上的静态文件

（2）proxy_cache

nginx 反向代理之 proxy_cache

（3）Nginx使用upstream负载均衡和proxy_cache缓存实现反向代理