DNS Through Proxy: socks5 vs socks5h, Remote Resolution, and Leaks

Picture this. You've connected a proxy from the right region, checked your IP address — everything is correct, the city and country match. But the target website stubbornly shows you the wrong content, and the anti-fraud system flags your session as suspicious. Sound familiar? Chances are you've encountered one of the most insidious issues when working with proxies — a DNS leak or the wrong path for domain name resolution.

This article is a comprehensive guide to exactly how domain names are resolved into IP addresses when traffic goes through a proxy. We'll break down the fundamental differences between socks5 and socks5h schemes, who sends the DNS query and at what stage, why a website sometimes sees a completely different region than you expected, and how to set up remote resolution in popular clients and libraries. The topic is narrow but incredibly important. It's at the name resolution stage that thousands of seemingly well-configured setups fall apart.

Introduction: why the proxy is connected but the site sees a different region

Let's start with the symptom that brings most readers to this topic. You've configured a proxy. Your IP address is correctly masked — you can easily verify that on any IP detection service. Yet something is off: the site serves localization from another country, the CDN directs you to an unexpected node, and sometimes the target resource's security system blocks your request for no apparent reason.

The reason is almost always the same. Your HTTP or application traffic does go through the proxy, but the DNS query — the very request that turns a name like example.com into a concrete IP address — goes straight from your machine, bypassing the proxy entirely. And that query gives you away completely.

Why does this happen? Because name resolution and data transfer are two separate stages that can follow different routes. Many clients resolve the name locally by default, then send the already established IP connection through the proxy. From a network perspective, it makes sense. From a privacy and geolocation perspective, it's a disaster.

By the end of this material, you'll understand:

• who exactly performs the name resolution — the operating system, the application library, the browser, or the proxy server itself;
• how the socks5 scheme differs from socks5h at the protocol level and why one letter changes everything;
• how the CONNECT method in HTTP proxies almost automatically solves the resolution problem;
• through which channels DNS leaks occur even with seemingly correct configuration;
• how to enable remote resolution in curl, Python, Node.js, Go, Chrome, Firefox, Selenium, and Playwright;
• how to verify the actual resolution path using tools like dig, nslookup, and tcpdump.

Let's agree on boundaries upfront. We won't discuss which public DNS server is better or recommend specific providers. Our focus is solely on the resolution path when working through a proxy. Nothing more, nothing less.

Basics: what is name resolution and who performs it

To understand leaks, we must first firmly grasp the mechanics of resolution. Let's break it down.

What is domain name resolution

Computers communicate using IP addresses, humans use names. Resolution (from the English verb 'resolve') is the process of converting a human-readable name, like shop.example.com, into a machine IP address like 93.184.216.34. Without this step, no connection is possible: the browser doesn't know which server to connect to until it gets the IP.

Resolution is a separate network transaction. It typically uses the DNS protocol over UDP or TCP on port 53. The client sends a query to a resolver, and the resolver returns an answer. The key point? Who exactly sends this query and along which route is the central question of our entire topic.

Four possible resolution executors

When an application wants to connect to example.com, one of four participants can perform the resolution. Let's examine each.

1. Operating system

Most applications don't resolve names themselves. They call a system function — in the C world, this is getaddrinfo. The OS has its own resolver (stub resolver) that knows which DNS server to query, maintains a local cache, and respects the hosts file. This is the most common path. And the most dangerous in terms of leaks: the system resolver by default goes directly to the network, ignoring your proxy.

2. Application library

Some programs and libraries have their own resolution logic. They can either delegate the task to the OS, perform it themselves, or — most importantly — pass the name to the proxy server so that resolution happens on the remote side. This is exactly the mechanism implemented by socks5h schemes and proxy hosting.

3. Browser

Modern browsers are a whole universe of their own. They have their own resolution policies, DNS caches, mechanisms like DoH (DNS over HTTPS), connection preloading, and WebRTC. The browser can resolve a name completely independently of system settings, creating a whole class of leaks.

4. The proxy server itself

The ideal scenario for privacy. The client doesn't resolve the name at all. It passes the hostname string to the proxy server, which then performs the resolution on its own side and connects to the required IP. From the target website's perspective, the DNS query originates from the proxy's network, not yours.

Key analogy

