两个代理设置可能造出你并不想要的链路

你的应用指向代理 B，但它是通过一个为代理 A 配置的包装器启动的。网站看到的出口是哪一个？答案取决于包装器拦截的是哪一条连接。

在简单的嵌套结构中，应用首先尝试连接 B。包装器拦截这条连接并让它经由 A 转发。随后，应用在这条流上使用 B 的代理协议，由 B 建立最终的网站连接。

application → wrapper proxy A → application proxy B → website

网站看到的是 B 最终的对外连接。B 看到的是一条经由 A 到达的连接。这与包装器静默覆盖应用自身代理设置的情形不同。

简单示意图是有条件的

绕过规则、不受支持的套接字调用、已存在的进程，以及各产品自身的拦截模型，都会改变实际路径。有些包装器可以把自身代理或指定目标排除在外。不要假设任意两种工具叠加后行为都一样。

proxychains-ng 的说明解释了它的拦截方式和限制。使用原生代理支持的程序仍然会向该代理发起网络连接，这正是可被拦截的候选之一。

若要刻意串联多个未认证的公共出口，免费代理列表提供的候选必须与各工具支持的协议相匹配。遇到意料之外的出口时，请分别记录三个地址：应用选择的出口、包装器选择的出口，以及网站实际看到的结果。只看浏览器里的设置，就会漏掉中间这一层。

在确认预期行为时只使用一条路径，确有必要串联时再加入另一条。额外的跳数会增加故障点，也会带来不同的信任关系。它们不会自动清除用于识别的 Cookie，也不会让应用中的所有连接都走同一条路径。