DNS resolution inside a SOCKS tunnel

Most people who run scrapers through SOCKS proxies never think about DNS until something goes wrong: content comes back in the wrong language, pricing is off, or a target that should see a US residential IP is somehow still seeing traces of your home network. Nine times out of ten, the cause isn’t the proxy. It’s where the DNS lookup happened before the proxy ever got involved.

DNS resolution inside a SOCKS tunnel is one of those details that looks trivial and isn’t. Get it wrong and your “clean” residential exit is sitting on top of a DNS query that never left your own network. Get it right and you have one less inconsistency for a target site to notice.

What SOCKS actually tunnels

SOCKS4 only ever forwards connections to an IP address. If your client wants to reach example.com, it has to resolve that hostname to an IP itself, locally, before it even talks to the proxy. The proxy has no idea a hostname was involved. This is why SOCKS4a exists as an extension: it lets the client send the hostname as a string and asks the proxy server to do the resolution on its end instead.

SOCKS5 formalizes this properly. The protocol defines three address types in its request format: IPv4, IPv6, and a domain name. When a client sends a domain name as the destination, the SOCKS5 server is the one that resolves it, using whatever resolver it has configured on its own network. That’s “remote DNS” or “proxy-side DNS.” When the client resolves the hostname itself and only sends the proxy a raw IP, that’s “local DNS,” and the proxy server never sees the domain name at all.

The protocol supports both. Which one actually happens depends entirely on how your client library or tool is configured, not on the proxy.

Where the resolution actually happens in practice

This is the part that trips people up, because the default behavior is inconsistent across tools:

curl defaults to local resolution with a plain --socks5 proxy flag. If you want the proxy to do the DNS lookup, you need --socks5-hostname instead, or the socks5h:// URL scheme.
Python’s requests library, when using PySocks under the hood for SOCKS support, resolves locally with a socks5:// URL and remotely with socks5h://. That single letter h is the whole difference.
Browser automation tools (Selenium, Playwright) generally hand SOCKS proxy settings to the underlying browser network stack, and Chromium and Firefox both default to remote DNS resolution over SOCKS5, which is the opposite default from curl and requests.
Scrapy and most async HTTP clients inherit whatever behavior their SOCKS transport library implements, and that’s worth checking per library rather than assuming.

None of this is a bug. It’s just that “SOCKS5 proxy” isn’t a single behavior, it’s a protocol capability, and the client decides whether to use it. A scraper built by copying a socks5:// URL from a proxy provider’s dashboard into a requests session, without checking whether that’s the local or remote variant, can end up doing local DNS through a residential exit without anyone noticing for months.

Why the difference matters for scraping

When DNS resolves locally, your machine sends a query to whatever resolver it’s configured to use, your ISP’s resolver, a public resolver like a 1.1.1.1 or 8.8.8.8 you’ve set, or a corporate DNS server. That query happens outside the tunnel entirely. The proxy only sees the IP address afterward.

Two consequences follow from that, both purely from how DNS and CDNs work, not from anything mysterious:

Geo mismatch. A lot of content delivery networks use the resolver’s location, not just the requesting IP’s location, to decide which edge server or regional answer to hand back. If your DNS query comes from a resolver in Singapore but your SOCKS exit IP is a residential address in Ohio, you can get a response that was built for the wrong region: wrong currency, wrong language variant, wrong regional catalog. The exit IP and the resolver told the target two different stories about where the request came from.

Split visibility. Anything that logs DNS traffic on your own network, or any downstream party that can see resolver query logs, sees the actual hostnames you’re requesting, tied to your real network, completely independent of whatever exit IP the proxy shows the target site. That’s a privacy and operational hygiene issue more than a “will I get blocked” issue, but it’s worth being clear-eyed about: local DNS means the tunnel isn’t actually carrying the full request.

Neither of these means a target site can reliably fingerprint you off DNS behavior alone, and nobody should treat matching resolver and exit geography as a way to avoid detection. It’s simply a consistency problem: if you want a scraper’s traffic to look like it plausibly originates from one place, the DNS resolution should happen in the same place as the exit IP. That’s a correctness question, not an evasion technique.

Checking whether your tunnel is leaking DNS

This is a diagnostic step, not a workaround, and it’s worth building into any proxy setup before you trust it for anything geo-sensitive:

Pick a test endpoint that echoes back the IP address it saw the request come from (a “what’s my IP” style service is fine for this).
Send a request through your SOCKS proxy using local resolution (socks5:// in requests, plain --socks5 in curl) and note the result.
Send the same request using remote resolution (socks5h://, --socks5-hostname) and compare.
If both return the same exit IP but you want to confirm DNS specifically, use a dedicated DNS leak test service through the tunnel and check whether the resolver it reports matches the geography of your proxy exit or your real network.

If the exit IP is identical either way but the resolver location clearly matches your ISP rather than the proxy’s network, you’re resolving locally. That’s fine for some use cases and a real problem for others, geo-targeted scraping being the obvious one.

How this varies across proxy types

Datacenter, residential, and mobile proxy providers differ in how much DNS handling they do server-side versus leaving to the client, and that’s genuinely provider-specific rather than something tied to the proxy type itself. Some gateway-based residential and mobile networks route DNS through their own infrastructure by design, so remote resolution is effectively forced regardless of client settings. Others are a thinner SOCKS relay where the client’s chosen scheme is what actually decides it. There’s no shortcut here: the only reliable way to know is to run the check above against the specific provider and proxy type you’re using, rather than assuming based on the marketing page.

What a clean setup looks like

For scraping work where geographic consistency matters, the practical habit is simple: standardize on remote DNS resolution (socks5h:// or equivalent) across your proxy pool, verify it with the leak check above when you onboard a new provider or pool, and log which resolution mode was used per request if you’re debugging inconsistent responses later. If a target’s content varies unexpectedly by region even though your exit IPs look correct, DNS resolution mode is one of the first things worth ruling out, before assuming it’s a blocking or fingerprinting issue.

Getting DNS resolution right doesn’t make a scraper undetectable and it isn’t a defense against bot detection systems, which look at far more than resolver geography. It just removes one avoidable inconsistency between what your exit IP claims and what your request actually did. That’s worth doing regardless of what else your scraping setup is up against.

If you want more breakdowns like this on how proxy infrastructure actually behaves in production, from DNS handling to picking between residential, mobile, and datacenter pools, you can find the rest of our writing on the site home page.

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