什么是代理服务器？定义与架构

代理服务器究竟是什么

代理服务器既不是一种产品，也不是一项隐私功能，更不是某种类型的软件。它是在通信中扮演的一个角色——一台会终止你的连接，并代表你与目标服务器建立新连接的机器。 人们争论的种种区别——无论是正向与反向，还是透明与精英型——归根结底都取决于两个技术问题：谁选择了中间人？以及在目标服务器看到你的请求之前，它会重写哪些标头字段？

HTTP 本身的规范比围绕它的营销宣传更为严格。RFC 9110 第 3.7 节列举了三种常见的中介形式，区分它们的并非软件——一个程序可以扮演多个角色——而是位置和选择。

• 根据规范的定义，代理是一种由客户端选择的消息转发代理，通常通过本地配置规则进行选择。客户端知道它的存在，是因为正是客户端将其部署在那里的。
• 网关——RFC 文档中将其简称为“反向代理”——在出站连接中充当源服务器，但会将接收到的请求进行转换，并将其转发给另一台或多台服务器。对访问者而言，它与真实的源服务器毫无二致。
• 隧道在两个连接之间充当“盲中继”，不会更改消息内容，且规范中明确指出，它不被视为HTTP通信的参与方。

这个术语一举消除了大部分困惑：代理服务器的定义取决于其所在位置以及由谁选定，而非其销售时的宣传名称。同一台运行相同软件的机器，既可以作为公司员工的代理服务器，也可以作为其所连接网站的大门。

有一层区别值得在早期明确，之后便无需再纠结。 HTTP 代理能够解析 HTTP 消息——它会解析请求行，并能重写请求头。SOCKS 代理（在 RFC 1928 中定义）则工作在更低一层，负责中继 TCP 连接（若实现支持 UDP 则也包括 UDP 连接），且不会解析其中传输的数据。关于应将工具指向哪种代理，另有专门页面说明： HTTP 与 SOCKS5. 代理检测工具 如果不想阅读，想直接测试的话，它两种语言都会说。

本页定义的是该角色，而非其任何特定种类。关于蜂窝网络的情况——即作为移动网络中设备的出口点——请参见 什么是移动代理. 有关退出类型的继承关系，请参见 代理类型解析.

数据线中究竟发生了什么变化

几乎所有关于“代理服务器如何工作”的解答，都讲的是“中转”的故事：你的请求先发到这里，再发到那里，最后才到达目标网站。这虽然属实，却几乎毫无用处，因为它描述的都是你无法观察到的内容。实际上，有三件事是肉眼可见的变化，而且这三件事都存在于HTTP消息本身之中。

1. 请求目标的形态发生了变化

直接发送到服务器的请求采用 RFC 9112 中所称的“源格式”（origin-form）：仅包含路径，主机名则单独通过 Host 字段携带。 随后第 3.2 节提出了一项“MUST”级别的要求——向代理发送请求时（CONNECT 或全服务器范围的 OPTIONS 请求除外），客户端必须以绝对形式将目标 URI 作为请求目标发送。完整的 URL 被移入请求行，因为代理无法假设其即为目标地址。

Direct to the origin (origin-form)
    GET /pub/index.html HTTP/1.1
    Host: example.org

Through a forward proxy (absolute-form, RFC 9112 s3.2)
    GET http://example.org/pub/index.html HTTP/1.1
    Host: example.org
    Proxy-Authorization: Basic dXNlcjEyMzpzM2NyZXQ=

2. HTTPS 完全不通过代理——而是通过隧道传输

一旦协议变为 HTTPS，上述机制便不再适用。客户端不会发送供代理读取的请求；而是使用第三种请求目标格式——授权格式——发送一个 CONNECT 请求，其中仅包含用冒号分隔的主机名和端口号。 RFC 9110 描述了后续流程：CONNECT 请求要求接收方建立一条隧道，连接到请求目标所标识的目的地源服务器；如果成功，则此后将行为限制为双向数据的盲转发，直至隧道关闭。

