Two Proxy Settings Can Create a Chain You Did Not Intend

Your application points to proxy B, but it was launched through a wrapper configured for proxy A. Which exit does the website see? The answer depends on what connection the wrapper intercepts.

In a straightforward nested arrangement, the application first tries to connect to B. The wrapper intercepts that connection and carries it through A. The application then speaks B's proxy protocol over the resulting stream, and B makes the final website connection.

application → wrapper proxy A → application proxy B → website

The website sees B's final outward connection. B sees a connection arriving through A. This is different from the wrapper silently overwriting the application's own proxy setting.

The simple diagram has conditions

Bypass rules, unsupported socket calls, existing processes, and each product's interception model can change the path. Some wrappers can exclude their own proxy or selected destinations. Do not assume that every pair of tools composes identically.

The proxychains-ng description explains its interception approach and limitations. A program using native proxy support is still making a network connection to that proxy, which is one candidate for interception.

For a deliberate chain of unauthenticated public endpoints, the free proxy list offers candidates whose protocols must match each tool. For an unexpected exit, record three addresses separately: the endpoint the application chose, the endpoint the wrapper chose, and the website-facing result. Looking only at the browser's settings misses the middle layer.

Use one route while establishing the intended behavior, then add the other only if the chain is required. Extra hops can add failure points and different trust relationships. They do not automatically erase identifying cookies or make every connection in the application follow the same route.