Proxy chaining and when it helps
Somebody sent me a scraper config with two proxies stacked in it, one routed through the other, and asked which address the target would see.
The second one. Only ever the second one. He had been paying for the pair for three weeks on the theory that the site was getting a diluted view of him.
His block rate had not moved either, which was the real question under the one he asked.
The mechanism is duller than the diagram
Your client connects to the first proxy. The first proxy connects to the second. The second connects to the site. Every byte crosses all three legs, in both directions, and comes home the same way.
Nothing else happens. No extra layer of encryption at the join, no fresh identity minted. It is one tunnel handed to another, over the same CONNECT a single proxy already does, and the second box has no idea it is the second box.
People imagine something more architectural, and the distance between the imagined thing and the real one is where the money goes.
The target gets one address and no hop count
No field in an HTTP request says how many machines the bytes crossed, and nothing in the TCP or TLS setup exposes it either. A chain leaves your TLS fingerprint and your header order exactly as they were.
So the site sees the exit, and that is the entire surface. Identical to what one proxy in the same position would show.
Check it on your own account in two minutes. Fetch an address echo through the full chain, then through the second proxy alone, then the same against a TLS fingerprint endpoint. Same address, same fingerprint.
Which is why chaining is a bad answer to blocking. The exit decides that, the exit has not changed, and tomorrow’s success rate matches today’s.
What changes is which company knows which half
The first proxy sees your address, your timing and your volume. It knows who you are. The furthest thing it can see downstream is the second proxy, so your destinations never reach it.
The second proxy sees every hostname, and full request bodies too if the traffic is plain HTTP. It has no idea who you are. Its customer, as far as it can tell, is the first proxy.
Two halves of one fact, held by two companies, neither holding the pair. Which tells you who the defence is aimed at: the provider. Their staff, their logs, whoever subpoenas them, whoever buys the drives when they fold.
That is a legitimate worry and a very specific one. Most people asking me about chaining have never said it out loud. They want to be safer in a general direction, and there is no such direction.
Reachability is the honest reason
The first case where I have built a chain and would again has no privacy content at all.
Sometimes the exit cannot be reached from where you are. A host network that blocks the SOCKS port outbound, so the only route runs through a box on a network that does not. A seller who supports address whitelisting and nothing else, while your workers autoscale and pick up a new address on every start, which is a shape a whitelist cannot describe.
The fix in both cases is the same. One small static box in front, registered or reachable once, everything else routed through it.
That is a chain, and it is plumbing. I would not call any of it a privacy measure.
Splitting knowledge on purpose
The second case is the split, bought deliberately. No single company gets to connect your identity to your list of destinations, so you buy the first hop from one seller and the second from another, knowing what the arrangement costs.
The reasoning is sound. It survives exactly as long as the two companies are separate, and this industry is mostly resellers.
A small number of outfits own infrastructure. A much larger number buy wholesale, put a dashboard on top and price it their own way. Two brands with different domains and different plans can be two doors into one pool. If that is what you bought, one owner sees both ends, and the split you paid twice for is decorative.
Checking whether your two sellers are one company
- Pull twenty or thirty exits from each account and look up the ASN behind them. Overlap is the loudest signal available.
- Watch for repeated addresses across the two pools. A shared pool hands the same address to two customers eventually.
- Compare the dashboards. White label panels come from a handful of products, down to the same odd column headings.
- Read the billing entity on your card statement rather than the website. A company name is harder to rebrand than a landing page.
- Ask each of them who they buy from, then notice which one will not answer.
None of that is proof. It catches the lazy version, and the lazy version is most of them.
Latency sums, and TLS makes it worse
Every hop adds a round trip, and a chain adds them rather than averaging them, in both directions.
My Singapore line to a Singapore target sits in the low tens of milliseconds. Put a European box in the middle and you pay the Singapore to Europe leg going out and again coming back. A page that returned in roughly two hundred milliseconds came back at about six hundred on a job I measured last year.
Connection setup is worse than that ratio suggests. A TLS handshake costs several round trips before any request data moves, so the added leg gets charged more than once per connection. Reuse connections and you pay it once. Open a fresh one per request and you pay it on every item in the queue.
Availability multiplies the wrong way
Two legs at ninety nine percent each give you a chain at about ninety eight. You have doubled your bad days and bought nothing the target can perceive.
Real failures are worse than the arithmetic, because they arrive correlated in ways multiplication cannot model. A rotation on the far provider kills your session. Either subscription lapsing at midnight takes down the whole path.
Then there is support. Two vendors means working out which one to write to before you can open a ticket, and each will point at the other. I have been the vendor on the receiving end: my side clean for the whole window a customer was complaining about, no visibility into the leg he bought elsewhere, nothing to tell him except that it is not us, which is precisely what a bad provider would say.
A third machine in the error path
Separating a proxy error from a target error is the main diagnostic skill in this work. It is a subject of its own, written up separately, so I am not rebuilding it here.
What a chain does to it is add a machine. One proxy in the path means two candidates for any given response. Two proxies means three, and most of the tests that split provider from target quietly assume there is one provider.
The 407 rule survives, since only a proxy sends one, but it stops telling you which proxy. The timing test survives in a weaker form: anything returning faster than a full chain round trip was manufactured inside the chain, and you still cannot say which box wrote it.
So log the hops as separate fields before you run one. First hop, second hop, connect time per leg. Without it you are picking one machine out of three from a single error string.
The part you cannot verify
The whole split rests on neither provider keeping records. The moment one of them logs, and the two sets are ever put side by side, the thing you bought is gone.
No request you send through a gateway tells you whether it wrote a line to disk. A no logs claim is a paragraph on a marketing page, and I run a marketing page myself. Registration country and years trading are context, not evidence, and treating them as evidence is how people end up feeling protected while being written down twice.
Write the sentence before the second invoice
One sentence: who is the adversary, what do they learn, and what happens to you next.
Nine times out of ten it lands somewhere a chain does not reach. The target might block my exits. My provider might oversell the pool and hand me a slow line. A second proxy improves neither.
When it comes out right it reads like this. I do not want the company that knows my identity to also hold the list of hosts I visited. That is coherent, chaining answers it directly, and the latency and the doubled failure rate are a fair price.
I sell proxy lines, it would suit me to sell you two, and I still talk people out of it most times it comes up.
What I cannot tell you
I have never run a three hop chain in production. People do. The availability arithmetic gets ugly fast and I have no measurements of my own on whether a third split buys anything real.
I also cannot promise that any given pair of sellers is unrelated. I can tell you how I check, and that I have been wrong once: two brands I had treated as separate were answering support from the same desk, and I caught it because the same slightly odd phrase turned up in replies from both. That was luck, and luck is a poor foundation for a privacy design.
The checks I run on a pair of providers before I will chain them, and the per hop log fields that make a chain debuggable, are here.
Get new guides and videos first — join the Telegram channel.