当前位置： 首页 > news >正文

Nginx 超详细详解和部署实例

news 2025/8/14 7:11:01

目录

一、Nginx介绍

二、Nginx安装

2.1、安装环境准备

2.2、下载 Nginx 安装包

2.3、解压与配置编译环境

2.4、编译与安装

2.5、启动与基本管理

三、Nginx配置和使用

3.1、基础配置逻辑

3.1.1、按域名 / 端口区分不同业务

3.1.2、root 指令：路径拼接方式

3.1.3、alias 指令：路径替换方式

3.2、Nginx正向代理与反向代理

3.2.1、正向代理

3.2.2、反向代理

3.3.3、正向代理和反向代理区别

3.3、负载均衡算法

3.3、跨域问题（CORS）

3.3.1、跨域问题详解

3.3.2、Nginx 解决跨域的原理与配置

3.4、动静态资源分离

3.4.1、什么是动静态资源分离？

3.4.2、为什么需要动静态分离？

3.4.3、Nginx 实现动静态分离的核心思路

五、配置说明

四、SpringBoot+Vue项目部署

4.1、需部署的环境

4.2、注意事项

4.2.1 安装方式

1. 安装方式分类

（1）yum 安装

（2）源码编译安装

（3）二进制包安装

（4）rpm 包安装

4.2.2、不同方式的启动和关闭

4.2.3、端口号的开放

4.3、后端项目打包部署

4.4、前端项目打包部署（使用Nginx代理）

一、Nginx介绍

        Nginx是一款轻量级、高性能的 HTTP 和反向代理服务器，

        Nginx 采用事件驱动的异步非阻塞模型，能够高效地处理大量并发连接。与传统的 Web 服务器（如 Apache）相比，Nginx 在性能表现上具有显著优势，尤其在高并发场景下，Nginx 能够保持较低的资源消耗，提供更快的响应速度

二、Nginx安装

2.1、安装环境准备

        本文以 CentOS 系统为例进行安装演示。在安装 Nginx 之前，需要确保系统已经安装了必要的依赖包，Nginx 基于 C 语言开发，因此需要安装 C 语言编译环境以及其他相关依赖。执行以下命令安装依赖包：

yum -y install gcc pcre-devel zlib-devel openssl openssl-devel

        其中，gcc是 C 语言编译器，pcre-devel用于支持 PCRE 正则表达式库（Nginx 配置中常用到正则表达式），zlib-devel用于支持数据压缩，openssl和openssl-devel用于支持 SSL/TLS 加密功能。

2.2、下载 Nginx 安装包

        Nginx 官方网站提供了稳定版本和开发版本的下载。通常建议在生产环境中使用稳定版本，以确保系统的稳定性和安全性。访问 Nginx 官网的下载页面（nginx: download），选择合适的稳定版本，本文以nginx-1.24.0为例，使用wget命令下载安装包：

yum install wget
wget https://nginx.org/download/nginx-1.24.0.tar.gz

2.3、解压与配置编译环境

下载完成后，解压 Nginx 压缩包，并进入解压后的目录进行编译环境配置：

tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0
./configure --prefix=/usr/local/nginx

  --prefix=/usr/local/nginx参数指定了 Nginx 的安装目录为/usr/local/nginx，你可以根据实际需求进行调整。configure脚本会检查系统环境，确保满足 Nginx 编译所需的依赖条件，并生成相应的 Makefile 文件。

2.4、编译与安装

执行以下命令进行编译和安装：

make & make install

 make命令根据之前生成的 Makefile 文件编译 Nginx 源代码，make install则将编译好的 Nginx 二进制文件及相关配置文件安装到指定的目录（即/usr/local/nginx）。

2.5、启动与基本管理

安装完成后，进入 Nginx 的安装目录/usr/local/nginx/sbin，可以使用以下命令对 Nginx 进行管理：

# 查看版本
./nginx -v
# 检查配置文件语法
./nginx -t
# 启动Nginx
./nginx
# 停止Nginx
./nginx -s stop
# 重新加载配置文件（修改配置后使用）
./nginx -s reload

        为了方便使用，建议将 Nginx 的sbin目录添加到系统的环境变量中。编辑/etc/profile文件，在PATH环境变量中增加/usr/local/nginx/sbin，修改完成后执行source /etc/profile使配置生效。这样，在系统的任何目录下都可以直接执行nginx命令。

三、Nginx配置和使用

3.1、基础配置逻辑

        Nginx 存放静态资源的核心是：通过 server 块区分不同访问入口（域名或端口），再用 location 块指定资源存放路径，让不同请求对应到正确的本地文件。

