Testing a proxy from the wrong place

Somebody sent me a terminal paste as proof his line was dead. The command had run fine. It came back in under half a second with a full page. And the exit address printed at the bottom of the output belonged to his home broadband provider.

His proxy flag had been ignored. The request went out over his own connection, returned cleanly, and he had spent the previous hour deciding my rack was on fire.

I run that rack. Real SIMs on Singapore carriers, modems on shelves, one port per modem, and every support message lands on me. So I read other people’s tests for a living, and after a couple of years of it I have stopped treating the test as the reliable half of the report.

Two neighbouring jobs get folded into this one, so let me set them aside. Leak testing asks whether your real address escapes through DNS or WebRTC while the proxy is up, and it runs off a fixed checklist. Diagnosing a genuinely slow line is about weak signal, hot hardware and busy towers, and the repair is physical. What follows sits underneath both of those. It covers tests that never measured the thing you were worried about, which makes the result evidence of nothing.

The first line of any test is the exit address

The failure that fools the most people fools them in the direction of good news. You set a proxy, the test returns something fast and healthy, and you write the line down as fine when the request never left your own connection.

The ways this happens are boring and numerous. A CLI tool reading a proxy from an environment variable your shell never exported. An HTTP library that honours the proxy for plain HTTP and quietly skips it for HTTPS. A desktop app whose proxy tab only governs one of its features. A script where the proxy is bound to a session object and one later call reaches for a bare client instead.

None of those announce themselves. Every one of them is caught by the same move: make your test print the address the far end saw, and read it before you read anything else. If it is yours, stop. If it belongs to a hosting company rather than the carrier you pay for, stop for a different reason. Half the reports that reach me collapse at this step, and it costs ten seconds.

Your browser leaves by more doors than you set

Browsers are the hardest thing to test with, because a browser is a bundle of network activity that does not all obey the same setting. There is the page fetch. There is name resolution, which frequently lives somewhere else entirely. There are extensions with their own outbound calls, and a media stack that occasionally opens a path of its own.

Set a proxy in an extension and you route the page loads. The lookups may keep going out over your own connection, because your resolver was configured at the operating system level and never heard about the extension.

One customer was certain his line dropped requests at random. It did not. His browser was resolving names locally, receiving an address from a service that answers differently depending on where the question originates, and then dialling that address through Singapore. He was reaching a server on the wrong continent every time. Erratic, slow, completely explainable, and nothing at all to do with the modem.

If a browser has to be in the test, use a profile or a system level configuration that routes lookups as well as pages. Otherwise put it away and test with a tool whose entire path you can see.

Why a speed test is the worst instrument here

Here is the opinion I will defend. A speed test is the least informative thing you can run against a proxy line, and it is the first thing almost everybody runs.

Look at what it does. It selects a server geographically near your exit, opens a stack of parallel connections, and pushes as hard as it can for a few seconds to find a peak. That is a burst against a machine chosen for being close and idle.

Your actual work is a small request to one specific site, usually far away, which holds an opinion about who you are and enforces its own rate limits. The burst figure speaks to none of that.

It misleads in both directions, which is the part people miss. A good number relaxes somebody about a line that is going to fail them, because bandwidth was never going to be the failure. A bad number gets a replacement demanded for a line that would have been perfect, because the job needed four hundred kilobits and the test told a frightening story about a peak.

A mobile line hates being measured this way on top of everything else. One radio, one modem, one antenna. Sixteen parallel streams hunting a maximum is precisely the load pattern that makes the number look worst, and it is a load your real job would never produce.

The number is real. It just answers a question you never asked.

A protocol mismatch reads as a dead line

This one is quick and it generates the most confusing errors of the lot. A port speaks a protocol. Point an HTTP client at a SOCKS5 port, or configure a SOCKS5 proxy against a port that only understands HTTP, and nothing polite comes back to explain the mismatch. You get a hang, or a reset, or a run of bytes your client cannot parse and reports as something unrelated.

That gets written up as the line being dead. One customer had the right host, the right password, and a port number one digit off, landing on a neighbouring service that answered just enough to look alive. He burned an afternoon on it before mentioning it.

The reputation you brought with you

Now the expensive one, because the test looks correct in every visible way. You route properly. You aim at the real target. Blocks come back, or captchas, or responses that crawl, and you conclude the address is burned.

The machine you tested from has been hitting that same target all week. It carries cookies. Its browser profile has a history. It may be wearing a fingerprint the site has seen a hundred times, attached to behaviour the site did not care for.

What returned was the target’s opinion of you. It got filed against the line.

I see it most in people migrating off a setup that was already in trouble. Same machine, same profile, same account, a fresh address in front of it, and an expectation of a clean slate. The address was the only variable that moved and it was not the one being judged.

Separating the two is easy enough. Run the same request from something with no history: a fresh profile, a clean container, a machine that has never touched the site. Clean through the proxy means your address is healthy and your identity is the problem. Blocked from everywhere means something else is going on and it is a longer conversation.

The whole test fits in a paragraph

One request. To the target you actually care about. With the full path routed, lookups included. Compared against the same request from the same machine with the proxy switched off.

The comparison carries the entire diagnosis. One variable moves. Your code, your headers, your machine and your account all hold still, so any difference that appears belongs to the network path.

Read three things off it. Whether it completed. What came back, precisely, including the status and the opening of the body. And how long it took, timed from your side. No average of thirty runs. No peak. The request your job makes, once, honestly.

Then repeat it a few times across the day, spaced out. A Singapore line at nine in the evening is a different animal to the same line at four in the morning, because a few million people are on those towers watching video on the way home. One sample at rush hour is a story about the city.

Reading the outcome

Works without the proxy and fails with it, and you have handed me something I can act on. I will go and look at that line.

Fails both ways, and the network was never the cause. A different address would not have helped.

Works both ways while your job still falls over, and the trouble lives in volume, timing or behaviour, which a single request was never going to reveal.

The monitoring I built that lied to me

For a long stretch my own health checks were a plain request to a page that echoes the exit address. Cheap, quick, ran every few minutes across the fleet. Everything came back green while customers were reporting failures on those same lines.

The echo page loved us. It is a tiny endpoint with no opinion about anybody and it answers everything. It was reporting whether the tunnel was open, which was never the question. The question was whether a real destination would accept a real request, and I had built a system that carefully avoided asking it.

I had done the exact thing this whole piece argues against. I picked a target because it was convenient rather than because it resembled the work.

The fix was to point those checks at destinations that behave like the real internet, with a proper handshake and a response worth comparing against a known good one, and to judge each line against its own history rather than one fixed threshold. The fleet stopped being green. That was the point of the exercise.

If you want lines to run that comparison against, that is what I rent: real Singapore mobile IPs on Singtel, M1 and StarHub SIMs, sticky ports you can hold for a whole job, and DNS routed through the tunnel so your lookups stop leaving out the side. There is a free trial of Singapore Mobile Proxy, and the code YT30 takes thirty percent off your first month.

Get new guides and videos first — join the Telegram channel.