深度解析：住宅代理网络如何运作？架构详解

这是许多从事代理行业的人经常提出的问题。以下是对每个住宅代理网络背后大致架构的解释。

首先，让我们定义什么是住宅网络：一个由能够将数据包转发到目标地址的对等节点组成的网络。

简单来说，住宅代理网络通过真实用户设备来路由你的互联网请求。这些设备通过用户已同意的应用程序进行招募，网络为每个请求选择最佳设备，响应以你从该位置浏览的形式返回给你。表面下的复杂性是将快速、可靠的住宅网络与缓慢、不稳定的住宅网络区分开来的关键。

1. SDK

对等节点通过集成到消费者应用程序中的 SDK（软件开发工具包）进行招募。基于用户同意，SDK 使住宅代理网络能够将数据包通过设备转发到目标地址。这是促进通过真实住宅设备代理请求的基本元素。

2. 标准请求与代理请求

以下是标准 HTTPS 请求的路由方式（第 4 层到第 7 层）。下方的 RTT 计数是累积的；每一层都会添加到运行总数，并假设是新连接：

TCP 握手（步骤：1 RTT | 累积：1 RTT）

1. 用户向目标地址发送 SYN

2. 目标地址向用户发送 SYN-ACK

3. 用户向目标地址发送 ACK（数据可以随这个最后的段传输）

步骤成本：1 RTT，使累积运行时间达到 1 RTT。RFC 9293。

第 5/6 层：（步骤：TLS 1.3 为 1 RTT / TLS 1.2 为 2 RTT | 累积：TLS 1.3 为 2 RTT / TLS 1.2 为 3 RTT）

1. 用户向目标地址发送 ClientHello

2. 目标地址向用户发送 ServerHello、EncryptedExtensions、Certificate、CertificateVerify、Finished

步骤成本：现代 TLS 1.3 为 1 RTT（累积：2 RTT），或旧版 TLS 1.2 为 2 RTT（累积：3 RTT）

单独来看，TLS 1.3 是 1-RTT 握手，TLS 1.2 是 2-RTT；这里的总数是累积的，包括 TCP 往返，所以 TLS 1.2 增加了整整一个额外的 RTT（总共 3 RTT）。TLS 1.3 在重复连接上还可以进行 0-RTT 恢复，但存在已知的重放权衡。

第 7 层：应用层（步骤：1 RTT | 累积：TLS 1.3 为 3 RTT / TLS 1.2 为 4 RTT）

1. 用户向目标地址发送请求 + 头部

2. 目标地址向用户发送响应 + 头部

步骤成本：1 RTT，使首字节时间达到 TLS 1.3 的 3 RTT 或 TLS 1.2 的 4 RTT

一旦添加代理，它至少会增加一个跳转和一些延迟：路径更长（用户 → 代理 → 目标地址，然后返回），代理增加了自己的处理时间。是否也会增加往返取决于代理类型。

终止型代理（使用 CONNECT 的 HTTP 正向代理，或打开自己的上游连接的住宅网关）会增加额外往返：客户端首先与代理进行握手，对于 HTTPS，CONNECT 请求及其「200 Connection Established」回复在端到端 TLS 握手开始之前本身就构成一次往返，随后代理再向目标地址进行握手。

不终止连接的透明第 3/4 层转发器保持端到端握手，不增加额外往返，只是路径更长。无论哪种方式，距离更远和更多中间设备意味着延迟更高，这正是本文其余部分所要尽量降低的。

3. 「交通堵塞」问题

住宅网络极其复杂，因为在不拖慢网络的前提下智能路由请求涉及许多细节。

一个恰当的类比是道路网络。如果太多汽车走同一条路线，就会变得拥堵。理想状态是每条路线都零拥堵，而这只能通过根据每条路线的容量智能分配请求来实现。

每个对等节点在拥堵之前的容量是有限的。住宅代理网络必须持续收集每台设备网络层容量的信息，以在对等节点之间平衡负载，在不使对等节点拥堵的情况下满足客户端需求。

4. 提供商端优化

4a. DNS 与数据中心

住宅网络应尽可能利用数据中心级传输。例如，如果西欧的客户通过东欧对等节点进行路由，网络应使用 DNS 负载均衡器在西欧接收这些数据包，并通过直连数据中心路由将其传输到最近的网关，从而大幅降低延迟开销。

4b. 第 4 层内部优化

在网关数据中心节点之间，网络应使用直连路由并在全球分布网关以获得良好覆盖。在网关与对等节点之间，每个网关应维护预热的 TCP 连接，并使用双向 TLS 加密来保护设备和网关的安全。

4c. 第 4 层外部优化

SDK 可以维护到热门目标地址的预热 TCP 连接，以节省对等节点与目标之间的 1 RTT，因为应用层始终可以在现有 TCP 连接之上重建。

4d. 参数配置