3.1.1、按域名 / 端口区分不同业务

nginx

# 用域名区分（需解析域名）
server {listen 80;server_name member.hltop.cn;  # 会员业务域名location / {root html/member;  # 资源存放在 Nginx安装目录/html/memberindex index.html;  # 访问根路径时默认找index.html}
}
server {listen 80;                  # 同一80端口，不同域名server_name order.hltop.cn;   # 订单域名location / {root /var/www/order;index index.html;}
}
-------------------------------------------------------
# 用端口区分（适合本地测试）
server {listen 8081;  # 用8081端口访问会员业务location / {root html/member;index index.html;}
server {listen 8082;                # 测试端口2location / {root /var/www/test2;index index.html;}
}

3.1.2、root 指令：路径拼接方式

root 是最常用的指定资源目录的指令，它的路径拼接规则很简单：
最终文件路径 = root 指定的目录 + location 匹配的路径 + 请求的文件名

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

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

  1. location 匹配到 /img/
  2. 拼接路径：/var/www/static（root） + /img/（location 匹配的路径） + logo.png（请求的文件名）
  3. 实际查找的文件：/var/www/static/img/logo.png

3.1.3、alias 指令：路径替换方式

alias 用于替换 location 匹配的路径，适合需要重命名目录的场景。它的拼接规则是：
最终文件路径 = alias 指定的目录 + 请求中 location 之后的部分
（注意：alias 后面的目录路径必须以 / 结尾）

nginx

location /img/ {alias /var/www/static/image/;  # 用/image/替换/img/
}

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

  1. location 匹配到 /img/，但这个路径会被 alias 替换
  2. 拼接路径：/var/www/static/image/（alias） + logo.png（请求中/img/之后的部分）
  3. 实际查找的文件：/var/www/static/image/logo.png

root 和 alias 的核心区别

场景

root 指令

alias 指令

作用

设定根目录，路径叠加

替换 location 匹配的路径

路径要求

无特殊要求

目录必须以 /

结尾

适用场景

大多数静态资源映射

需重命名目录的场景（如 URL 显示 /img/，实际用 /image/ 目录）

        简单说：root 是「在指定目录下追加路径」，alias 是「直接替换路径」。根据实际目录结构选择即可。

3.2、Nginx正向代理与反向代理

3.2.1、正向代理

3.2.1 概念

        正向代理是位于客户端和目标服务器之间的代理服务器。当客户端需要访问外部资源时，客户端将请求发送到正向代理服务器，代理服务器代替客户端向目标服务器发送请求，并将目标服务器的响应返回给客户端。

        正向代理是指代理服务器代理客户端，使得客户端可以访问被代理的服务器上的资源。举个例子，我们可以使用正向代理访问一些境外网站，这些网站被代理服务器所代理，客户端看到的是代理服务器响应的内容。这时，被代理的服务器并不知道客户端的存在，只知道代理服务器的存在。正向代理主要应用于隐藏客户端的 IP 地址、访问互联网被封锁的资源等场景

3.1.2 Nginx 实现正向代理配置

在 Nginx 中配置正向代理，需要编辑 Nginx 的配置文件，通常位于/usr/local/nginx/conf/nginx.conf。在http块内添加如下配置：

nginx

server {listen 8080; # 代理服务器监听端口resolver 8.8.8.8; # 指定DNS服务器，用于域名解析location / {proxy_pass http://$http_host$request_uri;}
}

        上述配置中，listen指令指定了代理服务器监听的端口为8080，客户端将请求发送到该端口。resolver指令指定了 DNS 服务器地址（这里使用 Google 的公共 DNS 服务器8.8.8.8），用于将域名解析为 IP 地址。location /块表示对所有请求进行处理，proxy_pass指令将客户端的请求转发到目标服务器，$http_host和$request_uri是 Nginx 的内置变量，分别表示客户端请求的主机名和请求的 URI。

        配置完成后，检查配置文件语法并重新加载 Nginx 配置：

nginx -t
nginx -s reload

        此时，客户端需要将代理服务器的地址和端口配置到网络设置中，才能通过 Nginx 正向代理访问外部资源。需要注意的是，Nginx 的正向代理默认不支持 HTTPS 站点，如果需要代理 HTTPS 请求，还需要进行额外的配置。

3.2.2、反向代理

3.2.1 概念

        反向代理位于客户端与目标服务器之间。客户端向反向代理服务器发送请求，反向代理会依据配置规则，把请求转发到后端的目标服务器，再将目标服务器的响应回传给客户端。对客户端而言，它不清楚具体是后端哪台服务器处理了请求，仅与反向代理交互，反向代理隐藏了后端服务器的真实 IP 和架构细节。

        反向代理常用于为服务器端提供服务，可实现负载均衡（比如按算法选合适服务器转发请求）、缓存加速、安全防护（隐藏后端信息、抵御直接攻击），还能进行 SSL 加密等，主要在数据安全性、访问速度、系统弹性等方面发挥作用。

3.2.2 Nginx 实现反向代理配置

在 Nginx 中配置反向代理同样需要编辑配置文件。假设后端有一台 Web 服务器，IP 地址为192.168.1.100，端口为8080，现在要通过 Nginx 反向代理将客户端对http://example.com的请求转发到该后端服务器。在nginx.conf文件的http块内添加如下server块配置：

server {listen 80; # 监听端口server_name example.com; # 域名或IP地址location / {proxy_pass http://192.168.1.100:8080; # 反向代理到后端服务器proxy_set_header Host $host; # 设置请求头，将客户端请求的主机名传递给后端服务器proxy_set_header X-Real-IP $remote_addr; # 设置请求头，将客户端的真实IP传递给后端服务器}
}

  listen指令指定 Nginx 监听的端口为80，server_name指定了反向代理的域名或 IP 地址（这里假设为example.com，实际使用时需替换为真实的域名或 IP）。location /块表示对所有请求进行匹配处理，proxy_pass指令将请求转发到后端服务器http://192.168.1.100:8080。proxy_set_header指令用于设置请求头信息，将客户端的一些信息（如主机名、真实 IP）传递给后端服务器，这在后端服务器需要根据这些信息进行处理时非常重要。

        配置完成后，同样需要检查配置文件语法并重新加载 Nginx 配置，使配置生效。

        这段配置的作用就是：当用户访问 example.com（通过 80 端口）时，Nginx 会自动将请求悄悄转发到后端的 http://192.168.1.100:8080 服务器，而用户完全感知不到这个转发过程 —— 在用户看来，自己就是直接访问 example.com 并得到了响应。

3.3.3、正向代理和反向代理区别

区别：

  • 正向代理：客户端明确知道自己在通过代理服务器访问目标服务器（比如设置浏览器代理），整个过程是 “客户端→代理→目标服务器”，客户端主动依赖代理才能完成请求。
  • 反向代理：客户端以为自己直接访问的是 “目标服务器”（实际是反向代理服务器的地址），完全不知道后端有多少台真实服务器，也不关心代理如何转发请求。对客户端来说，“反向代理服务器” 就是它眼中的 “目标服务器”，整个过程是 “客户端→反向代理（以为是目标服务器）→后端真实服务器”，代理行为对客户端完全透明。

在简单说：

  • 正向代理是 “客户端主动找代理帮忙上网”；
  • 反向代理是 “后端服务器偷偷用代理对外提供服务”，客户端被蒙在鼓里。

3.3、负载均衡算法

Nginx 支持多种负载均衡算法，每种算法都有其特点和适用场景：

        1.轮询（Round Robin）：默认算法，每个请求按时间顺序逐一分配到不同的后端服务器。如果后端服务器出现故障，Nginx 会自动将其剔除，请求将分配到其他正常的服务器上。例如：

nginx

upstream backend_servers {server 192.168.1.101:8080;server 192.168.1.102:8080;
}

        2.权重（Weighted Round Robin）：为后端服务器设置不同的权重，权重越高的服务器被分配到的请求越多。适用于后端服务器性能不均的情况，例如：

nginx

upstream backend_servers {server 192.168.1.101:8080 weight=3;server 192.168.1.102:8080 weight=1;
}

        这里192.168.1.101服务器的权重为 3，192.168.1.102服务器的权重为 1，那么在负载均衡时，192.168.1.101服务器被分配到请求的概率将是192.168.1.102服务器的 3 倍。
        3. IP 哈希（IP Hash）：根据客户端的 IP 地址计算哈希值，将请求分配到固定的后端服务器上。这样可以确保同一客户端的请求始终被转发到同一台后端服务器，适用于需要保持会话一致性的场景，例如：

upstream backend_servers {ip_hash;server 192.168.1.101:8080;server 192.168.1.102:8080;
}

3.3、跨域问题（CORS）

3.3.1、跨域问题详解

1. 什么是跨域？

跨域是指浏览器出于安全考虑（同源策略），限制一个域的网页去请求另一个域的资源。

  • 同源：指两个 URL 的 协议、域名、端口 完全一致。例如：
    • http://example.com 与 https://example.com（协议不同，跨域）
    • http://example.com 与 http://api.example.com（域名不同，跨域）
    • http://example.com:80 与 http://example.com:8080（端口不同，跨域）

2. 跨域的常见场景

  • 前端页面（http://frontend.com）请求后端 API（http://backend.com）
  • 静态资源（如图片、JS）从 http://a.com 加载到 http://b.com 的页面中
  • 前后端分离项目中，前端本地开发环境（http://localhost:3000）请求后端服务器（http://localhost:8080）

3. 跨域的本质：浏览器的同源策略限制

        同源策略是浏览器的安全机制，防止恶意网站窃取其他网站的资源或数据。当跨域请求发生时，浏览器会拦截响应（即使服务器正常返回数据），并在控制台报类似错误：

Access to fetch at 'http://backend.com/api' from origin 'http://frontend.com' has been blocked by CORS policy...

3.3.2、Nginx 解决跨域的原理与配置

        Nginx 解决跨域的核心思路是：通过反向代理将跨域请求转为同域请求。
        即前端页面请求 Nginx 服务器（同域），Nginx 再转发请求到真实后端服务器，从而绕过浏览器的同源策略限制。

1. 场景假设

  • 前端页面地址：http://frontend.com（端口 80）
  • 后端 API 地址：http://backend.com:8080（跨域，协议 / 域名 / 端口任一不同）
  • 目标：让前端通过 http://frontend.com/api 访问后端 API，实现 “同域” 请求。

2. Nginx 配置示例

server {listen 80;server_name frontend.com;  # 前端页面的域名（同域）# 处理前端页面的静态资源（如 HTML、CSS、JS）location / {root /path/to/frontend;  # 前端代码存放目录index index.html;}# 反向代理后端 API，解决跨域location /api/ {  # 前端请求以 /api 开头的路径时，触发代理proxy_pass http://backend.com:8080/;  # 转发到真实后端（注意末尾的 / 含义）# 关键：设置跨域相关响应头，允许浏览器接收add_header Access-Control-Allow-Origin $http_origin;  # 允许请求的源（$http_origin 为动态值,或者为*允许所有的跨域调用）add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;  # 允许的请求方法add_header Access-Control-Allow-Headers Content-Type,Authorization;  # 允许的请求头add_header Access-Control-Allow-Credentials true;  # 允许携带 Cookie（需前后端配合）}
}

3. 配置说明

  • proxy_pass 转发规则：
    当前端请求 http://frontend.com/api/user 时，Nginx 会转发到 http://backend.com:8080/user（/api/ 被替换为后端的根路径）。
  • 跨域响应头作用：
    • Access-Control-Allow-Origin：告诉浏览器 “允许 frontend.com 这个源的请求”，$http_origin 表示动态匹配请求的源（更灵活）
    • Access-Control-Allow-Credentials：如果前端请求需要携带 Cookie 或认证信息，必须设置为 true，且 Allow-Origin 不能为 *（需指定具体域名）。

4. 效果

        前端只需请求同域的 http://frontend.com/api/xxx，Nginx 自动转发到后端，浏览器认为是同域请求，不再拦截，跨域问题解决。

3.4、动静态资源分离

3.4.1、什么是动静态资源分离？

动静态分离是指将网站的动态资源和静态资源分开部署、管理和访问的架构设计。

  • 静态资源：即所说的前端资源，指内容不随请求变化的文件，如 HTML、CSS、JS、图片（jpg/png）、视频、字体等（可被浏览器缓存）。
  • 动态资源：即后端请求，指内容随请求参数或业务逻辑动态生成的资源，如 PHP/JSP/Java 代码生成的页面、API 接口返回的 JSON 数据等（需服务器计算后返回）。

        通过分离，可让静态资源由专门的服务器（如 Nginx）处理，动态资源由应用服务器（如 Tomcat、Node.js）处理，从而提升整体性能。

3.4.2、为什么需要动静态分离？

  1. 减轻应用服务器压力：
    静态资源访问频率高（如首页图片、样式表），若全部由处理动态逻辑的应用服务器承担，会占用其 CPU / 内存资源，影响动态请求的响应速度。
  2. 提升静态资源加载速度：
    Nginx 处理静态资源的效率远高于应用服务器（底层基于异步非阻塞 IO，适合高并发静态文件读取），且可配合浏览器缓存、CDN 进一步加速。
  3. 便于缓存和扩展：
    静态资源可设置长期缓存策略，或通过 CDN 分发到边缘节点；动态资源则可专注于业务逻辑，按需扩容应用服务器。

3.4.3、Nginx 实现动静态分离的核心思路

        Nginx 通过 location 指令匹配不同资源路径，将静态资源请求直接由 Nginx 本地处理（读取服务器文件），动态资源请求转发到后端应用服务器（如 Tomcat、Spring Boot 等）。

假设场景：

  • 静态资源（CSS/JS/ 图片）存放路径：/usr/share/nginx/static
  • 动态资源由后端应用服务器 http://192.168.1.101:8080 处理

配置如下：

nginx

server {listen 80;server_name example.com;  # 网站域名# 1. 处理静态资源：匹配以 /static/ 开头的路径（如 CSS、JS、图片）location /static/ {root /usr/share/nginx;  # 静态资源根目录（实际路径为 /usr/share/nginx/static/）try_files $uri =404;  # 若文件不存在，返回404}# 2. 处理动态资源：所有非静态资源的请求转发到后端应用服务器location / {proxy_pass http://192.168.1.101:8080;  # 转发到动态服务器proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}
}

五、配置说明

后面部署实例有更加详细的解释

  1. 静态资源处理（location /static/）：
  • 当用户请求 http://example.com/static/css/style.css 时，Nginx 会直接读取服务器上的 /usr/share/nginx/static/css/style.css 文件并返回。
  • try_files $uri =404：若请求的静态文件不存在，直接返回 404 错误，避免转发到后端服务器。
  1. 动态资源处理（location /）：
  • 除了 /static/ 路径外的所有请求（如 http://example.com/api/user、http://example.com/login），都会被转发到后端应用服务器 192.168.1.101:8080 处理。

四、SpringBoot+Vue项目部署

以下是在 Linux 下部署 SpringBoot 前后端分离项目时，所需环境（JDK、MySQL、Redis、Tomcat、Nginx）的安装方式及注意事项整理：

4.1、需部署的环境

需在 Linux 系统中部署以下环境：

  • JDK
  • MySQL
  • Redis
  • Tomcat
  • Nginx（用于部署前端项目）

部署时需要注意以下三点：

4.2、注意事项

4.2.1 安装方式

1. 安装方式分类

共四种常见安装方式，适用场景及操作特点如下：

（1）yum 安装
  • 操作方式：通过 yum 命令直接安装（如 yum install 软件名）。
  • 特点：
    • 自动解决依赖关系，安装 / 卸载便捷。
    • 安装后默认生成 systemd 服务单元文件，可通过 systemctl 命令（如 start/stop/status）管理服务。
    • 适合快速部署、生产环境基础版本需求。
（2）源码编译安装
  • 操作流程：

1. 下载源码包（通常为 .tar.gz 格式），使用 tar -xvzf 文件名 解压。

如图，nginx目录就是我们刚解压好的目录：

    2.进入解压目录，配置编译参数（如 ./configure 或 cmake，指定安装路径、功能模块等），此步骤会检查系统依赖，缺失则报错。

      3.编译并安装：

      • make：根据配置生成的 Makefile，调用编译器（如 gcc）将源码编译为二进制可执行文件。​
      • make install：将编译好的文件复制到配置阶段指定的系统目录（如 /usr/local/软件名），完成部署。

      注意事项：

      • 服务器中会存在两份文件：下载的源码包目录 + make install 后的系统指定目录。
      • 配置文件需修改 make install 后的系统目录中的文件，而非原始源码包目录中的文件（如 Nginx 配置需修改 /usr/local/nginx/conf/nginx.conf）。
      • 适用场景：需定制化功能（如启用 / 禁用特定模块）、需指定版本时使用。
      （3）二进制包安装
      • 操作方式：
        1. 下载预编译的二进制包（通常为 .tar.gz 格式），使用 tar -xvzf 文件名 解压。
        2. 解压后可直接使用（无需编译），文件集中在解压目录内。
      • 与源码编译安装的核心区别： 
        • 二进制包解压后不会自动复制到系统指定目录，需手动处理（如直接在解压目录运行，或手动复制到 /usr/local/ 等路径）。
        • 无源码文件，无需 configure、make 等编译步骤。

      区分源码包与二进制包：

      特征

      源码包

      二进制包

      文件名

      仅含软件名 + 版本（如 nginx-1.24.0.tar.gz），可能带 src

      标识

      含系统架构

      （如 x86_64，如 mysql-8.0.34-linux-x86_64.tar.gz）

      解压后内容

      含 .c/.cpp源码文件、configure/CMakeLists.txt等编译配置文件

      含 bin/目录（可直接运行的二进制文件）、lib/库文件、conf/配置模板

      是否需编译

      是（需 make）

      否（直接运行）

      （4）rpm 包安装
      • 操作方式：通过 rpm 命令手动安装（如 rpm -ivh 包名.rpm）。
      • 特点：
        • 可精确控制版本，无需依赖 yum 仓库（需提前下载对应 rpm 包）。
        • 需手动解决依赖关系（依赖缺失时需单独安装）。
      • 适用场景：需固定版本且无法使用 yum 仓库时。

      除了第一种可以使用systemctl管理查看状态，其他方式安装的都不可使用该命令查看。

      4.2.2、不同方式的启动和关闭

      1、若使用yum安装的软件

      # 临时启动（当前会话生效，重启后失效）
sudo systemctl start 服务名# 开机自启（永久生效）
sudo systemctl enable 服务名# 临时停止（当前会话生效，重启后若已设置自启则会重新启动）
sudo systemctl stop 服务名# 禁止开机自启（仅关闭自启，不影响当前运行状态）
sudo systemctl disable 服务名# 查看服务状态（是否运行、启动失败原因等）
sudo systemctl status 服务名# 重新加载服务配置
sudo systemctl reload 服务名# 若不支持重新加载，则重启服务
sudo systemctl restart 服务名

      2、若使用安装包安装的软件

      这个并没有统一规范，多数源码文件会在安装目录下生成bin/sbin目录，包含启动/关停脚本（如start.sh，stop.sh或直接以软件命名的可执行文件），具体的需要查看官网文档说明。

      • 启动：直接执行启动脚本（通常需要指定配置文件路径）
        示例（以 Nginx 源码安装为例）：
      # 启动（假设安装在/usr/local/nginx）
/usr/local/nginx/sbin/nginx# 示例：重新加载配置
/usr/local/nginx/sbin/nginx -s reload
      • 关停：执行停止脚本，或通过软件自带的参数停止
      # Nginx停止（通过自带参数）
/usr/local/nginx/sbin/nginx -s stop# 若软件支持信号停止（如Redis）
kill -9 进程ID     # 强制杀死（不推荐，可能导致数据丢失）

      4.2.3、端口号的开放

              一般每个服务都有对应的端口号，我们可以从配置文件中看到这个端口号。如果要访问这个服务，那么一定要放行这个端口号，一共有两个位置需要更改：

              如在 Linux 系统中放行 8081 端口，通常需要在云服务器控制台配置安全组规则，并在服务器终端配置防火墙规则。

      1、终端配置防火墙规则：

      sudo firewall-cmd --add-port = 8081/tcp --permanent

      命令，添加 8081 端口到防火墙规则中，--permanent参数表示永久生效。

      然后执行

      sudo firewall - cmd --reload

      命令，重新加载防火墙规则，使新规则生效。

      2、云服务器控制台配置：

              登录腾讯云控制台，找到对应的云服务器实例，进入 “网络与安全” 部分，查看或编辑安全组策略。在安全组规则中添加允许入站流量的规则，协议选择 TCP，端口范围设置为 8081，来源设置为0.0.0.0/0，保存规则即可。

      4.3、后端项目打包部署

      我们对springBoot项目进行打包，在依赖中加入下面代码

      <build><plugins>
<!--            负责将 Java 源代码编译为字节码（.class 文件），是 Maven 原生的编译工具。--><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>3.8.1</version><configuration><source>1.8</source><target>1.8</target><encoding>UTF-8</encoding></configuration></plugin>
<!--            是 Spring Boot 提供的专用插件，用于将项目打包为可直接运行的jar/war包（包含嵌入式服务器，如 Tomcat），并支持 Spring Boot 特有的构建功能。--><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>${spring-boot.version}</version><executions><execution><id>repackage</id><goals><goal>repackage</goal></goals></execution></executions></plugin></plugins></build>

      打包好后，会生成两个jar包，一个jar包，一个jar.original包，我们把第一个jar包上传到云服务器上。

      上传好后，执行java -jar 项目名即可启动后端项目

      4.4、前端项目打包部署（使用Nginx代理）

              因为我们是前后端分离项目，刚才的只是部署后端到云服务器上，下面我们部署前端vue项目

      我们打开vue项目，在终端输入命令

      npm run build

              将前端代码（如Vue的.vue、.js文件，以及样式图片等）编译、压缩、打包成浏览器可以直接运行的静态资源（HTML，CSS，JS、图片等），输出到dist目录

              然后我们将dist目录打包成压缩包，上传到云服务器上，记住上传的位置

              然后我们打开Nginx配置文件，开始进行配置：

      # 前端静态文件 + 后端接口代理配置server {# 监听端口（根据需求调整，如 80、8080，确保未被占用）listen       81;# 绑定的域名或 IP（替换为你的服务器公网 IP 或域名）server_name  124.220.90.82;# 字符集（按需启用，如前端是中文，可设为 utf-8）# charset koi8-r;# 静态文件配置：直接加载前端打包文件location / {# 前端静态文件目录（替换为你的实际路径）root   /usr/local/nginx/html/staticResource;# 默认首页文件index  index.html index.htm;# 解决 Vue/Router History 模式刷新 404 问题try_files $uri $uri/ /index.html;}# 后端接口代理配置（假设前端请求以 /prod-api 开头）location /prod-api/ {# 后端服务地址（替换为你的实际后端地址，如 Spring Boot 端口 8081）proxy_pass http://124.220.90.82:8081/;# 传递客户端真实 IP 和 Host 头（解决后端获取客户端 IP 异常问题）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_http_version 1.1;proxy_set_header Connection "";}# 错误页面配置（404/50x 等）error_page   404              /404.html;error_page   500 502 503 504  /50x.html;location = /404.html {root   /usr/local/nginx/html/staticResource;}location = /50x.html {root   /usr/local/nginx/html;}}

      4.4.1、配置项详细说明

      1. location /：匹配所有根路径请求

        location / 是 Nginx 中最基础的路由规则，表示匹配所有以 / 开头的请求（即网站的所有访问路径，如 http://域名/、http://域名/about、http://域名/user 等）。

      2. root /usr/local/nginx/html/staticResource;：指定静态文件目录

      • 作用：告诉 Nginx，当请求匹配 location / 时，去 root 配置的目录中查找对应的静态文件（HTML、CSS、JS、图片等）。
      • 举例：
        当访问 http://124.220.90.82/index.html 时，Nginx 会去 /usr/local/nginx/html/staticResource/index.html 查找文件；
        当访问 http://124.220.90.82/css/app.css 时，会去 /usr/local/nginx/html/staticResource/css/app.css 查找。
      • 注意：路径必须准确指向 Vue 项目 npm run build 打包后的 dist 目录（或解压后的实际路径），否则会出现 404 错误。

      3. index index.html index.htm;：设置默认首页

      • 作用：当请求的是一个目录（而非具体文件）时，Nginx 会自动返回 index 配置的文件。
        例如：访问 http://124.220.90.82/（根路径，本质是请求目录）时，Nginx 会默认返回 root 目录下的 index.html。
      • 为什么是 index.html：Vue 项目打包后，dist 目录的入口文件就是 index.html，所有页面内容都通过这个文件动态渲染。

      4. try_files $uri $uri/ /index.html;：解决 Vue Router History 模式的核心

              这是单页应用部署的关键配置，专门解决 Vue Router 使用 history 模式时的刷新 404 问题，逐部分解释：

      • $uri：Nginx 变量，表示当前请求的文件路径。
        例如：请求 http://域名/css/app.css 时，$uri 就是 /css/app.css，Nginx 会先去 root 目录下查找这个文件，如果存在则直接返回。
      • $uri/：表示当前请求的目录路径。
        例如：请求 http://域名/user 时（假设 user 是一个路由，而非实际目录），$uri/ 就是 /user/，Nginx 会检查 root 目录下是否有 user 文件夹，如果存在则返回该文件夹下的 index.html（通常不存在，所以继续下一步）。
      • /index.html：当 $uri 和 $uri/ 都不存在时，直接返回 root 目录下的 index.html。

      为什么需要这行配置？

              Vue 项目使用 history 模式时（路由路径如 /about、/user），这些路径对应的物理文件或目录并不存在（所有内容都由 index.html 通过 JavaScript 动态渲染）。
      如果没有 try_files：

      • 直接访问 http://域名（根路径）：会返回 index.html，正常加载。
      • 刷新 http://域名/about：Nginx 会去查找 /about 文件或目录，发现不存在，直接返回 404 错误。

      有了 try_files 后：

      • 刷新 http://域名/about 时，Nginx 找不到 /about 文件 / 目录，会自动返回 index.html，此时 Vue Router 会根据 URL 中的 /about 动态渲染对应的页面，避免 404。

      1. location /prod-api/：匹配特定前缀的请求

        location /prod-api/ 表示：只处理所有以 /prod-api/ 开头的请求。
      例如：

      • 前端发起的 http://前端域名/prod-api/user/login
      • 前端发起的 http://前端域名/prod-api/article/list

      这些请求会被该规则匹配并处理，其他不以 /prod-api/ 开头的请求（如静态资源请求）则不会进入该规则。

      2. proxy_pass http://124.220.90.82:8081/;：核心代理转发

              这是代理配置的核心，作用是将匹配到的请求转发到指定的后端服务地址。

      • 拆解说明：
        • proxy_pass：Nginx 代理指令，用于指定后端服务的地址。
        • http://124.220.90.82:8081/：后端服务的实际地址（需替换为你的后端 IP: 端口）。
          例如：如果后端服务部署在同一服务器的 8081 端口，就是 http://127.0.0.1:8081/；如果在其他服务器，就是对应的公网 / 内网 IP: 端口。
      • 转发逻辑：
        当天前端请求 http://前端域名/prod-api/user/login 时，Nginx 会自动转发到：
        http://124.220.90.82:8081/user/login（注意：/prod-api/ 前缀被去掉了，因为 proxy_pass 最后有 /）。若 proxy_pass 末尾没有 /（如 http://124.220.90.82:8081），则转发后会保留 /prod-api/ 前缀（即 http://后端地址/prod-api/user/login），需根据后端接口实际路径决定是否加 /。

      3. proxy_set_header：传递客户端信息给后端

              后端服务通常需要获取客户端的真实 IP、请求域名等信息（例如用于日志记录、权限验证），但由于请求经过 Nginx 代理，后端直接获取的会是 Nginx 服务器的 IP，而非真实客户端 IP。这些配置用于解决此问题：

      • proxy_set_header Host $host;
        • $host 是 Nginx 变量，表示客户端请求的域名或 IP（如 124.220.90.82）。
        • 作用：将客户端请求的域名 / IP 传递给后端，确保后端能正确识别请求的来源域名（例如后端有多个域名绑定的情况）。
      • proxy_set_header X-Real-IP $remote_addr;
        • $remote_addr 是 Nginx 变量，表示客户端的真实 IP 地址。
        • 作用：在请求头中添加 X-Real-IP 字段，后端可通过该字段获取客户端真实 IP（例如 Java 中用 request.getHeader("X-Real-IP")）。
      • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        • $proxy_add_x_forwarded_for 是 Nginx 变量，记录请求经过的所有代理服务器 IP，格式为 客户端IP, 代理1IP, 代理2IP...。
        • 作用：当请求经过多层代理时，后端可通过该字段追溯完整的请求路径（常用于复杂网络环境的日志分析）。

      这样前后端项目就都部署完成了，此时我们访问124.220.90.82:8081/便可以出现我们的项目首页了

      http://www.dtcms.com/a/329077.html

      相关文章：

    1. 大致计算服务器磁盘使用情况脚本
    2. 从零到一：TCP 回声服务器与客户端的完整实现与原理详解
    3. pycharm配置连接服务器
    4. 解析Vue3中集成WPS Web Office SDK的最佳实践
    5. 物理服务器和虚拟机在性能上的不同
    6. 【opencv-Python学习笔记（3）：色彩空间类型及其转换】
    7. 【Abp.VNext】Abp.Vnext框架模块学习
    8. 工业元宇宙：迈向星辰大海的“玄奘之路”
    9. TCP客户端Linux网络编程设计详解
    10. docker+nginx+keepalived+openappsec+web ui+crowdsec部署安全代理
    11. IDEA创建一个VUE项目
    12. SVN提交服务器拒绝访问的问题
    13. 服务器硬件电路设计之 I2C 问答（五）：I2C 总线数据传输方向如何确定、信号线上的串联电阻有什么作用？
    14. 从零开始搭建私服务器
    15. opencv：直方图
    16. 【AI论文】GLM-4.5：具备智能体特性、推理能力与编码能力的（ARC）基础模型
    17. Visual Studio Code 跨平台快捷键指南：Windows 与 macOS 全面对比
    18. 第十三节：后期处理：效果增强
    19. 开发避坑指南（24）：RocketMQ磁盘空间告急异常处理，CODE 14 “service not available“解决方案
    20. 2025年，Javascript后端应该用 Bun、Node.js 还是 Deno？
    21. python基于Hadoop的超市数据分析系统
    22. 高防CDN和高防IP的各自优势
    23. Sklearn 机器学习 异常值检测 孤立深林
    24. 《设计模式之禅》笔记摘录 - 15.观察者模式
    25. 【完整源码+数据集+部署教程】军事伪装目标分割系统源码和数据集：改进yolo11-EMSC
    26. 最新去水印小程序系统 前端+后端全套源码 多套模版 免授权
    27. Four.Meme 重大更新：Bonding Curve Cap 从 24 BNB 降至 18 BNB，这意味着什么？
    28. 浏览器面试题及详细答案 88道（23-33）
    29. 【密码学实战】国密SM2算法介绍及加解密/签名代码实现示例
    30. 用了Cursor AI之后，我的编程效率翻倍了？——一位程序员的真实体验分享