What Still Leaks Through a Proxy — and How To Check Yours

A proxy changes the address a server sees connecting. It does not, by itself, change everything else your machine reveals — and the gap between those two statements is where most setups fail. The address check passes, so the configuration is presumed correct, and it stays presumed correct for months.

What a proxy does and does not cover

A proxy relays a connection. What travels through that relay is decided by the application, and applications differ in how completely they route through it.

SOCKS5 operates below the application protocol: it moves TCP, and optionally UDP, without interpreting the contents. It can also accept a hostname and resolve it at the far end, which is the property that matters most here. An HTTP proxy sits at the application layer, understands requests, and may add or rewrite headers as it forwards them.

Neither controls what your browser volunteers about itself. That distinction explains almost every surprising result below.

DNS: the leak that survives everything

Before connecting, something has to turn a hostname into an address. If your machine does it, the query goes to your configured resolver — typically your actual provider — and that resolver learns which sites you are visiting. The subsequent connection still exits through the proxy, so an address check shows the proxy address and everything appears correct.

SOCKS5 can avoid this by passing the hostname to the proxy and letting the far end resolve it. In client libraries the distinction is a single character: socks5:// resolves locally, socks5h:// resolves remotely. In browsers it is usually a checkbox about proxying DNS. In both cases the wrong setting produces no error and no visible difference.

This is the most common defect we see described, and it is invisible to the one test most people run.

WebRTC and the local candidate

WebRTC establishes peer connections and, to do so, enumerates the network interfaces available to it. That enumeration can expose addresses the proxy was never involved in — including a local network address and, depending on configuration, the real public one.

Because this happens through a browser API rather than through the proxied connection, no proxy setting prevents it. It has to be handled in the browser: disabled, or restricted so that only the proxied route is offered as a candidate. Antidetect browsers generally expose a control for exactly this, and it is worth confirming rather than assuming, since the default varies between builds.

Headers, and how HTTP differs from SOCKS5

An HTTP proxy can attach headers describing the forwarding — the family of fields that carry an originating address through a chain. Whether it does depends on the proxy. A transparent one may announce the client it is forwarding for, which defeats the purpose entirely.

SOCKS5 does not participate at this layer, so it adds nothing of its own. Whatever the browser sends is what arrives, unmodified.

This is a genuine argument for SOCKS5 beyond protocol flexibility: fewer components are in a position to add information about you. It is also why a mismatch between an accept-language header and the country of the exit address is a signal you have to fix in the client rather than at the proxy.

Consistency signals

Beyond outright leaks, there is a category that no proxy can address because it is about agreement between things you control.

A browser reporting a New York timezone from a Warsaw address is contradictory. So is an interface language that does not match the region, or a locale that disagrees with both. None of these is a leak in the strict sense — nothing escaped — but each is a discrepancy that costs nothing to check and is checked routinely.

The rule that covers all of them: everything the client claims should agree with where the exit address actually is.

A testing procedure

Run these in order, because each depends on the previous one being sound.

One. Load an address-check page. Confirm the address and country are what you intended. This is necessary and it is where most people stop.

Two. Load a DNS leak test. The resolvers listed should not belong to your own provider. If they do, DNS is resolving locally and step one told you nothing about it.

Three. Load a WebRTC test. No address should appear that differs from the proxy address. If one does, handle it in the browser — no proxy change will fix it.

Four. Check reported timezone and language against the exit country, and correct them in the profile rather than in the network layer.

Five. Load the actual target and confirm the content is localised as expected. A page that still shows default pricing after the first four steps pass usually means the site is reading something specific — a stored preference or an account setting — rather than the network at all.

Repeat this whenever a tool updates. Defaults get reset by upgrades more often than anyone expects, and a configuration verified six months ago is not necessarily the configuration running today.

FAQ

Does a proxy hide my traffic from my provider?

The contents of HTTPS traffic, yes, since TLS terminates at the destination. Which sites you visit, only if DNS is also resolved remotely.

Is WebRTC leaking a proxy fault?

No. It is a browser API operating outside the proxied path, and it has to be handled in the browser.

Does SOCKS5 leak less than HTTP?

It adds less of its own, because it does not touch headers. The larger leaks — DNS and WebRTC — depend on client configuration in both cases.

How often should I re-test?

After any update to the browser or client library, and whenever results change without an obvious explanation.