Imagine you're sending a courier (proxy) with a package to another city. There are two ways. First: you find the exact recipient address from your local directory, write the coordinates on the package, and give the courier only the coordinates. The directory in your city might give a different address than the directory in the destination city — and you won't notice. Second: you give the courier only the recipient's name, and they find the address on the spot, using the local directory. The second method is remote resolution. It guarantees that the address is determined from the correct point in the network.

socks5 vs socks5h: where the resolution decision is made

Now we reach the heart of the topic. The difference between socks5 and socks5h is not cosmetic and not synonymous. They represent fundamentally different resolution paths, even though the underlying SOCKS5 protocol is the same.

What the SOCKS5 protocol says

The SOCKS5 protocol itself is flexible. In the connection setup command, the client specifies the type of destination address. Three options are possible:

• IPv4 address — the client sends a ready IP;
• IPv6 address — same, but for IPv6;
• domain name — the client sends a name string, and then the proxy server must perform the resolution.

So the protocol itself supports both local and remote resolution. The question is only which address type the client will send. And here, naming conventions come into play.

The socks5 scheme: local resolution

When a client uses the socks5 scheme (without the letter h), the established convention means: resolve the name locally. The client first asks its own resolver (usually the system's) for the IP of example.com, gets the address, and then sends the ready IPv4 or IPv6 to the proxy server.

What does the target website see? It sees the connection coming from the proxy — that's correct. But the DNS query went out from your network, on your side, through your local resolver. If your resolver is geographically or logically tied to your region, the target infrastructure via CDN and DNS geolocation can pinpoint your region, not the proxy's region. Hence the symptom from the introduction.

The socks5h scheme: remote resolution

The letter h in socks5h stands for hostname. This scheme tells the client: don't resolve yourself, pass the name to the proxy server. The client sends a command with the domain name address type, and the proxy server performs the resolution on its side.

What does the target website see now? The DNS query comes from the resolver used by the proxy, i.e., from the proxy's network. DNS geolocation points to the proxy's region. Your local resolver is not involved at all and knows nothing about where you're going. This is the correct, clean path for most tasks.

Mechanics comparison table

Let's summarize the differences compactly:

• socks5: resolution performed by the client (OS/library). Proxy receives an IP. DNS query leaves your network. Possible geographic mismatch and leak.
• socks5h: resolution performed by the proxy. Proxy receives the name. DNS query leaves the proxy's network. Region is consistent, no leak.

Remember the simple rule: if privacy and correct geolocation are important — always use socks5h. One letter saves hours of debugging.

Why this convention exists

A bit of historical context helps. Initially, SOCKS clients resolved names themselves because early versions (SOCKS4) couldn't transmit names. SOCKS5 added domain name support, but the tool ecosystem introduced the 'h' suffix to explicitly distinguish behavior. Thus the pair socks5 / socks5h was born, understood today by curl, Python, and many HTTP clients. It's a de facto naming standard, not part of an RFC.

HTTP and HTTPS proxies: why the CONNECT method resolves on the proxy

SOCKS is not the only proxy type. A huge portion of work tasks use HTTP proxies. Here the resolution mechanics are different, and in many cases better.

Regular HTTP request through a proxy

When you access an HTTP resource (unencrypted) through an HTTP proxy, the client sends the proxy a full request with an absolute URL. The request line contains the hostname. The proxy sees the name, resolves it itself, and connects to the server. So with plain HTTP proxying, resolution naturally happens on the proxy side. The client doesn't need to know the IP.

The CONNECT method for HTTPS

With HTTPS, things get more interesting. The encrypted traffic cannot be read by the proxy — nor should it. Therefore, a special method CONNECT is used for HTTPS. The client sends a command like CONNECT example.com:443 to the proxy. Note: here the hostname is passed, not an IP.

What happens next? The proxy server receives the name, resolves it on its side, opens a TCP tunnel to the target IP, and becomes a transparent pipe. Inside that pipe, a full TLS handshake occurs between your client and the target server — the proxy does not decrypt it.

The key takeaway: with a correct HTTP proxy implementation using the CONNECT method, resolution is remote by default. The name goes to the proxy, and the proxy resolves it itself. This is one reason why HTTP proxies for HTTPS traffic often behave more correctly out of the box than a misconfigured SOCKS proxy.

A note on client optimization

There's an important nuance. Some clients, aiming to optimize the connection, still resolve the name locally before sending CONNECT, and then pass the IP address in CONNECT instead of the name. Formally this is allowed, but it completely defeats the benefit of remote resolution. So even with an HTTP proxy, you can't blindly trust the behavior — you must verify it. We'll discuss verification methods in a separate section.

HTTPS proxy as a separate term

Don't confuse two meanings. Sometimes HTTPS proxy means a proxy that proxies HTTPS traffic (via CONNECT). Other times it means a proxy where the connection itself is encrypted with TLS (i.e., the client-proxy channel is secured). These are different things. From a resolution standpoint, the first meaning is more important: how the destination name is passed. Encryption of the channel to the proxy doesn't directly affect the resolution path, although it does protect the fact of the name transmission from an observer between you and the proxy.

DNS leaks: mechanics and typical scenarios

Now for the most interesting part — the anatomy of leaks. A DNS leak is a situation where a DNS query goes out bypassing the proxy, revealing your real resolver, region, or the very fact that you're accessing a specific domain. Let's go through the scenarios one by one, because each requires its own remedy.

Scenario 1: system resolver bypassing the proxy

The most common case. You've configured the application to use socks5 (without h), or the client simply doesn't support remote resolution. The application calls the system's getaddrinfo, the OS sends a DNS query directly to its resolver over the network, bypassing the proxy. The data then goes through the proxy, but the name has already leaked.

How to recognize: connections to the proxy arrive by IP, not by name. In your machine's network dump, you see outgoing packets on port 53 that are not wrapped in the proxy tunnel.

Remedy: switch to socks5h, enable remote resolution in the client, or isolate the application so it has no direct network access for DNS.

Scenario 2: WebRTC in the browser

WebRTC is a real-time technology for audio, video, and data transfer directly between browsers. To establish a connection, WebRTC uses the ICE mechanism, which gathers candidates — including resolving STUN server hosts — and can initiate requests that bypass the configured proxy. Historically, WebRTC was notorious for revealing real addresses even with a working proxy. Although modern browsers have significantly tightened policies, the risk remains if configuration is not careful.

Remedy: control WebRTC policy in the browser, disable or restrict ICE candidate processing, use browser settings that force all traffic including WebRTC through the proxy.

Scenario 3: built-in DoH in the browser

Modern browsers support DNS over HTTPS — resolution via an encrypted HTTPS request to their own DoH provider. The problem is that this request can go around your SOCKS scheme, directly from your machine, if the browser is configured to resolve via its own DoH and doesn't wrap this traffic in the proxy. It creates a paradox: the name is resolved encrypted and privately from the provider, but bypasses your proxy, which is worse for geolocation tasks. We'll cover this mechanism in detail in the DoH section.

Scenario 4: parallel IPv6 path

A particularly insidious scenario. Your proxy works over IPv4, you've set up remote resolution. But your machine has a working IPv6 stack, and the client, following the Happy Eyeballs algorithm (simultaneous attempts over IPv4 and IPv6), tries to resolve AAAA records and connect via IPv6 directly, bypassing the proxy. Part of the traffic and DNS leaks out. The region diverges, and some connections go the wrong way.

Remedy: disable IPv6 for the proxied application, or ensure the proxy supports IPv6 and all traffic, including AAAA resolution, goes through it. For many tasks, it's simpler to force the client to use only IPv4.

Scenario 5: cache and prefetching

Browsers and operating systems aggressively cache DNS and pre-establish connections (preconnect, prefetch). If the cache was filled before configuring the proxy, the application may use old entries or pre-established connections that bypass the new configuration. A small detail, but during debugging it can drive you crazy.

Remedy: clear the OS and browser DNS caches, restart, disable aggressive prefetching during diagnostics.

Common pattern of leaks

Did you notice a common pattern? All leaks boil down to one thing: there is a channel through which the name or connection goes not through the proxy. The engineer's task is to find and close all such channels. A leak is always an unclosed door, not magic.

Practice by tool: how to enable remote resolution

Now for the hands-on part. We'll go through specific clients and show how to enable remote resolution and prevent local resolution. This is the most applied section — keep it handy.

curl: socks5 vs socks5-hostname

curl is the benchmark tool for understanding the difference. It gives you an explicit choice.

• --socks5 host:port — local resolution. curl determines the IP itself, then goes through the proxy.
• --socks5-hostname host:port — remote resolution. curl passes the name to the proxy server.

Through the --proxy option you can also control the scheme: socks5://... gives local resolution, while socks5h://... gives remote resolution. Example of a correct call for remote resolution: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. For HTTP proxies, the http://... scheme with the CONNECT method resolves on the proxy by default, but you should still verify the actual behavior.

Python: requests and httpx

In the Python ecosystem, the socks5h scheme is the gold standard for remote resolution.

For requests, you need a SOCKS support package. Set the proxy via a dictionary: use the socks5h://user:pass@host:port scheme for both https and http. The socks5:// scheme without h means local resolution — and it's the most common cause of leaks for beginners. One letter decides.

For httpx, the logic is similar: pass a proxy with the socks5h:// scheme for remote resolution. httpx is strict about schemes and documents behavior well, but the principle is the same — the letter h switches resolution to the proxy side.

Important observation: even after setting socks5h, check that system proxy environment variables (HTTP_PROXY, ALL_PROXY) haven't overridden your intentions with a different scheme. Environment variables can override your settings.

Node.js

In Node.js, there is no direct SOCKS support in the standard http module. SOCKS agents are used to create connections through the proxy. The key parameter in such agents is an option that determines whether to resolve the name locally. In popular SOCKS agent libraries, there is a flag usually named something like lookup or a DNS-related option: when set to disable local lookup, the name is passed to the proxy. Make sure the agent is configured to pass the hostname, not to pre-resolve via dns.lookup.

Practical tip: in Node, be especially careful to check that dns.resolve or dns.lookup is not called somewhere in the code before establishing the connection. Such premature resolution nullifies the remote path.

Go

In Go, the standard library provides a package for working with proxies. Through golang.org/x/net/proxy, you can create a SOCKS5 dialer. By default, the behavior depends on whether you pass a name or an already resolved address to Dial. The key is to use the dialer so that it receives the domain name, not the result of net.LookupHost. If you called resolution yourself and passed an IP, that's local resolution with all its consequences. The correct approach: pass the host:port string with the name to the dialer and do not resolve in advance.

Chrome: startup flags

Chrome is controlled via command-line flags and policies. To set a proxy, use the proxy-server flag. Critically, when using SOCKS5, Chrome may resolve locally by default. There is a flag that controls whether resolution for proxied connections is performed on the proxy side — its name relates to host-resolver-rules and a setting that forces all hosts through the proxy. Also important is controlling built-in DoH: if Secure DNS is active in the browser and configured to its own provider, it can bypass your scheme. For a clean experiment, Secure DNS is usually disabled during diagnostics, and WebRTC policy is tightened.

Firefox: about:config settings

Firefox has historically been more convenient for controlling resolution. The key setting is network.proxy.socks_remote_dns. Set it to true, and Firefox will send hostnames to the SOCKS proxy for remote resolution instead of doing it locally. This is one of the most important settings in the entire material. Additionally, control:

• network.trr.mode — the DoH (TRR, Trusted Recursive Resolver) mode. A value that disables forced DoH is important if you want resolution to go only through the proxy.
• media.peerconnection.enabled — WebRTC management, to eliminate leaks via ICE.
• settings to disable IPv6 or prefetching if a parallel path is observed.

Selenium

Selenium controls a real browser, so resolution logic is inherited from Chrome or Firefox. For Chrome, pass the same flags via startup options (proxy-server arguments and those related to resolution). For Firefox, create a profile with the enabled network.proxy.socks_remote_dns setting through the profile preferences object. The secret to success: don't rely on driver defaults — explicitly set remote resolution in the profile or flags, then verify the actual path.

Playwright

Playwright provides a proxy parameter when launching a context or browser. You specify the server with a scheme (e.g., socks5://host:port) and credentials. There is a nuance: resolution behavior depends on the engine (Chromium, Firefox, WebKit) and how proxying is implemented. To guarantee remote resolution in the Chromium engine, combine the proxy setting with appropriate launch arguments; for the Firefox engine, use the profile setting socks_remote_dns. Always finish configuration with a leak test.

Summary table: client, how to enable remote resolution, how to verify

Here is the main practical table of the material:

• curl — enable: use --socks5-hostname or socks5h:// scheme in --proxy — verify: curl with verbose and observe that the name is passed; traffic dump to ensure no direct requests on port 53.
• Python requests — enable: socks5h:// scheme in proxies dictionary — verify: request to a service showing the resolver source; check environment variables.
• Python httpx — enable: proxy with socks5h:// scheme — verify: leak test, analyze which resolver is visible.
• Node.js — enable: SOCKS agent with hostname transfer, no prior dns.lookup — verify: absence of dns.resolve calls before connection; dump on port 53.
• Go — enable: SOCKS5 dialer, pass host:port with name, no prior net.LookupHost — verify: log what goes into the dialer; tcpdump.
• Chrome — enable: proxy-server with SOCKS5, host-resolver-rules on proxy, disable Secure DNS for diagnostics — verify: online leak test, compare region of IP and region of DNS.
• Firefox — enable: network.proxy.socks_remote_dns set to true, control network.trr.mode — verify: about:networking, online leak test.
• Selenium — enable: same Chrome flags or Firefox profile with socks_remote_dns — verify: run leak test inside the controlled browser.
• Playwright — enable: proxy parameter plus engine arguments for remote resolution — verify: navigate to a leak test in an automated session.

DoH and DoT: how they interact with proxies

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries. They are great for protecting the query content from an observer. But in the context of proxies, they create subtle effects that must be understood.

What DoH and DoT are in brief

DoT wraps DNS in TLS on a dedicated port. DoH hides the DNS query inside regular HTTPS traffic, making it indistinguishable from web browsing. Both protocols encrypt the query. But — and this is critical — encrypting the query is not the same as routing it through the proxy. These are different dimensions.

Key conflict: browser DoH bypassing the proxy

Here's the main insight of this section. When a browser enables its own DoH and is configured to resolve through its own provider, it establishes an HTTPS connection to the DoH endpoint. The question: does this connection go through your proxy? Often, no. The browser may open a DoH channel directly because resolution is perceived as a housekeeping operation separate from user navigation.

The result is paradoxical. On one hand, the DNS query is encrypted and your ISP doesn't see which domain you're querying. On the other hand, this query leaves from your real machine, from your network, bypassing the proxy. For geolocation, this is a failure: the target infrastructure sees a resolution from your region, not from the proxy's region. Your beautifully configured socks5h scheme is sidestepped because the browser never went through SOCKS for resolution — it took its own DoH path.

When browser DoH breaks your entire setup

Let's specify situations in which DoH bypasses the proxy:

• the browser is set to forced DoH via its own provider, and the proxy is only configured for regular traffic, not for housekeeping resolution;
• the operating system or application has DoH enabled at the OS level, and it is not wrapped in a tunnel;
• the DoH endpoint is cached and a connection to it was established before the proxy settings were applied.

Practical conclusion: for tasks where region consistency is important, when working through a proxy, browser and system DoH must either be disabled or explicitly directed through the same proxy. The ideal picture is that all resolution, encrypted or not, goes through the proxy server (remote resolution), not around it.

DoT and proxies

DoT works on a dedicated port and is easier to control via network policy, but it can also bypass the proxy if not explicitly wrapped. For our purposes, the principle is the same: ensure that resolution goes through the proxy, not over an independent channel.

The golden rule of DoH in the context of proxies

Remember: encryption of resolution and its routing through the proxy are independent properties. You can have encrypted resolution that completely reveals your region because it bypasses the proxy. For consistency, always aim for remote resolution on the proxy, and handle the encryption question separately and consciously.

How to verify: dig, nslookup, tcpdump, and online tests

Setting up is half the battle. An engineer must verify that resolution actually goes where intended. Let's go through diagnostic tools from simple to serious.

dig and nslookup through a proxy

dig and nslookup are classic tools for manual resolution. The nuance is that standard DNS uses UDP, while SOCKS proxies natively proxy TCP. So testing resolution through a proxy requires that the DNS query goes over TCP, and that the tool is directed through a SOCKS wrapper. In practice, to observe behavior, it's easier to wrap tools through programs that tunnel TCP traffic into SOCKS. The point of the test: verify that with remote resolution, your local machine does not send DNS queries itself, but only sees the result that came through the proxy channel.

nslookup is useful for quickly checking which resolver responds and which IP is returned. Compare the IP obtained locally with the IP that the connection actually goes to through the proxy. A discrepancy indicates that resolution is happening via different paths.

tcpdump on port 53 — the most honest test

This is my favorite method because it doesn't lie. Run a traffic capture on your machine with a filter on port 53 (and on port 443 for DoH suspicions). Then execute a proxied request. The logic is simple:

• if with remote resolution you see outgoing DNS packets on port 53 directly from your machine — you have a leak, resolution is local;
• if port 53 is silent and all traffic goes into the proxy tunnel — remote resolution is working correctly;
• if port 53 is silent but there are suspicious HTTPS connections to known DoH endpoints bypassing the proxy — you have a leak via DoH.

tcpdump shows the physical reality of the network, not the declarations of configs. That is why it is indispensable for final verification.

Online leak test: how to read the result correctly

There are web services that show which resolver performed your DNS query and from which region. The key to reading the result correctly is not to confuse two parameters:

• your visible IP — this is the IP from which the HTTP connection came, i.e., the proxy's IP;
• DNS resolver — this is the address and region of the entity that actually performed the resolution.

The correct picture with remote resolution: both the visible IP and the resolver point to the proxy's region. A warning sign: visible IP is the proxy's region, but the resolver is your real region. This is a classic local resolution leak. Another leak variant: the resolver belongs to a major DoH provider, but the connection to it went bypassing the proxy — then the resolver's region may be neutral, but the path itself still does not go through the proxy, which is visible via tcpdump.

Resolution verification checklist

Go through the points sequentially:

1. Clear the OS and browser DNS caches, restart the application.
2. Ensure the scheme is socks5h or remote resolution is enabled in the client.
3. Check proxy environment variables for conflicting schemes.
4. Run tcpdump with filters on ports 53 and 443.
5. Execute a proxied request to a test resource.
6. Ensure no direct DNS packets on port 53.
7. Check for no independent HTTPS connections to DoH endpoints.
8. Open an online leak test and compare the IP region with the resolver region.
9. Check the IPv6 path: no parallel AAAA queries and connections.
10. Document the reference configuration in team documentation.

Common mistakes almost everyone makes

Over years of working with proxies, a collection of rakes accumulates. Let's go through the most frequent ones so you don't step on them.

Mistake 1: confusing socks5 and socks5h

The absolute leader. Someone writes socks5:// and is sure resolution is remote. But it's local. One missing letter 'h' — and the entire region diverges. Always explicitly specify socks5h if you need remote resolution, and verify with a dump.

Mistake 2: setting up the proxy but forgetting about DoH

A classic for browsers. The proxy is set, but built-in Secure DNS / DoH is active and goes around. The user sees the correct IP and relaxes, while resolution leaks away. Always synchronize DoH policy with the proxy.

Mistake 3: ignoring IPv6

Proxy on IPv4, machine on dual stack. Happy Eyeballs does its job, and some connections go directly over IPv6. Either disable IPv6 for the application, or ensure the proxy fully serves IPv6.

Mistake 4: premature local resolution in code

A common problem in Node.js and Go. The developer, with good intentions, calls resolution in advance (for verification, logging) and passes the IP to the proxy. Remote resolution is dead. Don't resolve the name before passing it to the proxy dialer.

Mistake 5: trusting environment variables

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY — silent saboteurs. They override code settings or conflict with the scheme. Check the environment before launching and clean unnecessary ones.

Mistake 6: believing the config instead of verifying

You wrote the correct string and moved on. But a config is an intention, not a fact. Actual behavior is only verified by a traffic dump and a leak test. Never complete configuration without verification.

Mistake 7: forgotten DNS cache

You change configuration, but the result is the same — because old records and connections are cached. Always clear the cache and restart before a test.

Mistake 8: mixing proxy types in one pipeline

In one place HTTP proxy with CONNECT, in another place SOCKS with local resolution. Resolution behavior differs, and some requests leak. Unify the approach across the entire pipeline.

Mistake 9: not accounting for application cache

Some applications maintain their own DNS cache and connection pool that survive setting changes. Process restart is sometimes mandatory.

Mistake 10: ignoring WebRTC in automation

When automating browsers, WebRTC is often forgotten. A controlled browser can freely initiate ICE and expose paths bypassing the proxy. Always control WebRTC policy in automated sessions.

Tools and resources for working with resolution through proxies

Let's assemble the arsenal you should keep handy. Divided by purpose.

Diagnostic tools

• tcpdump — network traffic capture, the ultimate judge of resolution paths.
• Wireshark — graphical packet analysis, useful for complex cases involving DoH and IPv6.
• dig and nslookup — manual resolution, quick check of resolver responses.
• online DNS leak tests — show the resolver and its region, give a quick verdict.
• about:networking in Firefox — built-in diagnostics for browser connections and DNS.

Configuration tools and libraries

• curl — benchmark for testing socks5 and socks5-hostname behavior, ideal for debugging.
• SOCKS wrappers for TCP traffic — allow wrapping any application into SOCKS for resolution tests.
• SOCKS libraries for languages — SOCKS support packages in Python, SOCKS agents in Node.js, proxy package in Go.
• Browser automation tools — Selenium and Playwright with explicit proxy and resolution configuration.

Knowledge resources

• official curl documentation on proxy options — the best primary source for the semantics of socks5 vs socks5h;
• Python HTTP client documentation on working with proxies and schemes;
• Firefox about:config references for network and resolution parameters;
• documentation of your chosen proxy provider, in particular the MobileProxy.space service, where supported schemes and recommendations for remote resolution on mobile proxies are described.

Mini decision framework for choosing an approach

To avoid confusion, keep this simple decision logic:

1. Need HTTPS traffic and remote resolution? HTTP proxy with CONNECT or SOCKS5 with the socks5h scheme.
2. Working from a library or CLI? Explicitly specify socks5h or the remote resolution flag.
3. Working from a browser? Enable remote resolution, disable or direct DoH through the proxy, restrict WebRTC and IPv6.
4. Always finish configuration with a traffic dump and an online test.

Case studies and results: how it looks in practice

Theory without practice is dead. Let's go through generalized cases reflecting typical situations. Figures are approximate, but proportions and logic come from real engineering experience.

Case 1: region mismatch for a data analyst

A team collected data via a Python script with a proxy from the required region. Results came with localization from a different country in about forty percent of cases. Diagnostics showed the socks5:// scheme in the proxies dictionary — local resolution. Changing to socks5h:// completely eliminated the mismatch. tcpdump confirmed: direct requests on port 53 disappeared. Lesson: one letter solved a problem that had consumed two days of debugging.

Case 2: leak through browser DoH in automation

When automating Chromium via Playwright, the IP region was correct, but the target resource stubbornly determined a different region. An online test showed a resolver that did not match the proxy region. Wireshark revealed independent HTTPS connections to a DoH endpoint bypassing the proxy. Solution: disabling Secure DNS in the launch configuration and forcing remote resolution. After the fix, the resolver region matched the IP region, and false anti-fraud triggers dropped significantly.

Case 3: parallel IPv6 in a microservice

A Go service used SOCKS5, but periodically some requests went directly. The cause was dual stack and attempts over IPv6 bypassing the proxy. Restricting the client to only IPv4 and correctly passing the name in the dialer eliminated the leak. tcpdump stopped showing direct AAAA queries. Region stability increased to nearly a hundred percent.

Case 4: environment variable saboteurs

A script behaved differently on two machines with identical code. On one, remote resolution worked; on the other, it didn't. The breakthrough: on the problematic machine, the ALL_PROXY environment variable was set with a scheme without 'h', overriding the settings. After clearing the environment, behavior became consistent. Lesson: the environment is part of the configuration and must be controlled as strictly as the code.

General conclusion from cases

Notice the pattern. In all cases, the symptom was similar — incorrect region or security trigger — but the causes were different: scheme, DoH, IPv6, environment. That is why diagnostic checklists are more important than intuition. A systematic approach finds the root faster than guessing.

FAQ: frequently asked questions

What is the difference between socks5 and socks5h in simple terms?

socks5 resolves the domain name on your side and sends the proxy a ready IP. socks5h sends the proxy the name itself, and the proxy performs the resolution. For privacy and correct geolocation, you almost always need socks5h. The letter 'h' stands for hostname — the hostname is sent remotely.

If I use an HTTP proxy, do I need to worry about resolution?

For HTTPS via the CONNECT method, the name usually goes to the proxy, and it resolves itself — that's good. But some clients pre-resolve locally and pass an IP in CONNECT. So even with an HTTP proxy, verify the actual behavior with a traffic dump.

Why is the IP correct but the site sees a different region?

Almost certainly your DNS query is going around the proxy — through a local resolver or browser DoH. The target infrastructure uses DNS geolocation and CDN to determine your resolver's region, not the proxy's. The remedy is remote resolution and controlling DoH.

How is WebRTC related to resolution and leaks?

To establish connections, WebRTC gathers network candidates and can initiate requests that bypass the proxy. This can expose paths and addresses. When working through a proxy, especially in browser automation, WebRTC policy must be controlled or restricted.

Does DoH break my proxy setup?

It can. Encryption of resolution and its routing through the proxy are different things. Browser or system DoH can go directly, bypassing the proxy, revealing your region. For consistency, either disable such DoH or direct resolution through the proxy.

How can I quickly check if there's a leak?

Two steps. First, run tcpdump with a filter on port 53 and execute a proxied request: direct DNS packets mean a leak. Second, open an online test and compare the region of the visible IP with the region of the resolver. If they match — good; if they differ — leak.

What to do about IPv6 if the proxy is only on IPv4?

Either disable IPv6 for the proxied application, or ensure the proxy serves IPv6 and all traffic including AAAA resolution goes through it. Otherwise, the Happy Eyeballs algorithm will send some connections directly, bypassing the proxy.

Why does identical code behave differently on two machines?

A common cause is proxy environment variables (HTTP_PROXY, ALL_PROXY, etc.). They override code settings or specify a different scheme. Check and clear the environment to make behavior consistent.

Is specifying socks5h enough to guarantee no leaks?

For the application itself, it's a big step forward, but not a guarantee for the entire system. Channels like browser DoH, WebRTC, and IPv6 remain. Full protection is remote resolution plus control of all bypass channels plus mandatory dump verification.

Can I test resolution through a proxy from the command line?

Yes. curl with the --socks5-hostname option or socks5h scheme is the simplest way to test remote resolution. For utilities like dig, it's convenient to wrap TCP traffic in SOCKS, keeping in mind that classic DNS over UDP does not natively proxy through SOCKS.

Conclusion: summary and next steps

We've gone from symptom to deep understanding. Let's collect the main points into a compact conceptual framework that will stay with you.

Domain name resolution is a separate network transaction that can follow a different route than your main traffic. This independence is what causes most problems. Resolution can be performed by four entities: the operating system, the application library, the browser, and the proxy itself. Your goal is almost always to hand off resolution to the proxy server so that the name is determined from the correct point in the network.

The difference between socks5 and socks5h is fundamental. socks5 is local resolution, socks5h is remote. One letter changes everything: region, privacy, consistency. HTTP proxies with the CONNECT method naturally pass the name to the proxy, but even here you shouldn't blindly trust — verify.

Leaks boil down to one principle: there is a channel through which the name goes not through the proxy. System resolver, WebRTC, browser DoH, parallel IPv6, cache — these are the main suspects. And remember the key insight: encryption of resolution is not the same as routing it through the proxy. You can have encrypted DoH that completely reveals your region.

What to do right now? Here is your action plan:

1. Review your current configurations and replace socks5 with socks5h where remote resolution is needed.
2. Check browsers: enable remote resolution, sort out DoH and WebRTC policies.
3. Ensure IPv6 does not create a parallel path bypassing the proxy.
4. Clear proxy environment variables of conflicting values.
5. Conduct verification via tcpdump and online test using the checklist from this article.
6. Document the reference working configuration in your team's docs so no one reinvents the wheel.

The topic of resolution through proxies may seem narrow, but it's where the most expensive and frustrating configurations break. Now you have a map of the terrain: you understand who resolves, where the decision is made, how leaks occur, and how to close them. Keep this material bookmarked and return to the table and checklists whenever the proxy is connected but the site stubbornly sees the wrong region. Now you know where to look.