Ngnix介绍、安装、实战及用法！！！

一、Nginx简介

1、Nginx概述

Nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器，特点是占有内存少，并发能力强，能经受高负载的考验,有报告表明能支持高达 50,000 个并发连接数。

2、正向代理

正向代理：如果把局域网外的 Internet 想象成一个巨大的资源库，则局域网中的客户端要访问 Internet，则需要通过代理服务器来访问，这种代理服务就称为正向代理。

【在浏览器配置代理服务器，通过代理服务器去访问这个网址】

3、反向代理

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

反向代理服务器比如端口号是9001，真正的内部服务器是8001，但是客户端不知道，把后面的tomcat和反向代理服务器当作一个整体。

4、负载均衡

一般请求

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

把15个请求平均分发到3个服务器，每个服务器5个请求。

5、动静分离

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

二、Nginx安装

我这边ngnix就在windows上面安装【一般安装在linux系统中才能发挥它最大的效果】

下载安装包

nginx: download

直接解压即可

三、Ngnix配置文件

我们这边就直接看配置文件

D:\nginx-1.26.2\conf\ngnix.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;
    #    }
    #}

}

总共三部分组成，大致如下：

这是我去掉之前注释后剩下的部分：


worker_processes  1; #第一部分


events {
    worker_connections  1024;  #第二部分
}


http {                   #第三部分
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
   
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;

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

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    }

}

第一部分：全局块

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

1. user nobody;

这行是注释掉的，它的作用是指定 Nginx 进程的运行用户。在 Linux 系统中，每个进程都有一个用户身份，user 指令允许你指定 Nginx 工作进程运行时所使用的用户和用户组。

如果取消注释并且配置为 user nobody;，那么 Nginx 会以 nobody 用户身份运行。
默认情况下，Nginx 会使用启动 Nginx 的用户（通常是 nginx 或 www-data，具体取决于你在安装时配置的用户）。

一般来说，如果你不修改这个配置，Nginx 会自动选择一个默认的用户，通常是 nginx。

worker_processes  1;

这是Ngnix服务器并发处理服务的关键配置，worker_processes值越大，可以支持的并发处理量越多，但是会受到硬件、软件等设备的制约。

这个配置指示 Nginx 启动的 工作进程 数量。

工作进程 是 Nginx 处理请求的单位，每个工作进程负责处理一定的连接。通常情况下，Nginx 是事件驱动模型，即每个工作进程可以同时处理多个连接。
worker_processes 的值通常设置为服务器的 CPU 核心数，以充分利用多核 CPU 的性能。如果你的服务器有多个核心，可以将其设置为多于 1 的值，例如 worker_processes 4;。但在这段配置中，设置的是 1，意味着 Nginx 将启动一个工作进程。

注意： 在生产环境中，通常建议根据服务器的 CPU 核心数来调整 worker_processes，以提高并发性能。

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

这三行配置是关于 错误日志 的设置，但它们被注释掉了（以 # 开头）。具体含义如下：

error_log logs/error.log;

该指令用于设置 Nginx 错误日志的文件路径。默认情况下，Nginx 会将错误日志写入 logs/error.log 文件中。
如果你取消注释并配置它，Nginx 会将错误日志记录在该路径下。
错误日志用于记录 Nginx 运行中的各种错误信息，如启动失败、配置文件错误等。

error_log logs/error.log notice;

该行指定了日志的级别为 notice。Nginx 支持多种日志级别，例如：
debug: 最详细的日志，用于调试。
info: 一般信息，记录普通的运行时信息。
notice: 比 info 级别更重要的信息，通常用于表示正常的操作。
warn: 警告信息，表示有潜在的问题，但不影响正常运行。
error: 错误信息，表示出现了问题。
crit: 严重错误，通常需要马上处理。

error_log logs/error.log info;

该行将日志级别设置为 info，表示记录更详细的信息。

总结：

这三行的作用是控制日志记录的详细程度，通过不同的日志级别来控制哪些信息需要被记录。默认情况下，日志等级可能设置为 error，但可以根据需要调整。

