Ezzi
← 全部文章
Nginx反向代理负载均衡静态资源前后端分离技术

Nginx是什么？

Nginx有什么用？它在Web系统开发中的地位是怎样的？

Ezzi··8 分钟阅读

更新于 2026.08.07

本文目录 16 节
Nginx是什么？封面

Nginx有什么用？

Nginx是一个支持静态资源托管、反向代理、负载均衡的服务器，以极高的性能和极低的消耗而闻名。在软件开发中，无论是前后端都绕不开Nginx。

静态资源托管

在前后端分离的架构中，Nginx 是存放前端成果的最佳场所。当你运行npm run build后，会生成一堆 HTML、CSS 和 JS 文件。Nginx 可以直接将这些文件呈现给用户，而不需要动用复杂的后端服务器（如 Java 或 Python）。同时，Nginx 专门为处理静态文件进行了优化，响应速度极快，且支持 Gzip 压缩，能显著减少用户下载流量，提升首屏加载速度。

反向代理

反向代理通常是不好理解的。通俗地说，反向代理就像一个“门面接待员”，客户端根本不知道真实的服务器是谁，它只跟代理打交道。反向代理的流程是这样的：

  • 客户端（可以是浏览器、移动端App、桌面软件等）请求代理服务器
  • 代理服务器转发请求到内部真实服务器
  • 客户端收到的响应，好像直接来自代理服务器

你去饭店点餐，你只跟服务员说你要吃啥，服务员去厨房帮你下单，然后把菜端给你。在这个过程中，你 = 客户端，服务员 = 反向代理，厨房 = 后端真实服务器。这种架构可以保护真实的后端服务器地址，使得其更加安全。同时这种架构也天然的实现了支持负载均衡的能力，后端可以有多个服务器，代理帮你分配压力。

负载均衡

负载均衡就像一个 “分流大管家”，帮你把很多人的请求平均分配到多个后端服务器上，避免某一台服务器压力过大。如果饭店生意太火爆，一个厨师忙不过来怎么办？那就多招几个厨师！而 Nginx 就是那个负责分配订单的指挥官。负载均衡（Load Balancing）能将海量的用户请求均匀地分配到多台后端服务器上，避免单台服务器“累死”。

它解决了三个核心痛点：

  1. 单点故障：一台服务器挂了，Nginx 自动把请求转给健康的服务器。
  2. 流量激增：服务器不够用了？再加两台，Nginx 动态分流。
  3. 响应缓慢：根据服务器的负载情况，把请求分给最“闲”的那台。

Nginx提供了三种负载均衡的策略。

1.轮询（默认）

将每个前端请求按时间顺序逐一分配到不同的后端服务器。如果后端服务器挂了，Nginx 会自动将其剔除。

upstream my_server {
    server 192.168.1.10;
    server 192.168.1.11;
}

2.权重

如果你的服务器有的性能强（32核），有的性能弱（2核），轮询就不合适了。通过给每台服务器分配一个 weight 值（权重），权重越高，被分配到的请求比例就越大。适用后端服务器性能不均，需要让“能者多劳”的场景。例如，如果 A 权重为 2，B 权重为 1。那么每 3 个请求中，会有 2 个发给 A，1 个发给 B。

upstream my_server {
    server 192.168.1.10 weight=2; # 性能强
    server 192.168.1.11 weight=1; # 性能一般
}

3.IP Hash

在有些情况下，我们需要用户在某段时间内一直访问同一台服务器（比如利用Session作登录认证的场景）。根据客户端的 IP 地址进行 Hash 计算，得到一个固定值，并将其映射到某台服务器上。只要用户的 IP 不变，他每次都会访问到同一个后端。解决 Session 共享问题。如果你的后端代码没有实现 Session 共享（如 Redis 存储），那么必须用这个策略来防止用户频繁掉线。

upstream my_server {
    ip_hash;
    server 192.168.1.10;
    server 192.168.1.11;
}

