【每天一个小笔记】01 Nginx初解

最新推荐文章于 2025-11-30 22:23:34 发布

原创最新推荐文章于 2025-11-30 22:23:34 发布 · 866 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#笔记 #nginx #运维

Nginx 专栏收录该内容

1 篇文章

订阅专栏

什么是Nginx

Nginx 是一款开源的高性能 HTTP 服务器、反向代理服务器，同时支持 IMAP/POP3/SMTP 代理功能。

核心特点

高性能高并发：采用事件驱动架构，单台服务器可支持数万并发连接，资源占用低。
多功能性：兼具反向代理、负载均衡、静态资源服务、缓存、SSL 终端等功能。
稳定性强：核心代码简洁，运行可靠，故障率低，适合长期稳定运行。
跨平台与轻量化：支持 Linux、Windows 等系统，安装包小，配置简单易维护。

主要应用场景

静态资源服务：直接处理 HTML、CSS、JS、图片等静态文件，效率远超应用服务器。
反向代理与负载均衡：接收客户端请求，转发至后端应用服务器（如 Tomcat、Node.js），并分配请求压力。
HTTP 缓存：缓存后端响应内容，减少重复请求，提升访问速度。
SSL/TLS 终端：处理 HTTPS 加密解密，减轻后端服务器负担。
限流与访问控制：通过配置限制请求频率、IP 黑白名单等，保障服务安全。

Nginx理解历程

最初对于Nginx的理解

一开始我对Nginx的理解就是一个用来部署软件的服务器，仅局限于认为它是一种能够用来部署软件的服务器。所以开始的时候，我的前端请求全部都是在前端本身就写好的，Nginx仅仅充当了一个提供前端显示的一个网址路径，主要的通信还是在前端和后端之间。也就是下面这样的nginx配置：

server {
    listen 7994;
    server_name 192.168.0.130;

    root /home/user/AIclient;  # 确认指向 dist 目录

    location / {
        autoindex off;  # 关闭目录列表
        try_files $uri $uri/ /index.html;  # 解决路由 404

        include mime.types;
        default_type application/octet-stream;

        # 禁用缓存（可选）
        add_header Cache-Control "no-store, no-cache, must-revalidate";
        add_header Pragma "no-cache";
    }
}

一句话结论：它的核心作用是「部署前端静态资源 + 支持 SPA 路由」，和 “代理” 没有半毛钱关系～

Nginx常规配置示例

而常规的Nginx配置示例是下面这样的，将请求转发到本地8080端口的应用服务器：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里可以看到在代码里面有一行proxy_pass http://localhost:8080;

“proxy_pass” 表示将请求代理转发到指定的地址，这里
“http://localhost:8080” 指定了转发的目标地址为本地（localhost）的 8080 端口。

整句话意思是，当服务器接收到符合相关配置规则的请求时，会把该请求代理转发到本地运行在 8080 端口的服务上，比如本地启动的某个 Web 应用程序，使得客户端看起来像是直接访问到了这个 8080 端口的服务。

如果按照我先前的写法，在前端的请求路径必须是http://localhost:8080/API/XXXX这样写,而采用代理的方法则只需要/API/XXXX这样的写法即可，Nginx会帮我们进行转发。

对于Nginx的疑问

当时我就有一个疑问，为什么要这么复杂呢，直接前端请求发后端不就行了吗？还要Nginx转发，Nginx不会压力很大吗？前端直接发送不是减少了服务器压力吗？

询问了AI之后得到了答案：

这个疑问特别关键！核心结论先给你：“前端直接请求后端” 只适合简单场景，Nginx 转发看似多了一步，实则是 “用微小压力换稳定性、安全性、扩展性”，而且 Nginx 的压力远没你想的大。

咱们分 3 点把逻辑说透，你就明白为什么需要 Nginx 了：

一、先回答：为什么不能 “前端直接请求后端”？（核心是解决跨域和安全问题）

你初始的写法（前端直接写http://localhost:8080/API/XXX），在本地开发、或者前后端部署在同一域名 + 同一端口时没问题，但一旦到了真实生产环境，基本走不通，因为两个核心障碍：

1. 跨域限制（浏览器的 “安全洁癖”）

浏览器有个 “同源策略”：如果前端部署在http://example.com:7994（Nginx 的地址），后端在http://example.com:8080（哪怕域名相同，端口不同），前端直接发请求会被浏览器拦截 —— 浏览器认为 “不同端口 = 不同源，可能有安全风险”，直接拒绝接收后端响应。

