A Longer SOCKS Chain Does Not Automatically Hide the Next Hop

A chain changes who opens each connection. It does not add encryption simply by adding another SOCKS address to a list.

Consider a client that constructs this chain itself:

application → SOCKS A → SOCKS B → website

It first asks A to connect to B. Through that stream, it can then negotiate with B for a connection to the website. If the client-to-A transport carries both negotiations without encryption, a sufficiently capable observer on that link can read the setup bytes that the client sent. The outer TCP destination is not the observer's only possible evidence.

Separate the chain from the protected application exchange

HTTPS can protect the website's application content after its TLS session begins. It does not retroactively encrypt earlier SOCKS setup messages. SOCKS5 username/password authentication is not an encrypted transport either.

An encrypted client-to-first-hop arrangement changes visibility on that link. It still has an operator and another endpoint holding the decrypted stream. Describe that trust boundary rather than claiming the chain is untraceable.

A server-configured parent route is another topology. If A selects B internally, the client has not necessarily sent a complete list of intermediaries over its first connection. Do not claim every chain exposes every hop in the same way.

For a useful privacy assessment, name the observer, the link, the proxy negotiation, and the TLS boundaries. The website observing B's exit and the access-network observer watching the client's first connection answer different questions. Counting hops alone answers neither one.