前面 28 篇默认请求是「客户端 → 服务器」两点直连。但真实的 HTTP 请求路上，往往不止这两个节点——中间可能有正向代理、反向代理、网关、CDN，一层层转发。这一篇讲这些中间节点。

中间节点的三种角色

HTTP 中间件按位置和职责分三类：

HTTP 中间件的三种角色

正向代理（Forward Proxy）

站在客户端这边，替客户端发请求。典型场景：公司内网通过正向代理访问外网，VPN 也是一种正向代理。客户端知道有代理，主动把请求发给代理，代理转发给服务器。

正向代理的特点：服务器看到的是代理的 IP，不知道真正的客户端是谁。这就是「翻墙」、匿名访问的原理——代理隐藏了客户端身份。

反向代理（Reverse Proxy）

站在服务器这边，替服务器收请求。典型场景：Nginx 做反向代理，把请求转发给后端的多个应用服务器。客户端不知道有反向代理，以为直接连的是服务器。

反向代理的用途很多：负载均衡（把请求分到多个后端）、缓存、SSL 卸载（HTTPS 在代理层解密，后端用 HTTP）、安全过滤。CDN 本质也是一种反向代理——边缘节点就是反向代理。

网关（Gateway）

协议转换器。当客户端和服务器用不同协议时，网关在中间转换。比如客户端用 HTTP，后端是 gRPC，网关把 HTTP 请求转成 gRPC 调用后端。网关和反向代理的边界比较模糊，很多时候反向代理同时承担网关的角色。

中间节点怎么改写请求

请求经过中间节点时，会被改写。最核心的改写是 IP 相关——因为代理转发后，服务器看到的 IP 是代理的，真正的客户端 IP 丢了。为了不丢，有一组头：

X-Forwarded-* 头：追踪真实的客户端信息

  • X-Forwarded-For: 客户端IP, 代理1IP, 代理2IP —— 链路上每一跳追加自己的 IP，让最终服务器知道真正的客户端是谁。
  • X-Forwarded-Proto: https —— 客户端原始用的协议（因为代理可能 HTTPS 收、HTTP 转给后端，后端要知道客户端本来是 HTTPS）。
  • X-Forwarded-Host: rubyfun.cn —— 客户端请求的原始 Host。

这几个头是「非标准但事实标准」。RFC 7239 定义了标准化的 Forwarded 头（替代 X-Forwarded-），但实际用得最多的还是 X-Forwarded-。后端拿客户端真实 IP 就靠 X-Forwarded-For。

还有一个头是 Via，它记录请求经过了哪些代理（代理类型、版本），用于诊断和防环路。

多层代理的现实

真实环境里，请求经常经过多层代理。一个典型链路：

浏览器 → CDN → 负载均衡器 → 反向代理(Nginx) → 应用服务器

每一层都可能：缓存（CDN、Nginx）、改写头（追加 X-Forwarded-For）、终止 TLS（CDN 或 LB 解密 HTTPS）、做路由（按 URL 分发到不同后端）。

多层代理的请求链路

多层代理的好处是职责分离、可扩展。但代价是：排障变复杂——「为什么客户端拿到的响应不对」可能卡在中间任何一层。这就是为什么需要 Via 和 X-Forwarded-*——它们让链路可追踪。

透明代理 vs 非透明代理

代理还分透明和非透明：

  • 透明代理：不修改请求内容，只转发。客户端不知道它的存在（如运营商的缓存代理）。
  • 非透明代理：会修改请求/响应（加头、缓存、改写）。反向代理基本都非透明。

透明代理有个争议点：运营商有时用透明代理缓存内容或注入广告，这破坏了 HTTP 的端到端语义。这也是为什么 HTTPS 重要——加密后透明代理没法窥探和篡改内容。

取舍与边界

代理和网关有几个实践要点：

  • X-Forwarded-For 可被伪造。客户端可以自己塞一个假的 X-Forwarded-For。信任哪个取决于代理链路——通常只信任自己控制的那层代理设置的值，外部的不可信。Nginx 有 proxy_set_header 配置控制这个。
  • 代理要正确处理 hop-by-hop 头。第 2 篇讲过，Connection 等逐跳头经过代理时要被剥掉，不能一路传。代理实现要遵守这个规则。
  • 缓存代理要尊重 Cache-Control。代理作为中间缓存，要按资源的 Cache-Control 决定能不能缓存（public 才能代理缓存，private 只能浏览器缓存）。

收束：HTTP 是为多层中间件设计的

HTTP 从设计之初就考虑了中间件——报文格式允许逐跳处理，header 区分端到端和逐跳，状态码和 method 让中间件能理解意图。代理、网关、CDN 这些中间节点不是 HTTP 的「补丁」，而是 HTTP 架构的有机部分。

下一篇是系列的最后一篇——怎么用抓包工具把这套机制看清楚，以及整个系列的总收束。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 HTTP」，欢迎关注公众号 「十三Tech」。后续会按 URL 与报文、连接与传输、缓存与协商、安全与边界、HTTP/2 与 HTTP/3 这条线更新。

十三Tech公众号二维码