HTTPS 安全加密（SSL 卸载）

在今天，没有 HTTPS 的网站会被浏览器标记为“不安全”，Chrome和Edge浏览器都是这么处理的。HTTPS已经成为网站的标配，用于保护信息传输过程中的安全。对HTTP行为进行SSL加解密，是需要配备公私钥证书的。Nginx不仅可以代理我们的SSL证书，还可以进行解密。

如果Nginx仅仅将客户端发来的请求原封不动的发给后端，那么每一台后端都需要配备SSL证书，这样让传输极其麻烦。事实上当请求到达Nginx后面的环节时，我们已经可以信任当前的传输环境。因此可以对SSL进行卸载，通过Nginx将解密的普通HTTP请求转发给后端服务器即可。

这么做不仅可以减少降低管理成本（更新证书只需改 Nginx 一个地方），还可以减轻后端服务器压力（加密和解密是非常消耗 CPU 的，让 Nginx 专门处理这些计算，后端服务器可以专心跑业务逻辑）。

防刷限流

如果突然有恶意爬虫抓取你的数据，或者遭受小规模攻击，Nginx 可以作为第一道关卡限流（limit_req_zone、limit_req）。同时，Nginx搭配GeoIP等服务可以进行IP地址层面的封禁。如果你的网站不计划对某个地区开放（或者只对某个地区开放），你可以通过这些可拓展的模块简单的实现这些功能。

Gzip压缩

Nginx 在把 HTML、CSS、JS 文件发给浏览器之前，先在服务器上进行压缩（类似打包成 .zip）。浏览器收到后会自动解压。原本 1MB 的 JS 文件，经过 Gzip 压缩后可能只有 200KB，传输速度提升 5 倍，这就是Gzip的强大之处。

简单入门Nginx——在你的Windows上使用Nginx

Nginx使用最多的场景是在服务器上，这些服务器通常是Linux系统。在Windows上对Nginx简单入门即可。 先下载nginx/Windows，然后下载好的 .zip 文件解压到你的电脑上。

注意：解压路径最好不要包含中文，尽量将nginx配置在D:\Nginx这种简单的目录即可。

打开终端工具，找到与nginx.exe相同的路径，如下：

目录介绍

1.conf —— 配置 这是 Nginx 最核心的目录，决定了 Nginx 如何工作。nginx.conf是其中最重要的文件，主配置文件，所有的监听端口、转发规则、负载均衡策略都在这里写。2. html —— 资源区（仓库） 这是 Nginx 默认的静态资源存放目录。当你访问 localhost 时，Nginx 默认就会来这里找文件。通常包含 index.html（首页）和 50x.html（报错页面）。3. logs —— 日志 error.log：错误日志。如果 Nginx 启动失败或运行报错，一定要看这个文件。 access.log：访问日志。记录了谁在什么时候访问了什么路径。 nginx.pid：记录当前运行的 Nginx 进程 ID。4. temp —— 临时中转站 这个目录由 Nginx 自动创建，用于存放处理大请求时的临时数据。 client_body_temp：客户端上传大文件时的临时存储。 proxy_temp：反向代理时的临时缓存。 注意：这个文件夹里的内容可以清理，但文件夹本身建议保留。5. contrib & docs ——工具与文档 contrib：包含一些实用的辅助工具。 vim：如果你在 Linux 下用 Vim 编辑 Nginx 配置，把这里的插件拷贝过去可以实现代码高亮（Windows 用户通常可以忽略）。 docs：存放官方文档、开源协议和更新日志（如 CHANGES）。

启动

双击nginx.exe即可，nginx会自动在后台启动。这时候打开浏览器，输入http://localhost，如果打开的页面是“Welcome to Nginx”，就说明你的配置成功了。这时候你可以把html目录中的文件更换成你自己的网页文件，你就能看到变化了。

Nginx的指令与配置

以下是一份比较全的配置。

