什么是反向代理？架构、优势和常见使用场景

所谓反向代理，是指在客户端请求到达一个或多个后端服务器之前接收这些请求的服务端中间节点。

在客户端看来，反向代理就是目标。在幕后，它可以选择后端、转发请求、接收后端响应，再将该响应返回给客户端。在 HTTP 术语中，RFC 9110 将网关（也称为反向代理）描述为在面向客户端的连接上表现得像源站服务器、并将请求转发到其他一个或多个服务器的中间节点。

这个定义很重要，因为反向代理首先是一种架构角色，而不是某个特定的协议或产品。NGINX、HAProxy、云负载均衡器或边缘服务部署在应用程序前方时，都可以承担反向代理功能。

简要解答

反向代理位于后端服务器前方，代表后端处理来自客户端的入站流量。

典型的请求路径如下：

1. 客户端连接到公共主机名。

2. 反向代理接受连接。

3. 代理应用路由、安全、缓存或负载均衡规则。

4. 代理向选定后端建立或复用一条独立连接。

5. 后端响应经过代理返回客户端。

部署反向代理的常见原因包括：

• 将流量分配到多个应用服务器；
• 在受控的边缘终止 TLS；
• 将不同的主机或路径路由到不同服务；
• 缓存选定的响应；
• 避免后端拓扑结构直接暴露；
• 集中实施访问控制、速率限制、日志记录或安全检查。

这些能力都不会自动具备。反向代理只会提供你配置的功能，而不当的路由、请求头、缓存、重试或 TLS 设置可能引入新的故障模式。

什么是反向代理？

反向代理代表连接的服务端一侧。

客户端不会直接选择后端服务器。DNS 和网络路由会将客户端引导到反向代理，使其成为面向公众的端点。随后，代理决定请求应该发往何处。

因此，“反向”这个词可能令人困惑。网络流量本身并不是在字面上被反转。这个名称反映的是代理代表哪一侧：

• 正向代理代表一个或多个客户端向外建立连接；
• 反向代理在客户端向内建立连接时，代表一个或多个服务器。

反向代理如何工作

理解反向代理架构最有效的方式，是将面向客户端的连接与后端连接分开看待。

1. 客户端到达公共端点

浏览器、移动应用、API 客户端或其他用户代理解析服务主机名，然后连接到反向代理层公开的地址。

客户端可能并不知道私有后端地址，甚至不知道有多少个后端服务器。

2. 反向代理接受请求

代理可以检查其所在层可获取的信息，例如：

• 主机名；
• URL 路径；
• HTTP 方法；
• 请求头；
• 来源连接的详细信息；
• TLS 连接属性。

随后，它可以应用路由或策略规则。

3. 代理选择后端

请求可以始终发往同一个应用服务器，也可以由代理从后端池中选择目标。

NGINX 文档介绍的负载均衡方法包括轮询、最少连接和 IP 哈希路由。其他产品提供的算法、权重、健康检查或服务发现集成可能不同。

4. 代理创建后端请求

后端请求不一定与客户端请求逐字节完全相同。

反向代理可以：

• 重写或添加请求头；
• 更改后端主机或端口；
• 规范化路径；
• 缓冲请求或响应；
• 在受支持的情况下选择不同的上游协议。

例如，NGINX 的反向代理文档介绍了用于控制发送到上游服务器的请求头的 proxy_set_header。

5. 响应经过代理返回

后端将响应发送到反向代理。代理可以直接转发响应、缓存响应、修改特定响应头、压缩响应，或执行其他已配置的行为，然后再将响应发送给客户端。

反向代理与正向代理

正向代理和反向代理都是中间节点，但它们分别部署在连接的不同一侧。

因此，正向代理并不只是一个指向相反方向的反向代理。两者的信任模型、运营方、路由决策和部署目标都不同。

反向代理架构：重要层次

生产环境中的反向代理设计通常不止一个概念层次。

公共端点

这是客户端可以访问的主机名和网络地址。

对于边缘服务，DNS 可以将公共主机名路由到供应商的网络。Cloudflare 文档说明，启用代理的 DNS 记录会让 HTTP/HTTPS 流量先经过 Cloudflare，再到达源站。

反向代理或网关层

入站连接在这一层终止，路由决策也在这一层作出。

根据产品和配置的不同，这一层还可能处理：

• TLS；
• 负载均衡；
• 缓存；
• 请求过滤；
• 身份验证；
• 速率限制；
• 日志和指标。

反向代理并不需要执行其中的每一项任务。

后端池

后端可以是：

• 一个源站服务器；
• 同一应用程序的多个副本；
• 按主机或路径选择的不同服务；
• 位于现代公共端点后方的旧应用程序。

代理可以向客户端隐藏这种内部拓扑结构，使后端变更更容易进行，而不需要改变公共 URL。

