Nginx 两个最常见的用法：静态站点部署和反向代理转发

对后端开发来说，Nginx 最常见的价值其实就两类：

托管静态站点
做反向代理

把这两件事理顺了，大多数个人项目和中小型系统的入口层配置就已经够用了。

先说结论

如果你正在维护个人博客或小型后端项目，可以先把 Nginx 理解成：

一个高性能静态文件服务器
一个对外统一入口

它既可以直接把 HTML、CSS、JS 返回给浏览器，也可以把请求继续转发给后端服务。

一、场景一：静态站点部署

像 VitePress 这种站点，构建产物本质上就是一堆静态文件。

这时 Nginx 最适合做的事情就是：

对外监听 80 或 443
从指定目录读取页面文件
把请求返回给浏览器

一个最小配置示例：

nginx

server {
    listen 80;
    server_name _;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri.html $uri/ =404;
    }
}

这里的 try_files 对 VitePress 很关键，因为开启 cleanUrls 后，请求路径经常不直接带 .html。

二、场景二：反向代理后端服务

如果 Nginx 后面还有 Spring Boot、网关、Node 服务，就可以通过反向代理把请求转发出去。

例如：

nginx

server {
    listen 80;
    server_name api.example.com;

    location / {
        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_pass http://127.0.0.1:8080;
    }
}

它的作用是：

浏览器请求先到 Nginx
Nginx 再转给后端服务
后端服务不必直接暴露给公网

三、为什么经常要补 proxy_set_header

很多代理问题其实不是“转发失败”，而是转发后请求头变了。

例如后端可能依赖：

Host
客户端真实 IP
转发链路信息

所以反向代理时经常会补这些头：

Host
X-Real-IP
X-Forwarded-For

这对日志、鉴权、回调地址生成都很有帮助。

四、放到当前知识库站点，这篇配置怎么落地

如果对照你现在这套线上结构，可以简单理解成：

text

443 子域名入口 -> Nginx server block -> /usr/share/nginx/html/mumu-wiki

也就是说，对 VitePress 站点来说，Nginx 最关键的几件事是：

server_name 对上子域名
root 指向正确静态目录
try_files 兼容 cleanUrls
HTTPS 证书路径正确

如果这几步没配对，即使构建产物已经同步到服务器，线上看起来也可能像“文章丢了”。

五、一个更贴近实际的站点入口结构

很多项目最终都会长成这种结构：

text

浏览器 -> Nginx -> 静态前端
浏览器 -> Nginx -> API 网关 / Java 服务

Nginx 的意义就在于把“对外入口”和“内部服务”隔开。

六、Nginx 配置里最值得优先理解的几个块

server

一个 server 基本就代表一组站点入口规则。

location

定义不同请求路径怎么处理。

root

静态文件根目录。

proxy_pass

代理转发目标地址。

七、几个高频问题

1. 页面能打开，但刷新子路径 404

常见原因是静态路由和文件路由没配好。

对 VitePress 这类静态站点，通常要重点检查：

root
index
try_files

2. 反向代理后后端拿不到真实域名和 IP

优先检查是否补了：

proxy_set_header Host $host
proxy_set_header X-Real-IP $remote_addr

3. 改了配置但没生效

先测配置：

bash

nginx -t

再重载：

bash

nginx -s reload

如果是 Docker 里的 Nginx，就要进入容器或重启容器执行对应动作。

4. 本机 curl 正常，但线上子域名不对

这类问题常见在多站点共用一个 Nginx 时。

要优先确认：

server_name 是否匹配当前域名
443 默认站点是不是把请求吃掉了
你验证时是不是直接用 127.0.0.1/，而不是带真实 Host

多子站场景下，校验最好直接走真实域名链路。

八、个人博客场景下的推荐思路

对你的博客场景，更推荐的组合是：

VitePress 负责生成静态页面
Nginx 负责对外提供访问
内容目录、配置目录通过宿主机挂载出来

这样做的好处是：

页面发布路径清晰
Nginx 配置和站点文件都便于维护
后续加 HTTPS、反向代理接口也更方便

如果你现在维护的是这套知识库，比较实用的理解顺序是：

先把静态站点托管跑通
再补 HTTPS
最后再决定是否代理后台或 API 服务

这样每一层问题都会更好拆。

一句话总结

Nginx 最值得先掌握的两件事，就是“把静态文件稳稳地发出去”和“把动态请求稳稳地转进去”。

对个人知识库和后端项目来说，这两类能力基本就是最核心的入口层能力。

Nginx 两个最常见的用法：静态站点部署和反向代理转发 ​

先说结论 ​

一、场景一：静态站点部署 ​

二、场景二：反向代理后端服务 ​

三、为什么经常要补 proxy_set_header ​

四、放到当前知识库站点，这篇配置怎么落地 ​

五、一个更贴近实际的站点入口结构 ​

六、Nginx 配置里最值得优先理解的几个块 ​

server ​

location ​

root ​

proxy_pass ​

七、几个高频问题 ​

1. 页面能打开，但刷新子路径 404 ​

2. 反向代理后后端拿不到真实域名和 IP ​

3. 改了配置但没生效 ​

4. 本机 curl 正常，但线上子域名不对 ​

八、个人博客场景下的推荐思路 ​

一句话总结 ​