我们的声明：我们是 Geonode，我们销售代理服务，因此本文实际上是在反对使用我们自己的产品。将我们的代理串联在其他代理之后，或者依次串联多个我们的代理，会导致您的请求变慢且可靠性降低，并且无法实质性地改善您的处境。 原因在于结构本身，而非任何特定提供商的限制，具体说明如下。串联代理确实有两三个正当理由，但这些理由与路由和访问相关，而非匿名性。如果您的目标是匿名，坦率地说，专门为此设计的系统才能真正实现这一目标，而一堆商业代理则无法做到。
链式连接的实际原理
通常情况：你连接到一个代理，代理再连接到目标。两条连接，一个中间节点。
链式连接：你连接到代理 A，代理 A 连接到代理 B，代理 B 再连接到目标。每个跳点都会终止前一个连接并建立新的连接，因此目标只看到代理 B 的地址，而代理 B 只看到代理 A。
据称其优点在于：没有任何一个中间节点同时知道两端的信息，且要追踪路径需要链中每个运营商的配合。
从狭义上讲，这两点说法都是正确的，但在实际应用中，其效果远不如上述总结所暗示的那样强。本文剩余部分将探讨原因。
构建链的两种方式
客户端级联是常见的情况：你的机器被配置为通过 A 进行路由，而 A 被配置（或指示）将流量转发至 B。像 proxychains 这样的工具通过拦截连接，并将其引导至你控制的列表中来实现这一点。
关键特性在于：**由你选择链路。**你清楚每个中转节点，可以随时更改它们，且无需任何运营商配合。这就是为什么几乎所有实际应用中的链路都是客户端链路。
服务器端链路是指服务提供商通过你无法控制的基础设施转发你的流量。某些服务在内部会采用这种方式——一个终止你的连接并从多个端点之一发出的网关，从技术上讲就是一条链路，尽管通常不会被这样描述。
这里的关键特性恰恰相反：**你无法控制该链路，也无法对其进行验证。**服务商声称流量会经过多个国家，但你无法从自身角度进行验证。这是一种信任声明，而非架构。
proxychains：功能及其局限性
最广为人知的工具，其官方描述对工作机制阐述得十分精准。proxychains 是一款“UNIX 程序，它通过预加载的 DLL 钩住动态链接程序中与网络相关的 libc 函数，并将连接重定向至 SOCKS4a/5 或 HTTP 代理。”
这句话既体现了其巧妙之处，也揭示了其局限性。
**巧妙之处：**它适用于本身不支持代理的程序。由于它在 libc 层进行拦截，因此进行普通套接字调用的应用程序会在不知情的情况下被透明地重定向。
**局限性，直白地说：**它“仅适用于动态链接程序”，并且要求 proxychains 和目标应用程序“使用相同的动态链接器”。 静态链接的二进制文件——其中包括大量现代 Go 软件——则完全不受影响。程序照常运行，直接建立连接，且没有任何警告提示。
支持三种链模式：
精确顺序 —— 代理按配置顺序精确使用。结果可预测，但单个失效的代理会导致整个链中断。 动态顺序 —— 失效的代理会被智能排除，因此链能继续运行，但代价是无法保持你指定的顺序。 随机顺序 —— 从配置的长度中随机选取子集，适用于希望每次运行结果有所变化的场景。
支持的协议包括 SOCKS4、SOCKS4a、SOCKS5 和 HTTP(S)，其中 SOCKS 支持用户名/密码认证，HTTP 支持基本认证。
还有一种值得了解的、在文档中记载的故障模式，因为它确实非常晦涩：“当一个进程进行分叉，在子进程中执行 DNS 查询，然后在父进程中使用该 IP 地址时，将无法找到相应的 IP 映射。”采用这种结构的应用程序会出现异常行为，这些行为看似网络问题，实则并非如此。
延迟累积，可靠性呈倍数下降
从数学角度来看，这是反对随意串联的最有力论据。
延迟会累积。 每个跳点都会带来自身的往返时间以及处理时间。一个50毫秒的直接请求，经过一个代理后可能变成200毫秒，经过两个代理后则可能达到400毫秒。对于交互式应用而言，这正是“可用”与“令人恼火”之间的区别。对于需要发出十万次请求的爬取任务来说，这则意味着耗时从4小时延长到8小时。
**可靠性呈乘法关系，而小于1的数值相乘结果只会单向变化。**如果每个跳点独立的可用率均为95%：
| 跳点数 | 成功率 |
|---|---|
| 1 | 95% |
| 2 | 90.3% |
| 3 | 85.7% |
| 4 | 81.5% |
由三个各自可靠的代理组成的三跳链，其系统每七次请求就会失败一次。 而且链路中的故障比单个跳点的故障更严重，因为诊断起来更困难——超时提示只能告诉你链路中断了，却无法指出具体是哪一节链路出了问题。
带宽按每个跳点计费。 如果你为两个按流量计费的代理付费，每个字节都会被计费两次。 将两个每GB收费0.79美元的住宅代理服务串联起来，处理相同数据的成本将达到每GB 1.58美元。
吞吐量受最慢节点的限制，而增加节点数量会增加出现延迟的可能性。
面对这些成本，收益必须相当可观。但通常并非如此。
链式连接能让你更匿名吗？
老实说：效果不如宣传的那样好，而且这完全取决于运营商是谁。
链式连接确实能实现什么。 没有任何一个中继节点能同时看到你的地址和目标地址。中继节点 A 知道你是谁，也知道你与 B 进行了通信；中继节点 B 知道它与目标地址进行了通信，但不知道通信的发起者是谁。这是它真正具备的特性。
为什么它的实际效果不如表面看起来那么好。
对于同时监视两端的任何人来说，跨中继节点的关联分析都轻而易举。 能够观察到两端情况（包括时间、流量、模式）的观察者，无需解密任何内容即可将它们关联起来。这就是流量分析，也是匿名系统的核心问题。两个商业代理无法解决这个问题。
**共同所有权会瓦解链条。**如果两个中继点都属于同一家服务商，或者转售同一底层网络，那么这种分离只是虚幻的。代理市场中转售关系很常见，且并不总是被披露；而一条通过共享同一供应商的两个品牌组成的链条，实际上只有一个运营商，而不是两个。
应用层完全能绕过这一机制。 无论路由如何，Cookie、登录信息、浏览器指纹以及你输入的任何内容都能识别你的身份。一条由五个代理组成的链路，若承载着你已登录的会话，不过是一种极其缓慢的身份识别方式。
支付和账户记录会追溯到你。 这些服务是你购买的。 这留下了记录。
**加密并非分层进行的。**在普通的代理链中，每个中继节点都能读取未受 TLS 保护的任何内容。链式连接并不会增加加密层，而是增加了可能读取你流量的中介节点。这与预期方向背道而驰，也是下一节将重点探讨的问题。
Tor 是正确实现的链式架构
值得作为参考设计加以理解，因为它揭示了商业代理服务器堆栈所缺乏的要素。
Tor 项目 直接指出了这一区别：“与普通代理服务器不同，普通代理服务器会形成单一的信任点和故障点，而 Tor 则通过多层加密，将您的流量路由到多个中继节点。”
流量至少会经过三个中继节点，且信息被有意分割。 第一个中继节点可能观察到某个地址正在使用 Tor，但无法确定其目的地。中间中继节点看到的是加密流量，既无法识别发件人，也无法识别最终目的地。出口中继节点看到的是出站流量，但看不到其来源——而且在 HTTPS 情况下，它只能看到目标网站，而无法看到具体内容。
有三项设计特性确保了这一机制的运作，而手动代理链则完全不具备这些特性：
**分层加密。**每个中继节点会剥离一层加密。一个中继节点无法读取下一节点将接收的内容。在普通代理链中，每个节点看到的流量都是客户端发送时的原始状态。
电路由客户端从已发布的目录中选择，路径约束机制旨在避免中继节点之间存在关联。而在手动代理链中，你只能从已购买的代理中选择，且无法判断两个提供商是否共享基础设施。
中继节点由志愿者独立运营。 商业代理提供商则是拥有用户记录、计费系统及法律义务的公司。
以上这些并不能使 Tor 成为万能的解决方案——它速度较慢，许多网站会封锁它，而且不适合大规模数据收集。重点在于比较：如果匿名性是你的目标，那么一个为此设计的系统能胜任这项任务，而堆叠商业代理虽然形式上相似，却缺乏实质内容。
破坏整个链条的漏洞
一条链条的强度取决于其最薄弱的环节，而且有几条路径会完全绕过它。
DNS。 这是最常见的情况。如果直接向你的解析器发送查询，当你的流量经过三个跳点时，你的互联网服务提供商（ISP）会看到每一个主机名。 使用 SOCKS5 时，请采用 socks5h 方案，这样主机名将由代理而非本地进行解析——curl 中 socks5:// 与 socks5h:// 的区别正是如此，这也是代理配置中最常被忽略的细节。
WebRTC。 在浏览器中，它可能会将本地和公共地址暴露在代理路径之外。
**IPv6。**如果一个仅支持 IPv4 的链路同时具备 IPv6 连接能力，则部分流量会直接传输。这种情况悄无声息，除非进行测试，否则无法察觉。
**proxychains 下的静态链接二进制文件。**如上所述：拦截机制根本不适用，程序会直接连接且不会发出任何警告。
截获进程之外的任何内容。 系统更新程序、遥测服务、后台服务。它们从未进入过代理链。
一般原则：验证而非假设。 检查网站是否报告了外部 IP 地址，仅能证实一个显而易见的变化。我们的 代理测试指南 详细介绍了如何正确检查 DNS、WebRTC 和 IPv6；对于代理链而言，这种验证的重要性非但不会降低，反而会更高，因为其中可能出现故障的环节更多。
链式连接的正当理由
真实案例，其中没有一个涉及匿名性。
访问无法直接连接的网络。 企业代理是您唯一的出站通道，而您需要通过它再连接第二个代理才能访问特定目的地。 这属于“管道式”代理链，也是迄今为止最常见的正当用途。
协议桥接。 你的应用程序仅支持 SOCKS 协议，但可用的代理却是 HTTP 协议，反之亦然。本地代理会进行协议转换并转发请求。这同样属于“管道式”应用。
**在本地跳点添加功能。**运行本地代理以进行缓存、日志记录、请求重写或 TLS 检查，然后将其转发给上游代理。这是一个第一跳的存在目的在于执行特定任务而非隐藏任何内容，这在开发和测试中是标准做法。
无法直接购买的地理路由。 有时，您需要的出口位置只能通过中间节点才能到达。这种情况虽罕见，但在构建链路之前，仍值得确认服务商是否直接提供该位置。
测试多跳行为。 如果您正在构建需要在多个代理后端运行的系统，测试该路径是合理的。
请注意这些情况的共同点：链条的存在源于路由限制，而非基于“跳数越多越好”的假设。这一区别值得您在自己的场景中加以应用。
大家还问
串联代理能否提高匿名性？
只能略微提高，且效果不如预期。这确实意味着没有任何一个中继节点能同时看到您的地址和目标地址。但它无法防范流量关联、服务商之间的共同所有权，也无法防止通过Cookie、登录信息和指纹识别在应用层进行身份识别。 简单的代理串联也不会增加加密——每个中继节点都能看到 TLS 未保护的内容。
我应该串联多少个代理？
出于合理的路由考虑，应尽可能少地串联——通常为两个。 若为匿名性考虑，无论数量多少，串联商业代理都不是正确的方法，而专门为此设计的系统效果更好。每个额外的中继节点都会增加延迟，成倍提高故障概率，并导致带宽费用翻倍。
什么是 proxychains 以及它是如何工作的？
这是一个 Unix 工具，它钩住动态链接程序中的网络相关 libc 函数，并将连接重定向至 SOCKS4a/5 或 HTTP 代理。它提供精确、动态且随机的链路排序。其主要局限在于仅适用于动态链接的程序——静态链接的二进制文件会直接连接，且不会发出警告。
代理链路会变慢吗？
是的，这是必然的。每个跳点都会增加一次往返时间和处理时间，因此两跳链路大致会使单个代理的成本翻倍。吞吐量受最慢跳点的限制，如果每个跳点的可靠性为 95%，那么三跳链路的成功率约为 86%。
能否将 VPN 和代理串联起来？
从技术上讲可以，而且这种做法很常见。实际效果通常是延迟增加，而各方的观察结果仅有微小变化。您的 VPN 提供商仍然能看到您正在连接，代理运营商仍然能看到您的请求，而且这两种方案都无法解决应用层的身份识别问题。
链式连接能阻止网站追踪我吗？
不能。追踪是通过 Cookie、浏览器指纹、账户登录信息和行为模式实现的——这些因素均不受流量经过多少个网络跳转的影响。路由仅会改变网站记录的地址，而网站早已不再仅依赖地址进行识别。
Tor 是一种代理链吗？
它是一种具备三项手动链所缺乏特性的链式连接：分层加密，确保任何中继节点都无法读取下一节点接收的内容；用户可从发布目录中选择路径，该目录设有约束条件以避免相关联的中继节点；以及由志愿者独立运营的中继节点。 Tor 项目将此与普通代理进行了对比，后者“会形成单一的信任点和故障点”。
在链中，我是否需要为带宽支付双倍费用？
如果两个中继点都实行流量计费，答案是肯定的——每个字节都会经过这两个中继点，并由两者分别计费。如果两个家庭宽带服务均按 0.79 美元/GB 计费，传输相同数据将花费 1.58 美元/GB。这正是我们在构建链路之前，必须先确认该链路是否确实能解决问题的一个直接原因。
总结
代理链是一种路由技术，常被宣传为隐私保护技术，但二者并非同一回事。
作为路由技术，它有时确实恰到好处：例如通过企业代理连接到需要另一个代理的目的地，在 SOCKS 和 HTTP 之间建立桥梁，或者在前面放置本地代理以进行缓存和日志记录。在这些情况下，链路的存在源于某种限制，而额外的延迟则是这条路由的代价。
作为隐私保护手段，它只是某种强大隐私机制的弱化版本。手动构建的代理链不会增加任何加密，因此每个中转节点都能读取 TLS 未保护的内容。它无法判断两个服务商是否共享基础设施，对流量关联性毫无作用，更无法应对 Cookie、登录信息和指纹识别——而这些才是身份识别真正发生的地方。
与此同时，成本却是确定的。延迟会累加，可靠性会成倍下降，而按流量计费的带宽费用则要翻倍。如果你正在考虑使用链式连接，一个有意义的问题是：它究竟解决了哪一项具体的路由限制？如果答案是“跳数越多似乎越安全”，那么从数学角度来看，这并不划算。