客户端身份和转发元数据

当反向代理位于客户端与应用程序之间时，后端的直接网络对端通常就是代理。

如果应用程序需要原始客户端 IP、协议方案或主机信息，代理可以添加转发元数据。标准化的Forwarded请求头可以携带原始客户端地址和协议等信息。实践中，X-Forwarded-For、X-Forwarded-Host 和 X-Forwarded-Proto 也被广泛使用。

这些元数据带来的不只是便利，也涉及信任问题。

MDN 的X-Forwarded-For指南警告，非可信代理添加的值可能被伪造。如果源站可以从互联网直接访问，应用程序就不能安全地将任意传入的 X-Forwarded-For 链视为安全决策的权威依据。

反向代理的常见能力

负载均衡

反向代理可以将请求分配到多个后端。

这是最常见的部署方式之一，但“反向代理”和“负载均衡器”并不是完全相同的概念。反向代理描述的是中间节点角色；负载均衡描述的是该中间节点可能执行的一项路由功能。

只有单个后端的反向代理仍然是反向代理。

TLS 终止

反向代理可以在面向客户端的连接上终止 HTTPS。

例如，AWS Application Load Balancer 文档指出，HTTPS 监听器使用服务器证书终止前端连接，并在将客户端请求转发到目标之前解密这些请求。

这并不意味着后端链路必须不加密。部署方案可以在代理处终止客户端一侧的 TLS，再建立另一条到后端的受保护连接。正确的设计取决于网络边界和威胁模型。

缓存

反向代理可以缓存符合条件的响应，使重复请求不必总是到达后端。

NGINX 的内容缓存文档介绍了如何存储经代理的响应，并在后续请求中复用。HTTP 缓存仍然需要正确的缓存控制策略：不能仅仅因为代理具备缓存能力，就共享个性化或敏感响应。

因此，缓存是一种可选行为，并不是每个反向代理的固有属性。

缓冲和连接管理

代理可以调节慢速客户端与更快的应用服务器之间的速度差异。

例如，NGINX 文档将响应缓冲描述为一种机制：上游服务器可以先完成处理，同时代理继续向较慢的客户端发送数据。

这可以改善资源隔离，但对于流式传输或交互性很强的响应，缓冲可能并不合适，缓冲策略需要与应用程序相匹配。

集中路由和策略

在受支持的情况下，代理可以集中处理主机或路径路由、身份验证集成、速率或请求限制、日志记录和安全过滤。这些都是配置后才具备的能力，并不是每个反向代理的固有属性。

反向代理的优势

1. 后端抽象

客户端可以使用稳定的服务端点，而后端主机、端口或副本则在代理后方发生变化。这并不会自动让这些后端被隐藏，或使它们无法通过其他路由访问。

2. 可扩展性

当代理支持负载均衡时，多个后端实例可以分担流量。

这允许应用层水平扩展，而不必让每个请求都通过同一台服务器。

3. 可靠性

反向代理和负载均衡器可以使用后端健康信息，避免将流量发送到不健康的实例。

HAProxy 的健康检查文档介绍了主动和被动检查，以及在故障服务器恢复之前将其从负载均衡轮转中移除的方式。

这能改善路由决策，但不会让代理本身永不出故障。如果代理层是关键入口，它本身也需要冗余。

4. 集中处理 TLS 和证书

在代理处终止 TLS，可以将公共证书管理从每个后端实例上移走。

当许多应用服务器提供同一个公共主机名的服务时，这可以简化运维。

5. 性能控制

对于适合的工作负载和配置，缓存、缓冲、连接复用、压缩或负载分配可以改善性能。仅仅添加反向代理并不能保证速度提升。

6. 受控的安全边界

反向代理可以减少后端的直接暴露，并提供一致的策略执行点，但前提是不能绕过代理直接访问源站。

反向代理的常见使用场景

多服务器 Web 应用

公共主机名指向反向代理层，由该层将流量分配到多个应用实例。

这是反向代理与负载均衡的经典组合。

微服务和基于路径的路由

反向代理可以将不同的主机名或 URL 路径路由到不同的内部服务。这是一种可能的路由模式，并不是反向代理架构的必然要求。

应用边缘的 TLS 卸载

代理管理公共 HTTPS 连接和证书，后端服务则在这一受控边缘的后方运行。

如果内部网络也需要加密，代理可以通过 HTTPS 或平台支持的其他受保护传输方式连接后端。

源站前方的缓存

反向代理缓存可以提供可复用的内容，而不必为每个请求联系源站。

这可以减少源站负载，并改善可缓存资源的响应时间，但缓存规则必须考虑授权、Cookie、个性化和新鲜度。

保护旧服务或内部服务

RFC 9110 指出，网关经常用于封装旧有或不可信的信息服务。

