Appearance
Nginx
这里主要整理 Nginx 这条线。比起上来就看零散配置，我更想把它在系统里到底扮演什么角色讲清楚：
Nginx是什么- 它在系统架构里通常放在哪一层
- 它最常解决什么问题
- 哪些能力属于它的核心使用场景
- 工程上最常见的边界和误区是什么
Nginx 可以看成一个站在客户端和后端服务之间的入口层组件，负责接请求、分发流量、做代理、处理静态资源，也经常顺手把 HTTPS 一起接住。
这里先说一个很容易混的点：
Nginx 既可以作为 Web 服务器 使用，也可以作为 反向代理服务器 和 网关入口 使用。
工程里最常见的语境，通常不是“拿它写业务”，而是“把它放在系统入口做流量治理”。
1. 为什么很多系统前面都会放一个 Nginx
如果浏览器直接访问后端应用服务，会很快遇到这些问题：
- 静态资源谁来分发
- 多台后端实例怎么统一对外暴露
- HTTPS 证书放在哪里管理
- 接口路径怎么路由到不同服务
- 缓存、压缩、跨域这些能力放在哪一层最合适
这就是 Nginx 经常出现的原因。
简单说，它就是在业务服务前面加一层统一入口，把流量接入、代理转发、静态交付和性能优化这类事情集中处理掉。
2. Nginx 最常见的几种角色
2.1 Web 服务器
这里的 Web 服务器 可以理解成 专门接收 HTTP 请求并返回页面、文件或接口响应的一类服务器程序。
Nginx 作为 Web 服务器时，常见任务包括：
- 返回静态页面
- 分发前端构建产物
- 提供图片、脚本、样式文件
2.2 反向代理
反向代理 可以理解成 客户端先访问代理层，再由代理层把请求转发给后端真实服务。
它解决的是：
- 隐藏后端真实地址
- 统一入口
- 把路径转发到不同服务
- 配合负载均衡分发流量
这也是 Nginx 在后端架构里最常见的角色。
2.3 负载均衡入口
负载均衡 可以理解成 把请求按某种策略分散到多台后端实例上。
它解决的是：
- 单机压力过大
- 后端多实例如何统一对外服务
- 某台实例故障时如何提升可用性
2.4 HTTPS 终止层
HTTPS 终止 指的是：浏览器和 Nginx 之间使用 HTTPS，加密在 Nginx 这一层完成，然后再由 Nginx 转发给后端服务。
它的价值在于：
- 统一证书管理
- 简化后端 TLS 配置
- 更适合作为统一接入层治理
3. 一条请求经过 Nginx 时通常会发生什么
可以用一条简单链路理解：
- 浏览器发起请求
- 请求先到 Nginx
- Nginx 根据
server和location规则匹配 - 如果是静态资源，直接返回文件
- 如果是动态请求，代理到后端应用
- 如果配置了缓存、压缩、HTTPS 或跨域处理，也会在这一层生效
这里的 server 可以看成 Nginx 中按域名或端口划分的一组站点级配置。
这里的 location 可以理解成 Nginx 中按 URL 路径做规则匹配和处理的一组路由规则。
4. Nginx 最值得优先掌握的几条能力线
4.1 反向代理
这是最核心的一条主线。
典型场景：
/api转发给 Java 或 Node 服务/admin转发给后台管理服务/直接返回前端页面
4.2 负载均衡
当后端不止一台机器时，Nginx 可以按策略分发请求。
常见策略包括：
- 轮询
- 加权轮询
IP Hash- 最少连接
4.3 静态资源交付
Nginx 很适合处理：
- HTML
- CSS
- JavaScript
- 图片
- 字体文件
这条主线通常会和前端构建产物、缓存头、压缩和 CDN 一起出现。
4.4 缓存与压缩
它们解决的是：
- 响应体过大，传输慢
- 静态资源频繁重复请求
- 源站压力过高
4.5 HTTPS 与安全入口
这条主线主要关注：
- 证书配置
- HTTP 跳转 HTTPS
- TLS 终止
- 常见安全响应头
5. 正向代理和反向代理到底有什么区别
这是理解 Nginx 时最容易混的概念之一。
| 对比项 | 正向代理 | 反向代理 |
|---|---|---|
| 代理谁 | 代理客户端 | 代理服务端 |
| 客户端是否知道目标服务 | 通常知道 | 不一定知道后端真实实例 |
| 常见场景 | 企业代理、访问外部资源 | 网站入口、API 网关、流量转发 |
| 工程里和 Nginx 的关系 | 可做，但不是最常见语境 | 是最常见语境 |
可以这样记：正向代理更像帮客户端出去访问，反向代理更像帮服务端统一接请求。
6. 哪些问题最适合放在 Nginx 这一层解决
更适合放在 Nginx 的，通常是这些问题：
- 静态资源分发
- 请求转发与路径路由
- 多实例负载均衡
- HTTPS 证书统一管理
- gzip、缓存头、跨域等通用接入层能力
不太适合放在 Nginx 的，通常是：
- 复杂业务编排
- 重业务状态处理
- 核心业务鉴权逻辑的全部细节
- 数据查询与业务计算
也就是说，Nginx 更适合做 流量接入层问题，而不是把它变成承载复杂业务逻辑的应用层。
7. 当前目录下的专题
推荐阅读顺序：
- 看这篇总览，建立 Nginx 的整体定位
- 再看“反向代理与负载均衡”，理解它如何接流量和分发流量
- 最后看“静态资源、缓存与 HTTPS”，理解它如何提升交付效率和统一入口治理
8. 常见误区
8.1 误区一：把 Nginx 只理解成“能访问网页的服务器”
这太窄了。工程里更常见的理解是：它是统一接入层的一部分。
8.2 误区二：以为用了 Nginx 就天然高可用
Nginx 可以提升流量治理能力，但如果入口层自己只有一台机器，它本身也可能成为单点。
8.3 误区三：把所有逻辑都堆进 Nginx 配置
Nginx 适合做规则明确、偏基础设施层的问题。
如果把太多复杂业务判断塞进去，配置会变得难维护。
9. 一句话总结
Nginx 最值得先建立的认知不是“某条配置指令怎么写”，而是：
它为什么站在系统入口、它解决哪些接入层问题、哪些能力应该放在这一层、哪些问题又不该放到这一层。