#pid        logs/nginx.pid;

这行配置是注释掉的，指示 Nginx 将其进程 ID（PID）存储在一个文件中。

pid 用于指定保存 Nginx 主进程 ID 的文件路径，通常该文件会存储在 logs/nginx.pid。
取消注释并配置该行后，Nginx 会将主进程的 PID 写入 logs/nginx.pid 文件中。这对于 Nginx 进程的管理（如启动、停止、重载配置等）非常有用。

总结：

user nobody;：指定运行 Nginx 的用户（这里注释掉了，使用默认用户）。
worker_processes 1;：指定 Nginx 启动的工作进程数，通常建议设置为 CPU 核心数。
error_log logs/error.log;：设置错误日志的文件路径（默认 logs/error.log）。
pid logs/nginx.pid;：指定主进程的 PID 存储路径（默认 logs/nginx.pid）。

这段配置文件主要是设置 Nginx 运行时的一些基本参数，通常在开发、调试或者生产环境中，根据需要进行适当的调整。

第二部分：events块

events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。

下图例子就表示每个 work process 支持的最大连接数为 1024. 这部分的配置对 Nginx 的性能影响较大，在实际中应该灵活配置。

events {
    worker_connections  1024;
}

第三部分：http块

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

需要注意的是：http 块也可以包括 http 全局块、server 块。

①、http 全局块

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

1. include mime.types;

作用：这行配置告诉 Nginx 加载 mime.types 文件，这个文件定义了常见的文件扩展名与 MIME 类型之间的映射关系。比如 .html 文件类型是 text/html，.jpg 是 image/jpeg 等。
解释：mime.types 文件通常包含了一些标准的 MIME 类型，Nginx 会根据文件扩展名来推断文件的类型，确保它能够正确地设置 Content-Type 响应头。

2. default_type application/octet-stream;

作用：这个配置指定了默认的 MIME 类型。如果 Nginx 在 mime.types 文件中找不到某个文件的 MIME 类型，它会使用这个默认值。
解释：application/octet-stream 是一个通用的二进制文件类型，通常用于无法识别的文件类型。这样做的好处是，在没有明确的 MIME 类型时，可以保证文件不会被错误处理。

3.

作用：这段配置是被注释掉的，它定义了访问日志的格式。Nginx 的访问日志是非常重要的，用于记录访问者的请求。

解释：

$remote_addr：客户端的 IP 地址。
$remote_user：客户端的用户名（如果启用了基本认证）。
$time_local：请求发生的本地时间。
$request：请求的原始字符串，例如 GET /index.html HTTP/1.1。
$status：HTTP 响应状态码。
$body_bytes_sent：响应体的字节数。
$http_referer：请求来源的 URL。
$http_user_agent：客户端浏览器的信息。
$http_x_forwarded_for：客户端的真实 IP（当通过代理服务器访问时）。
如果取消注释并启用这一行，它会影响 Nginx 如何记录访问日志。你可以定义不同的格式来满足你的日志需求。

4. #access_log logs/access.log main;

作用：配置访问日志的文件路径以及日志格式（此处是 main 格式）。
解释：如果启用这行配置，Nginx 将会将访问日志写入到 logs/access.log 文件中，并且使用前面定义的 main 格式。如果你想要自定义日志路径或日志格式，可以修改这行配置。

5. sendfile on;

作用：开启 sendfile 功能。
解释：sendfile 用于高效地传输文件，它允许 Nginx 从磁盘直接将文件传输到网络连接，而不需要先将文件读取到内存中。这对于大文件的传输非常有效，能够提高文件的传输效率。

6. #tcp_nopush on;

作用：这行被注释掉了，默认情况下它是关闭的。启用后，会影响 Nginx 向客户端发送响应数据包的方式。

解释：

tcp_nopush 可以提高大文件（如图片、视频等）的传输效率。它会将多个小的数据包合并成一个大包一起发送，从而减少了网络上的数据包数量，提高了效率。
在某些情况下，这个选项可以帮助减少网络带宽的消耗，提高文件传输的性能。