这时候 Nginx 的作用就来了：前端只需要发请求给同一源的 Nginx（比如/API/XXX），再由 Nginx 转发给后端（8080端口）。因为 Nginx 是 “服务器之间的通信”，不受浏览器跨域限制，相当于帮前端 “搭桥”，规避了跨域问题。

2. 安全风险（暴露后端真实地址 = 引狼入室）

如果前端直接写后端的真实地址（比如http://192.168.0.130:8080），攻击者通过浏览器开发者工具就能看到后端的 IP 和端口，然后针对性发起攻击（比如暴力破解、DoS 攻击）—— 后端直接暴露在公网，风险极高。

而用 Nginx 转发时，前端只能看到 Nginx 的地址（比如example.com），后端的真实地址（localhost:8080）是 “隐藏” 在 Nginx 后面的，攻击者根本看不到，相当于给后端加了一层 “防护盾”。

二、再回答：Nginx 转发会压力很大吗？（其实压力极小，几乎可以忽略）

你担心 “多了一层转发就多了压力”，这个顾虑很合理，但 Nginx 的设计天生就是为了 “扛压力”，而且它转发请求的方式特别 “轻量化”：

1. Nginx 是 “反向代理神器”，转发成本极低

Nginx 的核心优势就是高性能、低消耗—— 它是用 C 语言写的，采用 “事件驱动” 模型，能同时处理几十万甚至上百万的并发连接，而每个转发请求的 CPU 和内存消耗几乎可以忽略（简单理解：Nginx 只是 “传递消息”，不做复杂计算）。

举个直观的例子：后端 Java 服务（比如 Spring Boot）处理 1 万个并发请求可能需要占用几 G 内存，而 Nginx 处理同样 1 万个转发请求，可能只需要几十 M 内存 —— 两者根本不是一个量级的 “压力水平”。

2. 对比：前端直接请求反而可能让后端压力更大

如果没有 Nginx，后端不仅要处理业务逻辑（比如查数据库、计算数据），还要直接接收所有前端的静态资源请求（比如 JS、CSS、图片）—— 这些静态资源请求占比可能高达 80% 以上，会占用后端的连接数和 CPU 资源，导致后端 “忙不过来”，处理业务请求的速度变慢。

而 Nginx 处理静态资源的效率是后端服务的几十倍（Nginx 专门优化过静态文件传输），把静态资源请求都拦下来自己处理，只把 “真正需要后端计算” 的 API 请求转发给后端，相当于给后端 “减负”，让后端能专注处理核心业务，整体系统的压力反而更小。

三、额外福利：Nginx 转发还能解决很多 “麻烦事”，这才是它的核心价值

除了跨域和安全，Nginx 还能帮你搞定很多后端不好处理的问题，这些功能让系统更稳定、更易维护：

功能作用是什么？
负载均衡如果后端有多个服务器（比如 3 个 8080 端口的服务），Nginx 会自动分发请求，避免单个后端过载
缓存静态资源图片、JS、CSS 这些不变的文件，Nginx 会缓存起来，下次不用再找后端要，速度更快
限流 / 熔断万一有恶意请求（比如一秒发 1 万次），Nginx 可以直接拦截，不让后端被打垮
SSL 终止给网站加 HTTPS（绿色小锁），Nginx 负责解密 HTTPS 请求，后端不用管复杂的加密逻辑
路径重写比如前端写/v1/API，Nginx 可以悄悄改成/API转发给后端，前后端路径规则不用对齐

总结一下：什么时候可以 “前端直接请求后端”？什么时候必须用 Nginx？

可以直接请求：本地开发、小项目（只有几个人用）、前后端部署在同一域名 + 端口（无跨域）、不担心安全风险。
必须用 Nginx：生产环境、需要跨域、担心后端安全、需要负载均衡 / 缓存 / HTTPS、系统要扩展（比如以后加更多后端服务器）。

简单说：Nginx 不是 “多余的步骤”，而是整个系统的 “流量入口网关”—— 用极小的转发压力，换来了安全、稳定、可扩展的架构，性价比极高。

如果你的项目以后要上线，或者用户变多，Nginx 这层 “转发” 就是必须的；如果只是自己本地用，怎么简单怎么来就行～

功能	作用是什么？
负载均衡	如果后端有多个服务器（比如 3 个 8080 端口的服务），Nginx 会自动分发请求，避免单个后端过载
缓存静态资源	图片、JS、CSS 这些不变的文件，Nginx 会缓存起来，下次不用再找后端要，速度更快
限流 / 熔断	万一有恶意请求（比如一秒发 1 万次），Nginx 可以直接拦截，不让后端被打垮
SSL 终止	给网站加 HTTPS（绿色小锁），Nginx 负责解密 HTTPS 请求，后端不用管复杂的加密逻辑
路径重写	比如前端写`/v1/API`，Nginx 可以悄悄改成`/API`转发给后端，前后端路径规则不用对齐

