目录
一、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.gz2.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/member
index 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; # 测试端口2
location / {
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 时：
location匹配到/img/- 拼接路径：
/var/www/static（root） +/img/（location 匹配的路径） +logo.png（请求的文件名） - 实际查找的文件：
/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 时：
location匹配到/img/，但这个路径会被alias替换- 拼接路径：
/var/www/static/image/（alias） +logo.png（请求中/img/之后的部分） - 实际查找的文件：
/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、为什么需要动静态分离？
- 减轻应用服务器压力：
静态资源访问频率高（如首页图片、样式表），若全部由处理动态逻辑的应用服务器承担，会占用其 CPU / 内存资源，影响动态请求的响应速度。 - 提升静态资源加载速度：
Nginx 处理静态资源的效率远高于应用服务器（底层基于异步非阻塞 IO，适合高并发静态文件读取），且可配合浏览器缓存、CDN 进一步加速。 - 便于缓存和扩展：
静态资源可设置长期缓存策略，或通过 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;
}
}五、配置说明
后面部署实例有更加详细的解释
- 静态资源处理（
location /static/）：
- 当用户请求
http://example.com/static/css/style.css时，Nginx 会直接读取服务器上的/usr/share/nginx/static/css/style.css文件并返回。 try_files $uri =404：若请求的静态文件不存在，直接返回 404 错误，避免转发到后端服务器。
- 动态资源处理（
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）二进制包安装
- 操作方式：
-
- 下载预编译的二进制包（通常为
.tar.gz格式），使用tar -xvzf 文件名解压。 - 解压后可直接使用（无需编译），文件集中在解压目录内。
- 下载预编译的二进制包（通常为
- 与源码编译安装的核心区别：
- 二进制包解压后不会自动复制到系统指定目录，需手动处理（如直接在解压目录运行，或手动复制到
/usr/local/等路径）。 - 无源码文件，无需
configure、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/便可以出现我们的项目首页了