7. #keepalive_timeout 0;

作用：这行配置被注释掉了，默认情况下是 65 秒。它设置了 连接的保持活动时间，即 Nginx 在处理完请求后，保持与客户端的连接处于活动状态的时间。
解释：
keepalive_timeout 设置了服务器保持客户端连接的最大时间。在此时间内，如果客户端继续请求，Nginx 会复用该连接，而不是重新建立连接。

如果设置为 0，表示禁用连接保持（即每次请求都会创建一个新的连接）。但通常会将其设置为非零值（例如 65），因为保持连接能够减少连接建立的开销，提高性能。

8. keepalive_timeout 65;

作用：这行配置指定了保持活动连接的超时时间。
解释：
keepalive_timeout 65; 意味着在没有新请求的情况下，Nginx 会保持与客户端的连接 65 秒。如果超过这个时间没有新请求，连接将会被关闭。
保持连接活跃（keep-alive）有助于提高性能，因为它减少了建立新连接的开销。

9. #gzip on;

作用：这行配置被注释掉了，默认情况下是关闭的。它指示是否启用 gzip 压缩。
解释：
启用 gzip 后，Nginx 会在响应中对内容进行压缩，减小数据大小，加速页面加载，尤其适合传输文本类型的文件（如 HTML、CSS、JS 文件）。
如果启用这行配置，Nginx 会根据请求头的 Accept-Encoding 来决定是否对响应内容进行压缩。

如下图：

②、server 块

这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。每个 http 块可以包括多个 server 块，而每个 server 块就相当于一个虚拟主机。而每个 server 块也分为全局 server 块，以及可以同时包含多个 locaton 块。

1、全局 server 块

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

1. listen 80;

作用：指示 Nginx 在端口 80 上监听请求。80 是 HTTP 协议的标准端口，通常用于接收浏览器发出的普通 HTTP 请求。
解释：当用户访问这个服务器时，如果没有指定端口，默认会访问 80 端口。【可以理解为ngnix运行占用了80端口，在浏览器访问80端口就是访问ngnix服务器（Nginx是一个高性能的HTTP和反向代理web服务器）】

“监听”（listening）通常指的是一个网络服务（如Nginx、后端服务器等）在某个特定的端口上等待并接收来自客户端的连接请求。

当它在80端口上监听时，它实际上是在说：“我在这台机器的80端口上等待，准备接收任何HTTP请求。监听也可以理解为占用该端口

当提到Nginx在端口80上监听请求时，这意味着Nginx服务器被配置为在其网络接口上监听TCP协议的80端口，以接收来自客户端（如Web浏览器）的HTTP请求。端口80是HTTP协议的默认端口，意味着当用户在浏览器中访问一个网址（如http://example.com）而没有指定端口号时，浏览器会自动尝试通过80端口与服务器通信。

2. server_name localhost;

作用：定义ngnix服务器的域名或 IP 地址。这里设置为 localhost，表示当请求的主机名为 localhost 时，将会匹配此 server 块。
解释：localhost 通常指代本地计算机（127.0.0.1）。你可以根据需要替换为自己的域名或 IP 地址。例如，example.com 或 www.example.com。

server_name 指定了 Nginx 服务器响应的域名或 IP 地址，但它的作用并不是直接定义 Nginx 服务器运行的 IP 地址，而是决定 Nginx 如何根据请求中的 Host 头部来选择匹配的 server 块。

假设：

server_name example.com;：当请求的 Host 头部为 example.com 时，Nginx 会使用这个 server 块来处理请求。
server_name localhost;：当请求的 Host 头部为 localhost 时，Nginx 会使用这个 server 块来处理请求。
server {
    listen 80;
    server_name example.com;
}

server {
    listen 80;
    server_name localhost;
}
总之，可以理解：

