proxymint Lab #1: DNS, headers and redirects on our gateway
Proxy leak test results from our residential and mobile gateway: where DNS resolves per scheme, which forwarding headers arrive, and what plain HTTP gets.
Quick summary · TL;DR
- CONNECT and socks5h resolve names on the proxy side. Our US test exits looked up target hostnames through US public resolvers, so the lookup never touched the client's network.
- Plain socks5 leaked every lookup to the client. With socks5:// the client resolved the name itself and the test saw the client's own resolver, in another country.
- No Via or Forwarded header reached the target. Over CONNECT to an https:// site the gateway only relays the encrypted connection, so it has no way to add X-Forwarded-For either.
- Plain http:// targets get a redirect, not a page. The gateway answered every plain HTTP request with a 301 to the https:// address.
Proxy leak test results from proxymint’s own gateway, measured on 2026-09-28: over HTTP CONNECT and socks5h:// target names resolved on the proxy side, plain socks5:// leaked the lookup to the client, no Via or Forwarded header reached the target, and plain http:// targets received a 301 to https://.
This is the first proxymint Lab page. Lab pages publish what we measure on live exits, with the date, the sample and the command behind each number, so anyone can rerun them against any provider, including us. This one shows what did happen on a real gateway, and how to check yours.
What we tested and how
We opened two fresh packages on the gateway customers use, one rotating residential and one mobile, both with US exits and sticky rotation, and sent every test through each. Each test is a single curl request, so the results match what curl and Python requests see; other clients differ on socks5://, see the table below.
The DNS test works because every run asks for a random subdomain. No cache can answer it, so the authoritative server records the resolver that really asked, and that resolver’s address tells you where the lookup happened. The curl manual (checked September 2026) documents the scheme difference we tested: with socks5:// curl resolves the hostname locally, with socks5h:// it hands the hostname to the proxy.
Proxy leak test results
The residential exit sat on a home broadband line on a consumer ISP (AS7018) in Dallas, TX, and the mobile exit on a carrier network (AS21928) in Charlotte, NC.
Three of these results decide how a real job behaves.
DNS follows the scheme. The two SOCKS results explain most “proxy DNS leak” reports. With CONNECT and socks5h:// the target hostname never touched the client’s network. With plain socks5:// the client did the lookup itself, so its resolver saw every target the job visited, and CDNs could answer for the client’s location instead of the exit’s. A job that checks regional prices can then read the wrong country’s page while every request still exits in the right one. The fix is one letter in the proxy URL.
The gateway stays out of the request. No Via or Forwarded header arrived, and over CONNECT to an https:// site the gateway only relays encrypted bytes, so it has no way to add one. That matters for detection, because a Via or X-Forwarded-For header announces a proxy before any IP lookup happens. RFC 9110 (June 2022) expects a forwarding proxy to add Via on plain HTTP, which is why a forward proxy that handles plain HTTP can leak it. Tunnelled HTTPS gives an intermediary nothing to add, and our gateway added nothing on its own side either.
Plain HTTP is redirected. A health check written as curl http://example.com through the proxy reports 301, not 200, and looks broken. Point checks at https:// URLs and the redirect never appears.
Which clients resolve where
The scheme only matters if the client honours it. These are the documented behaviours for common clients, checked against each project’s docs in September 2026.
The safe default for scripts is an http:// proxy URL, which every client above resolves at the proxy. If a job must run over SOCKS5, write socks5h:// in the clients that know the difference. The DNS side of detection is one reason: a resolver in the wrong country is a cheap signal for a site to check.
Reading your own proxy leak test results
Run the same checks against your own setup and read each row this way.
- Resolver country differs from the exit country over CONNECT or socks5h://: the provider resolves somewhere else. Ask where, and whether they offer resolution closer to the exit.
- Resolver is your own ISP or office DNS: the client resolved locally. Switch to an http:// proxy URL or socks5h://.
- Via or Forwarded appears: the proxy announces itself. On a paid residential or mobile service that is a configuration problem worth raising.
- More than one X-Forwarded-For hop: something in the path, your code or the provider, adds your address. Find which before running account work.
- Plain http:// returns 301: expected on gateways that force HTTPS, including ours.
Reproduce it
Every row above is one curl request, so it reruns through any provider. Replace USER, PASS, HOST and PORT with your own proxy details; how to use a proxy shows where each one comes from:
# exit IP, network and location
curl -s -x http://USER:PASS@HOST:PORT https://ipinfo.io/json
# headers the target receives
curl -s -x http://USER:PASS@HOST:PORT https://httpbingo.org/headers
# plain http:// target (a 301 on gateways that force HTTPS)
curl -sI -x http://USER:PASS@HOST:PORT http://example.com
# DNS: which resolver looked the name up, once per SOCKS mode
curl -sL -x socks5://USER:PASS@HOST:PORT https://edns.ip-api.com/json
curl -sL -x socks5h://USER:PASS@HOST:PORT https://edns.ip-api.com/jsonFor DNS, the last two commands do it: edns.ip-api.com redirects every request to a hostname it has just issued, so each lookup is fresh, and its JSON names the resolver that asked. A resolver in your own network on the socks5:// run is the leak the results above show.
Limits and what comes next
One package per tier, US exits, one day. The scheme behaviour follows from how CONNECT and SOCKS5 work and will hold everywhere; the resolver location is specific to what we measured. Not measured yet: resolvers for non-US exits, and the static ISP and datacenter tiers. Those come next, together with session survival over hours.
For how these signals feed detection, see how mobile carrier IPs behave and the types of proxies.
Frequently asked questions
Some proxies do, and plain HTTP forwarding proxies often add Via. In our test, the proxymint residential and mobile gateway added no Via or Forwarded header to requests sent through CONNECT. Over CONNECT to an https:// site a proxy cannot add X-Forwarded-For at all, because it only relays the encrypted connection. Headers the client itself sets are passed through unchanged.
On the proxy side over HTTP CONNECT and socks5h://: on both tiers the target hostname went to the proxy and was looked up through US public resolvers, so the lookup never touched the client's network. Over plain socks5:// the client resolved the name itself, and the test saw the client's own resolver. Measured 2026-09-28, one residential and one mobile package, US exits.
Send one curl request per test through the proxy: an IP lookup for the exit, an echo endpoint for the headers the target receives, a plain http:// URL for the redirect, and a never-seen hostname under a resolver-echo domain, once over socks5:// and once over socks5h://, for DNS. The commands are in the Reproduce it section of this page.
The gateway redirects plain HTTP targets to their https:// address instead of forwarding them. A client that follows redirects ends up on the HTTPS page; a check that expects 200 from an http:// URL should use https:// instead.
No. This is one package per tier, US exits, measured on 2026-09-28. The scheme behaviour follows from how CONNECT and SOCKS5 work and will not vary by exit, but resolver location outside the US and header behaviour on other tiers are not measured yet and are marked as open.