引入 HTTP 代理后，原来简单的双方通信就变复杂了一些，加入了一个或者多个中间人，但整体上来看，还是一个有顺序关系的链条，而且链条里相邻的两个角色仍然是简单的一对一通信，不会出现越级的情况。

链条的起点还是客户端（也就是浏览器），中间的角色被称为代理服务器（proxy server），链条的终点被称为源服务器（origin server），意思是数据的“源头”“起源”

原理拆解： 代理链可以表示为“客户端 → 代理 A → 代理 B → 源服务器”，响应再沿原路径反向返回。这里的“不越级”描述的是单次连接关系：客户端把请求交给代理 A，代理 A 再建立到代理 B 的连接，而不是把同一条底层连接原封不动地延伸到源站。每一跳都可以拥有独立的 TCP 连接、超时和重试策略；应用层消息则由中间节点接收后继续转发。代理还可能通过 Via 等字段记录消息经过的中间环节。

最小验证： 输入是一条经过两个代理的请求及其响应，要验证各节点只和相邻角色交换消息，并且响应按链路逆序返回。

GET /products/42 HTTP/1.1
Host: origin.example
Via: 1.1 proxy-a, 1.1 proxy-b

HTTP/1.1 200 OK
Content-Type: application/json
Via: 1.1 proxy-b, 1.1 proxy-a
Content-Length: 24

{"id":42,"stock":true}

请求中的 Host 指向目标源站，Via 展示代理依次追加的转发轨迹；响应从源站返回后，先经过靠近源站的 proxy-b，再经过 proxy-a 到达客户端。真实产品是否添加或保留 Via 取决于代理配置，因此缺少该字段不能证明没有代理。

边界与排查： “有序链条”不等于所有代理都不会改变消息。代理可以增删首部、缓存响应，或因重试把一次下游请求转换成多次上游请求；负载均衡器也可能为不同请求选择不同源站。排查链路时应结合代理访问日志、请求标识、连接信息和抓包结果，分别确认每一跳的接收与发送时间，不能仅凭浏览器里看到的源站域名推断客户端进行了直连。

“代理”这个词听起来好像很神秘，有点“高大上”的感觉。

但其实 HTTP 协议里对它并没有什么特别的描述，它就是在客户端和服务器原本的通信链路中插入的一个中间环节，也是一台服务器，但提供的是“代理服务”。

所谓的“代理服务”就是指服务本身不生产内容，而是处于中间位置转发上下游的请求和响应，具有双重身份：面向下游的用户时，表现为服务器，代表源服务器响应客户端的请求；而面向上游的源服务器时，又表现为客户端，代表客户端发送请求

打个比方。

之前你都是从超市里买东西，现在楼底下新开了一家 24 小时便利店，由超市直接供货，于是你就可以在便利店里买到原本必须去超市才能买到的商品。

这样超市就不直接和你打交道了，成了“源服务器”，便利店就成了超市的“代理服务器”

原理拆解： 代理的双重身份体现在两段独立交互中。下游连接里，代理监听端口、解析请求并向客户端写回响应，因此是服务器；上游连接里，它主动选择源站、建立连接并发送请求，因此是客户端。这里的“转发”也不要求逐字节复制：代理可以重写目标地址、补充转发首部或复用上游连接，但响应内容的最终来源仍是源服务器或代理中已有的缓存。

最小验证： 输入为客户端发给代理的请求，以及代理据此发给源站的请求；要验证同一代理在两段通信中使用不同身份。

GET http://origin.example/profile HTTP/1.1
Host: origin.example
User-Agent: demo-client

GET /profile HTTP/1.1
Host: origin.example
Via: 1.1 edge-proxy
X-Forwarded-For: 192.0.2.10

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 5

Alice

第一段使用绝对形式的请求目标，常见于客户端访问显式正向代理；第二段是代理作为上游客户端向源站发送的请求。X-Forwarded-For 表示代理声明的原客户端地址，但它只是普通首部，只有来自可信代理时才可用于安全判断。最后的响应由代理接收，再转交下游客户端。

边界与排查： 代理不总能读取应用层内容。处理 HTTPS 隧道时，显式代理可通过 CONNECT 建立字节通道，此后若不终止 TLS，它只能转发密文。缓存命中时也可能完全不访问源站，所以“每个请求都有对应的上游请求”并不成立。工程验证应同时查看下游访问日志和上游日志，并用统一请求标识关联两段记录；若只有下游记录，应继续检查缓存、访问拒绝、连接失败和超时。