可以实时调整 TCP 参数以提高数据包传输效率，并降低 SDK 的 CPU/RAM 占用。最小化资源消耗至关重要。如果 SDK 对对等节点设备造成负面体验，发布者将终止 SDK 合同。

4e. 智能路由算法（基于性能）

这是最难但最有效的优化。网络在所有网关间维护一个实时内存数据库，可被即时查询以回答：「哪个设备最适合路由此请求？」

没有这个算法，每隔一个请求就可能被路由到缓慢或拥堵的对等节点，网络将在适度负载下崩溃。

4f. IP 上限算法（基于声誉）

住宅网络有维护每个目标地址 IP 声誉的利益诉求。如果三分之一的 IP 池被目标地址 A、B、C 列入黑名单，针对这些目标地址的用户将看到 33% 的错误率。通过仅经由剩余 67% 的 IP 进行路由，并将黑名单 IP 置于冷却期，网络可为客户提供显著更好的体验。

IP 上限算法构建和维护成本较高，但若执行得当，可显著提升网络质量。

5. 客户端优化

5a. 数据中心

客户端应使用位于尽可能靠近其目标对等节点区域最近网关的数据中心服务器。对于荷兰的对等节点，阿姆斯特丹数据中心是合理之选。你也可以对网关执行 traceroute，并选择路径最短的提供商。

5b. DNS

传递域名本身而非其解析后的 IP 地址。这允许对等节点执行 DNS 解析，可能带来更高效的路由。务必在 SNI 字段中包含域名，以确保 TLS 握手能够成功。

5c. 地理位置定向

虽然地理位置定向可以降低到目标对等节点的延迟，但也存在缺点。如果特定地理位置没有足够的对等节点来满足并发需求，请求将失败或延迟将激增。在完全依赖某一地理位置之前，请研究其限制并监控其健康指标。

5d. 第 4 层与粘性会话优化

按照行业标准，身份验证通过 Base64 编码的 Proxy-Authorization 头传递，同时附带粘性会话和地理位置定向等请求参数。请求到达网关后，这些参数将被解码并应用。

专业代理用户每个 IP 维护一个连接，每隔 10 到 20 秒监控出口 IP 以确认对等节点仍然存活，并根据性能在对等节点之间进行负载均衡。例如，如果目标地址在 50 个请求后触发限流，则在 25 到 30 个请求时主动降速，或在达到限制时进行轮换。

核心原则：当可用对等节点不足时，从速率限制、网络速度和拥堵管理等方面最大化每个对等节点的能力。

由 FlashProxy CEO Alon Levi 发表

关于作者：Alon Levi 是 FlashProxy 的 CEO，在代理基础设施、网络架构和大规模 IP 路由技术方面拥有丰富经验。  

在 LinkedIn 上联系  ·  联系方式：[email protected]

常见问题

为什么住宅代理比数据中心代理慢？

住宅代理通过家庭互联网连接上的真实消费者设备路由请求。这至少增加了一个额外的网络跳转，对于终止型网关而言，在端到端 TLS 握手开始之前还会增加额外的设置往返，再加上家庭宽带速度的不稳定性，使其比直接托管在数据中心的代理更慢。

代理中的粘性会话是什么？

粘性会话在设定的持续时间内保持请求通过同一 IP 地址路由。这对于需要会话连续性的任务非常有用，例如维持登录状态或保留购物车内容。

为什么住宅代理 IP 会被列入黑名单？

当某个住宅 IP 向特定目标地址发送过多请求时，该网站可能会将其标记并封锁。过度饱和或管理不善的网络会加速这一过程，减少所有用户可用的 IP 池。

什么是代理对等节点？

代理对等节点是真实的消费者设备（手机、计算机或智能电视），其互联网连接在设备所有者同意的情况下，通过集成到其已安装应用程序中的 SDK 用于路由代理流量。

来源与参考文献

• IETF RFC 9293，传输控制协议：https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446，TLS 1.3（1-RTT 握手；0-RTT 恢复）：https://datatracker.ietf.org/doc/html/rfc8446

• IETF RFC 5246，TLS 1.2（2-RTT 握手）：https://datatracker.ietf.org/doc/html/rfc5246

• IETF RFC 9110，HTTP 语义（CONNECT 方法）：https://datatracker.ietf.org/doc/html/rfc9110

• IETF RFC 6066，TLS 服务器名称指示（SNI）：https://datatracker.ietf.org/doc/html/rfc6066

• IETF RFC 7235，HTTP/1.1 身份验证（Proxy-Authorization）：https://datatracker.ietf.org/doc/html/rfc7235

• MDN Web 文档，HTTP CONNECT 方法：https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT

• Cloudflare，正向代理延迟：https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Cloudflare 学习中心，什么是 SNI？：https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik，高性能浏览器网络：https://hpbn.co/