结果恰恰与大多数人的理解相反。在 HTTPS 请求过程中，代理服务器只能看到目标主机名、端口、时间和字节数。它无法看到你的路径、请求头、Cookie 或响应正文：TLS 协议是通过隧道进行端到端协商的，而代理服务器只是中继它无法解密的密文。

CONNECT example.org:443 HTTP/1.1
    Host: example.org

HTTP/1.1 407 Proxy Authentication Required
    Proxy-Authenticate: Basic realm="proxy"

CONNECT example.org:443 HTTP/1.1
    Host: example.org
    Proxy-Authorization: Basic dXNlcjEyMzpzM2NyZXQ=

HTTP/1.1 200 Connection Established
    <-- TLS handshake and everything after it is opaque to the proxy -->

3. 凭证使用其专属的标头对

代理身份验证被有意与源身份验证区分开来，因为一条消息可能会收到来自两个不同方的身份验证请求，而客户端必须将它们区分开来。 需要凭据的代理会返回状态码 407（代理身份验证所需）并包含 Proxy-Authenticate 头，客户端则携带 Proxy-Authorization 头进行重试；需要凭据的网站会返回状态码 401 并包含 WWW-Authenticate 头，客户端则携带 Authorization 头进行响应。 状态码可作为自由诊断依据：407 表示您的代理拒绝了您，且目标服务器从未收到过您的请求；401 表示代理已完成其职责，但目标服务器拒绝了请求。

所有这些都发生在HTTP消息层，而本页正是特意止步于此。其底层的物理传输路径——客户端、硬件、运营商、目的地——则是另一个独立的主题，将在 移动代理的工作原理.

同一个请求，三种实现方式

这个问题中哪一半是你的？

至少有四位不同的人因面临四个不同的问题而询问“什么是代理服务器”，而其中只有部分人需要相同的答案。这是从图表到你真正需要的页面最快捷的途径。

正向代理与反向代理

这些是方向相反的同一类机制，而通过拓扑结构来区分它们并不靠谱——两者都位于中间位置，都既终止一条连接，又开启另一条连接。有用的检验标准是效忠对象。问问是谁部署了这个东西，它又服务于谁的利益，答案便不言自明。

正向代理由客户端选择，并代表客户端工作：它向目标隐藏客户端的身份。 反向代理——在规范术语中称为“网关”——由网站运营商选择，并代表网站行事：它向客户端隐藏了源服务器。你并非其用户，而是它所保护的网站所要防范的对象。

这就是为什么你不能购买反向代理来更改你的IP地址——技术支持邮箱里经常收到这类请求。 Nginx、HAProxy 和 CDN 边缘节点都在为服务器提供代理服务。在您自己的网站前端部署其中一种，只会改变访客能够获取的关于您基础设施的信息，而对您访问的网站能够获取的关于您的信息则完全没有任何影响。

该表格中有一行值得单独成句，因为这正是本文两部分的交汇点。前向代理无需由您亲自选择——只需在客户端进行选择即可。 一家将每台工作站都通过出站代理进行路由的公司，实际上部署了一个前向代理，而没有任何一名用户主动选择使用它；之所以它让人感觉像是监控而非服务，恰恰是因为忠诚度与选择权已经脱节了。

“透明”、“匿名”和“精英”是标题行为

代理列表将三种匿名级别描述得仿佛是印在硬件上的产品等级一样。其实并非如此。这些描述的其实是消息到达目的地时两个报头字段的状态，你大约只需十秒就能测得这些指标。

第一个字段是 Via。RFC 9110 第 7.6.3 节将其值定义为一个或多个协议和接收方标识符，每个标识符都代表一个不同的中间节点，这些标识符按照消息传输的顺序依次追加。 因此，该字段在目的地的存在即证明该消息至少经过了一个中间节点——这是中间节点按设计自我宣告的结果，而非信息泄露。