这段配置确实表明Nginx会在localhost的80端口上运行，并准备接收和处理HTTP请求。

  server {
        listen       9080;
        server_name  localhost,pay-test.anjulian.com.cn,172.25.52.60;

也可能有这种配置：这个server_name虽然有三个名字，不过都代表一台服务器。

3. #charset koi8-r;

作用：这行是注释掉的，表示你可以设置字符集（例如 koi8-r 是一种字符集，常用于俄语）。
解释：如果启用的话，它会设置服务器响应的默认字符编码。在此配置中，默认编码是 UTF-8。

4. #access_log logs/host.access.log main;

作用：这行也被注释掉了，通常是用于定义访问日志的位置和格式。Nginx 将请求的详细信息记录到指定的文件中。
解释：如果取消注释并启用，它会将访问日志写入 logs/host.access.log 文件，并使用 main 格式记录日志。日志记录了客户端的请求信息，包括 IP 地址、请求的 URL、响应状态码等。

2、location 块

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

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

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

作用：定义了请求的根目录 / 如何处理。
root html;：将请求的根目录映射到本地的 html 目录（通常是网站的根目录）。
index index.html index.htm;：指定当访问根路径时，默认查找的文件是 index.html 或 index.htm，如果文件存在，它们会作为响应内容返回。
解释：当用户访问该服务器时，如果请求路径是 /（即根路径），Nginx 会寻找 html 目录下的 index.html 或 index.htm 文件，并将其返回给客户端。

location = /50x.html { root html; }

作用：这个 location 配置定义了当访问 /50x.html 时，应该返回哪个文件。
解释：root html; 表示 50x.html 文件位于 Nginx 配置的 html 目录中。

后面注释的地方不用管了

③、总结：

虚拟主机是一种技术概念，它指的是在单个物理服务器上通过软件技术划分出多个逻辑上的服务器。这些逻辑上的服务器各自独立运行，仿佛它们是独立的物理服务器一样。Nginx 作为一个高性能的 HTTP 和反向代理服务器，通过其强大的配置功能，可以在单个服务器上配置多个 server 块，每个 server 块代表一个虚拟主机。

其次，每个 server 块可以监听不同的域名、IP 地址或端口号，并根据请求的不同将请求转发到对应的虚拟主机上进行处理。这样，虽然物理上只有一台服务器，但逻辑上却可以实现多个独立运行的服务器，每个服务器都可以有自己的域名、根目录、日志文件等配置信息。

定义了两个 server 块，每个块都监听一个不同的端口（9080 和 9443）。因此，当启动 Nginx 服务器时，它会同时占用这两个端口。

访问不同的端口，然后根据不同的server块处理请求。

server块中的location指令用于定义请求的路由规则。它可以根据请求的URL路径将请求转发到不同的后端服务器、文件系统位置或者执行特定的操作（如重定向等）
server {
    listen       80;
    server_name  blog.example.com;
    location / {
        root   /var/www/blog;
        index  index.html;
    }
    location /images/ {
        root   /var/www/blog;
    }
}
在这个server块配置中，当用户访问http://blog.example.com时，Nginx会从/var/www/blog目录下查找index.html文件作为响应。而当用户访问以http://blog.example.com/images/开头的URL路径时，Nginx会从/var/www/blog/images/目录下查找对应的文件进行响应。

server {
    listen       80;
    server_name  api.example.com;
    location / {
        proxy_pass http://backend-api-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X - Real - IP $remote_ip;
    }
}
此示例展示了server块作为反向代理的功能。当用户访问http://api.example.com相关的请求时，Nginx会将请求转发到运行在backend - api - server:8080的后端API服务器上。同时，通过proxy_set_header指令设置了一些请求头信息，使得后端服务器能够正确获取请求的来源信息。

四、Nginx启动

我们先就默认配置启动，双击一下，然后如果看到画面一闪而过，代表启动成功

我们直接浏览器输入localhost 就可以进入，这个画面其实在前面说过，就是下面第二张图中html目录下面的index.html(默认配置就是访问的这个界面），如果启动失败那应该会访问50x.html。

出现下面界面代表启动成功

五、Nginx配置实战

1、Nginx配置实例-反向代理

将请求转发到后端服务器

实例一

一般我们这里是用的打包后的前端项目，然后指定到后端sprinboot项目（自带tomcat）

反向代理配置
修改host文件（地址直接参照以下图片）

加上一行：将www.123.com映射到192.168.179.137（ip是Linux地址）

192.168.179.137 www.123.com

因为我这里是window是所以这里就不用了

启动ngnix：

start nginx

停止：

nginx.exe -s quit

总结：

因为我们这里是测试的反向代理，我这里本地启动了一个springbooot服务、localhost:8080，我在浏览器输入这个即可进入到一个界面，然后我用ngnix做反向代理，我输入的是localhost:80即可进入这个界面

实例二

这里就描述一下：

（1）准备两个tomcat服务器，一个8080端口，一个8081端口

~代表正则表达式的形式，有edu就8080，有vod就8081

在 Nginx 中，location 指令用于配置 URI 路径匹配规则。location ~/edu/ 和 location /edu/ 看似相似，但它们有一些重要的区别，主要体现在匹配方式上。

1. location /edu/

这种形式的 location 是 前缀匹配（prefix matching），意味着它会匹配以 /edu/ 开头的所有 URI。
它会匹配任何包含 /edu/ 前缀的路径，无论后面接什么内容，都会被这条规则捕获。
这种匹配规则是 最常见的，适用于常见的路径匹配需求。

例如，以下路径会匹配 location /edu/：

/edu/
/edu/index.html
/edu/abc/xyz
location /edu/ { # 处理以 /edu/ 开头的路径 }
2. location ~/edu/

这种形式的 location 是 正则表达式匹配（regex matching），它会使用正则表达式对路径进行匹配。
在 ~/ 前缀后跟着的 /edu/ 是一个正则表达式，用来匹配符合该表达式的路径。
注意，正则表达式匹配的顺序是较晚的，所以如果有其他的 location 路径匹配规则符合该路径，它将不会是优先匹配的规则，只有在没有找到前缀匹配时，正则表达式匹配才会被应用。

例如，以下路径会匹配 location ~/edu/：

/edu/
/path/to/edu/
/abc/edu/xyz/
/course/edu/class/
location ~/edu/ { # 处理通过正则表达式匹配的路径，大小写敏感、区分大小写 }
主要区别

前缀匹配 (/edu/): 直接根据路径的前缀来匹配，不考虑路径中的其他部分。
正则匹配 (~/edu/): 使用正则表达式匹配，允许更复杂的匹配逻辑，例如大小写不敏感、包含多个字符等。

匹配顺序

在 Nginx 中，location 的匹配是按照以下顺序进行的：

精确匹配：匹配最准确的路径。
前缀匹配：从长到短的匹配（最长的前缀优先）。
正则匹配：最后使用正则表达式进行匹配。

因此，正则表达式匹配会在前缀匹配之后进行。为了确保正确的匹配顺序，通常推荐正则匹配规则使用 ~（大小写敏感）或 ~*（大小写不敏感），并且它们通常放在后面。

2、Nginx负载均衡

大概是实现效果就是每次请求80端口刷新，轮询请求一个服务器，可能是8080，可能是8081

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

upstream myserver{
        server 192.168.77.130:8080;
        server 192.168.77.130:8081;
}

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

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

upstream myserver{
          server 192.168.77.130:8080 weight=10;
          server 192.168.77.130:8081 weight=5;
}

3、 ip_hash
每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。也就是说，客户第一次访问这个服务器，之后访问的都是这个服务器。

upstream myserver{
ip_hash;
          server 192.168.77.130:8080 ;
          server 192.168.77.130:8081 ;
}

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

upstream myserver{
             server 192.168.77.130:8080;
             server 192.168.77.130:8081;
             fair;
}

3、Nginx动静分离

实现效果:不同资源访问不同服务器。

一般在linux系统中，这个root就是根目录，所以可以直接用data

如果是在windows系统中，之前有一个默认示例，就是html中的静态页面，root应该就是从nginx的目录下开始

准备工作
在/data里面准备两个文件夹/image和/www，里面分别放入01.jpg和a.html来模拟静态资源。

Niginx具体配置
autoindex on：目的是为了在访问 /image 时，能够显示目录里面的内容，当然这里也可以通过expire设置缓存过期时间。

或者直接

http://192.168.17.129/image/01.jpg

如果是访问http://192.168.17.129/www/没有autoindex on，所以是404

但是可以http://192.168.17.129/www/a.html。可以看到页面

个人理解：

前面请求服务器就是动态请求，这里就是访问静态页面。

注意还是有点区别：

1、比如访问服务器的时候localtion后面的路径代表可能要走不同的端口

2、如果是访问静态资源，这里可能是代表静态资源的文件夹

3、还有就是前端打包的时候，动静结合。

六、项目打包实战

1、测试

start nginx

tasklist | findstr nginx

重新加载配置启动

nginx -s reload

检查配置是否有效：

nginx -t

关闭ngnix

nginx -s quit

tasklist | findstr nginx

不返回结果，代表关闭

proxy_pass http://localhost:9100/;

注意路径后面有一个“/"

和前面的反向代理一样。这里可以直接访问到后端服务器，但是我们一般用ngnix部署前端

2、若依打包部署

不能这样写：

location / {
    root   html/dist;
    proxy_pass http://localhost:9100/;
    index  index.html index.htm;
}

即使你配置了 root html/dist; 来提供静态文件，proxy_pass 会将请求转发到 http://localhost:9100，而不是直接访问静态文件。

通常，前端和后端请求会被分开处理，前端静态文件由 Nginx 提供，而后端 API 请求通过 proxy_pass 进行代理。你可以通过不同的 location 块来分别处理静态文件和后端 API 请求。

假设你的前端文件位于 html/dist 目录，而后端服务运行在 http://localhost:9100，你可以按以下方式配置：
# 提供静态文件
location / {
    root   html/dist;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;  # 如果静态文件没有找到，重定向到 index.html
}

# 代理后端 API 请求
location /gateway/slhy-mgr-ui/ {
    proxy_pass http://localhost:9100;
    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;
}
路径后面有一个”/"，这里漏了

不过一般vue.config.js，后面没有/

若依前端挂Nginx、打包部署运行！！！！-CSDN博客

在 Nginx 中，当使用 proxy_pass 指定目标地址时，URL 中是否包含尾随的 / 会影响路径的重写行为。这是一个容易引起混淆但非常重要的细节。

1. 不加 / 的行为：
proxy_pass http://192.168.1.30:8085;
效果：

Nginx 会将客户端请求路径的整个路径部分追加到目标地址。
原始请求路径不会被剪裁，而是直接拼接到 proxy_pass 的目标地址。

示例：

假设客户端请求
GET /gateway/slhy-mgr-ui/test
在上述配置下，转发到后端的 URL 将会是：
http://192.168.1.30:8085/gateway/slhy-mgr-ui/test
可能的问题：

如果后端服务期望 /gateway/slhy-mgr-ui/ 前缀已经被去掉（例如后端只处理 /test），这种配置会导致路径不匹配，返回 404 或其他错误。

2. 加 / 的行为：
proxy_pass http://192.168.1.30:8085/;
效果：

Nginx 会将客户端请求路径中与 location 配置匹配的部分剪裁掉，然后将剩余路径追加到目标地址。
proxy_pass 的目标地址中的尾随 / 告诉 Nginx：匹配的路径部分需要被替换，而不是直接追加。

示例：

假设 location 配置如下：
location /gateway/slhy-mgr-ui/ {
    proxy_pass http://192.168.1.30:8085/;
}
客户端请求：
GET /gateway/slhy-mgr-ui/test
转发到后端的 URL 将会是：
http://192.168.1.30:8085/test
为什么有这个变化？

Nginx 根据 location 的路径部分 /gateway/slhy-mgr-ui/ 匹配到请求，然后将匹配部分剪裁掉。
剩余的 /test 被追加到 proxy_pass 的目标地址。