反向代理可以公开受控的公共接口，同时让后端保留在内部网络中，或使用不同的应用接口。

边缘服务和 CDN

一些 CDN 和边缘安全产品以大型分布式反向代理网络的形式运行。

客户端连接到边缘，而边缘决定是从缓存返回响应、应用策略，还是将请求转发到源站。

反向代理与负载均衡器

这两个概念有很大重叠。

所谓反向代理，回答的是架构问题：

哪个组件接收客户端连接，并代表服务器与后端通信？

所谓负载均衡器，回答的是流量分配问题：

应该如何在多个后端之间分配请求或连接？

一个产品可以同时完成这两项任务。NGINX、HAProxy 和云应用负载均衡器通常会结合这些角色。

但不应该将这些术语视为完全相同：

• 反向代理可以将所有请求转发到一个后端；
• 负载均衡器的核心任务是在多个目标之间进行选择；
• 反向代理还可能执行 TLS、缓存、请求头重写或应用路由。

安全性和可靠性陷阱

反向代理可以改善架构，但也会成为应用程序信任边界的一部分。

错误地信任转发的客户端 IP

如果不了解可信代理链，就不要使用 X-Forwarded-For 中最左侧的值来作出涉及安全的决策。

客户端可以提供伪造的转发请求头，除非边缘层删除或覆盖不可信的值，并且应用程序明确知道可以信任哪些代理跳点。

让源站仍可被直接访问

如果公共反向代理实施访问控制或过滤，但源站仍然接受任意公共连接，用户就可能绕过预期的入口。

当设计要求由代理作为权威控制点时，应限制对源站的直接访问。

将 TLS 终止视为端到端加密

当代理终止 TLS 时，客户端到代理的连接受到保护。

代理到后端的连接则是单独的安全决策。如果内部链路也需要传输加密，就应使用后端 TLS。

重试不安全的请求

重试可以改善短暂故障后的恢复能力，但重试策略必须保持 HTTP 语义。

RFC 9110 规定，代理不得自动重试非幂等请求。对于购买或会改变状态的 POST 请求等操作，粗心的重试策略可能导致重复作用。

缓存个性化内容

除非响应被明确指定为可以安全用于共享缓存，否则共享代理缓存不得在不同用户之间复用私有响应。

应一起检查 Cache-Control、Cookie、授权行为，以及代理自身的缓存规则。

引入新的单点故障

如果每个请求都依赖同一个反向代理实例，该实例发生故障时，原本健康的后端也可能无法提供服务。

生产设计通常会在代理层本身加入冗余、故障转移，或采用托管服务。

反向代理部署检查清单

在将反向代理投入生产之前，应验证以下事项：

• 公共入口：公开了哪个主机名和哪些端口？
• 源站可达性：客户端能否绕过代理直接连接后端？
• 路由：哪些主机、路径或服务映射到哪些后端？
• 负载均衡：如果有多个后端，如何选择？
• 健康检查：哪些条件决定后端足够健康，可以接收流量？
• TLS：TLS 在哪里终止，后端连接是否也经过加密？
• 转发请求头：信任哪些代理跳点来设置客户端 IP、主机和协议方案元数据？
• 重试：哪些故障可以在不改变请求语义的情况下重试？
• 缓存：哪些响应可以安全地存储和共享？
• 超时和缓冲：它们是否适合流式传输、上传和长时间运行的请求？
• 日志：能否将面向客户端的请求与后端请求关联起来？
• 代理冗余：如果反向代理层本身发生故障，会出现什么情况？

当这些决策被明确作出，而不是沿用默认设置时，反向代理才最有价值。

要点总结

理解反向代理时，最合适的是将其视为一种服务端网关角色。

它在公共端点接受客户端流量，再代表应用程序与后端服务器通信。在这一位置，它可以提供负载均衡、TLS 终止、缓存、路由、缓冲、基于健康状态的故障转移，以及集中策略控制。

其架构价值在于将公共服务接口与后端实现细节分离。

运维风险也来自同一个地方：代理成为信任边界和可用性边界。

因此，稳妥的部署并不只是安装一个代理，还需要定义：

1. 哪些流量必须经过代理；

2. 如何选择后端；

3. TLS 在哪里开始、在哪里结束；

4. 信任哪些转发元数据；

5. 健康检查和重试如何运行；

6. 哪些内容可以缓存；

7. 代理层本身如何保持可用。

这就是简单地在请求路径中加入另一台服务器，与设计可靠的反向代理架构之间的区别。

来源

• RFC 9110 对网关（也称为反向代理）的描述
• NGINX 负载均衡方法文档
• NGINX 的反向代理文档
• Cloudflare 文档
• Forwarded 请求头
• MDN 的 X-Forwarded-For 指南
• AWS Application Load Balancer 文档
• NGINX 的内容缓存文档
• HAProxy 的健康检查文档