第二个字段包含您的原始地址。长期以来的惯例是使用 X-Forwarded-For，而 RFC 7239（即《Forwarded HTTP 扩展》，一份发布于 2014 年 6 月的标准跟踪文档）用一个包含四个参数（for、by、host 和 proto）的 Forwarded 字段取代了该字段及其相关字段。 该文档对相关风险的表述异常直白，指出许多人认为客户端地址属于隐私敏感信息，并且“by”和“for”参数的默认配置应使用混淆标识符。

Transparent   Via: 1.1 proxy.example.net
              Forwarded: for=203.0.113.47      <-- your address, forwarded intact

Anonymous     Via: 1.1 proxy.example.net       <-- an intermediary, but not who
              (no Forwarded, no X-Forwarded-For)

Elite         (neither field present)          <-- nothing in the headers to see

最后那句话值得认真对待。由于评级标准并未统一，标注为“精英级”的列表实际上是在对他人软件做出主张，而这种主张并无权威依据。不过，该主张是可以验证的，验证过程包括以下四个步骤：

PXM2 代理检测工具 它会为您针对这两种协议分别执行该测试，并报告实际接收到的结果，而非承诺的结果。

“四个作业代理”实际上是用于什么的

抛开供应商分类和功能列表不谈，代理的部署主要为了实现四项功能。每次实际部署都是这四项功能的某种组合，而您能使用哪种组合完全取决于角色——这就是为什么最诚实的呈现方式是将其与能够执行这些功能的角色结合起来说明，而不是作为供您选择的菜单来展示。

仔细阅读这份列表，就能明白围绕这个术语为何会有这么多误解。这四项功能中的两项——缓存和负载均衡——与隐藏任何人毫无关系，这也正是为什么网络工程师和购买IP地址的人经常在交谈中途才发现，他们用同一个词指代了不同的设备。 只有第四项功能才是大多数人访问本页时真正想要了解的，而在这项功能中，真正起决定性作用的并非代理本身，而是出口地址所处的网络。 每个 PXM2 代理都是一个正向代理，通过真实的 4G 或 5G 运营商连接来执行第四项功能；如果您关注的就是这方面的问题，那么 实时代理列表 是下一步，而且 如何设置移动代理 这是配置指南。

代理服务器不是什么

其余的混淆主要源于四处更正，而每处更正都是将一项相关技术误认为本技术所致。

• 代理并非加密。 普通 HTTP 代理会以明文形式转发您的请求，并可以读取和修改请求的每个部分。对于 HTTPS 请求，其机密性来源于通过隧道端到端运行的 TLS，这与请求路径中完全不包含代理时提供的保护完全相同。代理对此毫无贡献。
• 代理服务器不等于VPN。 代理是按应用程序分别配置的：你的爬虫会使用它，而你的邮件客户端则不会，两者通过不同的地址进行通信，但两者都没有问题。VPN 则是在操作系统层创建一个虚拟网络接口，并捕获所有流量。作用范围不同，故障模式不同，正确的解决方案也不同。 完整的对比内容请见此处.
• 代理既不是NAT，也不是防火墙。 这两者都运行在应用层之下。它们都不解析请求目标，都不了解“Host”字段是什么，也无法添加“Via”头，因为它们根本不读取HTTP数据。路由器重写地址的行为，在结构上与中间节点读取你的消息是截然不同的。
• 代理并不等于匿名。 这只会改变目标服务器记录的地址。它不会改变客户端发送的 Cookie、TLS 堆栈呈现的指纹，也不会改变你三十秒后登录的账户。在客户端其他方面均未改变的情况下，仅更换地址只是改名，而非伪装。

这些都并不能说明代理服务器很弱。这恰恰说明它们具有特定性。代理服务器是一种中间人，它会终止你的连接并建立自己的连接；一旦你知道是谁选择了它，以及它重写了哪些字段，你就已经掌握了这个术语本身所能提供的所有信息——剩下的问题只是远端位于哪个网络上。

探索真正的移动代理

需要一个带有干净的移动运营商IP地址的前向代理吗？PXM2运行专用的4G/5G调制解调器：

常见问题解答

相关指南

代理基础知识

核心移动代理指南