# --- 全局块 ---
worker_processes  1; # 启动进程数，通常设置成和 CPU 核心数一致

events {
    worker_connections  1024; # 每个进程允许的最大连接数
}

# --- HTTP 块 ---
http {
    include       mime.types;     # 核心：支持解析 CSS/JS/图片等各种文件类型
    default_type  application/octet-stream;

    # 性能优化：开启高效文件传输模式
    sendfile        on;
    keepalive_timeout  65;

    # 性能优化：开启 Gzip 压缩，让网页加载更快
    gzip  on;
    gzip_types text/plain text/css application/json application/javascript text/xml;

    # --- Server 块 (虚拟主机配置) ---
    server {
        listen       80;         # 监听端口
        server_name  localhost;  # 访问地址，本地测试用 localhost

        # 1. 静态前端资源配置
        location / {
            root   html;               # 对应 Nginx 目录下的 html 文件夹
            index  index.html index.htm;
            # 关键：解决 Vue/React 等单页面路由刷新 404 的问题
            try_files $uri $uri/ /index.html;
        }

        # 2. 后端 API 反向代理
        # 当访问 http://localhost/api/login 时，会被转发到 http://127.0.0.1:8080/login
        location /api/ {
            # 将 /api/xxx 重写为 /xxx
            # break 表示重写后停止匹配，直接执行后续的 proxy_pass
            rewrite ^/api/(.*)$ /$1 break;
            proxy_pass http://127.0.0.1:8080;
            # 透传客户端真实信息，防止后端拿到的 IP 全是 Nginx服务器的地址
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

        # 3. 错误页面重定向
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

同时，Nginx提供了一些指令。 nginx -t：语法检查。当你修改了Nginx的某个配置文件，可以通过此命令来检查配置是否有误，语法是否正确。 nginx -s reload：热加载，不重启服务直接生效配置。 nginx -s stop：快速停止。

多站点配置与 URL 转发

多站点配置（虚拟主机）

你只有一台服务器，但你有两个域名 a.com 和 b.com。Nginx 可以根据用户访问的域名不同，将请求分发到不同的文件夹或后端服务。在 http 块中定义多个 server 块即可。

http {
    # 站点 A：静态博客
    server {
        listen       80;
        server_name  www.a.com;
        location / {
            root   html/blog;
            index  index.html;
        }
    }

    # 站点 B：官方商城
    server {
        listen       80;
        server_name  www.b.com;
        location / {
            root   html/shop;
            index  index.html;
        }
    }
}

URL 转发（重定向）

你的项目的真实域名比较独特，为了防止别人记混，你特意多买了几个域名，将这些域名发到实际的域名；又或者是你为网站配备了HTTPS证书，要强制将HTTP的访问改为HTTPS访问等等。

server {
    listen 80;
    server_name blog.ezzi.asia;
    return 301 https://blog.ezzi.asia$request_uri;
}

前后端分离

前后端分离是当下 Web 开发的主流范式，它把“浏览器里跑的东西”和“服务器上跑的东西”彻底解耦，让两拨人可以独立迭代、独立部署。

在经典耦合时代，任何Web请求后需要后端服务器来处理。浏览器将请求发送给服务器后，服务器根据HTML模板，再从DB中查询数据拼接HTML返回给浏览器，这种架构开发起来相当麻烦。首先，任何微小的UI改动都要重新打包和发布War（Jar）。其次，横向扩容时，静态流量也要走 Tomcat，浪费计算。况且这样将前后端的代码都堆在一个工程里，给开发带来了相当大的挑战。

前后端分离不仅是一种架构模式，而且是一种开发模式。在这种开发方式下，前后端可以独立开发、独立部署、独立发布，前后端通过“接口”连接起来。这样，前端可以用CDN等静态资源托管加快访问速度，后端可以随意使用任何技术栈和框架，后端只要保证能够接收前端发送的请求和生成对应的JSON即可。

结语

学习不易，一起坚持，共勉之~

评论