跨域问题

Nginx 的代理功能还能解决跨域问题 —— 如果前端和后端不在同一域名 / 端口，直接通信会触发浏览器跨域限制，而通过 Nginx 代理，前端请求先发给 Nginx（同域名 / 端口），再由 Nginx 转发给后端，就能规避跨域。因为先前我的前后端都是自己的，所以先前我解决跨域问题都是通过在后端配置允许跨域访问的前端ip来解决跨域问题，但是后面需要访问其他的后端导致的跨域让我有点抓瞎，这才让我想起来用Nginx进行代理，才有了这次的进一步了解Nginx。

后端代理，后端反向代理，前端代理，前端反向代理

在了解的过程中，我接触到了各种代理，后端代理，后端反向代理，前端代理，前端反向代理，把我整个人的整懵圈了，所以对这几个代理进行了一个了解，

后端代理

打个比方，你在公司是 “技术部A组”（对应后端A服务器），要找 “技术部 B 组”（对应后端 B 服务器）要一份数据，但公司规定 “不能直接找 B 组”，必须先找 “行政中转岗”（对应后端代理服务器）。你把需求告诉行政（代理服务器发起请求），行政拿着需求去找 B 组要数据，B 组把数据给行政，行政再转交给你 —— 这个 “行政中转岗”，就是后端代理。

这里的行政中转岗就可以是Nginx，它可以进行一个后端的代理，把一个后端的请求转发给另一个后端

后端反向代理

员工（用户 / 前端客户端）想去 “大公司总部” 办事（访问网站 / APP 的后端服务），走到公司门口，先遇到 “前台接待员”（后端反向代理服务器，比如 Nginx）。

你不用知道公司里面谁负责干活（不用知道真实后端服务器的地址），只需要把需求告诉前台就行。

前台看了下需求：如果是要拿宣传册（静态资源，比如图片、网页），前台自己就有，直接给你，不用喊里面的人（Nginx直接自己处理了）；如果是要办复杂业务（动态请求，比如查订单、提交表单），前台自己找到 “对应部门的员工”（真实后端服务器，比如 Tomcat、Node.js）办事。

对应部门的员工办完事后，把结果交给前台，前台再转交给你 —— 你从头到尾都只和前台打交道，根本不知道里面的员工是谁、在哪个位置

这个就是后端反向代理

前端代理

疫情期间被居家的员工A（内网环境的用户）需要进行一些外出的工作，但是没有办法出去，于是找到公司的 “外事专员”（前端代理服务器，比如 Squid、或开发时用的 webpack-dev-server，nginx 也能简单实现）替你去你要去的 “外部机构”（目标服务器，比如百度、淘宝的服务器，或你公司的后端接口服务器）。帮你把你要的东西带回来，整个流程（全程围绕你 “前端” 展开）

这样看起来好像跟后端反向代理非常相似。

终极一句话区别（记死不混）

前端代理：前端自己访不了，找中间人 “替自己访”；
后端反向代理：前端能访，但不用访后端，让中间人 “替后端接访”。

前端反向代理

我了解到其实没有 “前端反向代理” 这个严格的技术定义，咱们常说的 “前端里的反向代理”，本质是开发者在前端开发环境或部署流程中，用代理工具实现的反向代理逻辑，它本质还是反向代理，只是应用场景围绕前端需求展开。比如前端本地开发时运行在localhost:3000，后端接口在localhost:5000，浏览器的同源策略会阻止跨域请求。这时配置的代理就像 “伪装的同事”，前端以为在调用自身域名下的接口，实际代理悄悄把请求转发给了后端服务器。

结尾补充

HTTP服务器

HTTP 服务器是一种遵循 HTTP（超文本传输协议） 规则，专门处理客户端（如浏览器、手机 App）请求，并返回网页、图片、视频等资源的软件（或软件 + 硬件的组合）。它是实现 “用户访问网站” 这一行为的核心角色，本质是 “接收请求、处理请求、返回结果” 的中间枢纽。

简单理解：当你在浏览器输入网址（如 www.baidu.com）并回车时，浏览器会向目标服务器发送 HTTP 请求，而 HTTP 服务器 就是接收这个请求的 “接待员”—— 它会找到你要的资源（比如百度首页的 HTML 文件），再通过 HTTP 协议把资源送回浏览器，最终让你看到网页内容。

其核心功能包括：