Proxy DNS leak test: check and fix it in your own client

Originally published on proxymint.

A proxy DNS leak test you run through your own client: where curl, requests, httpx, Playwright and Node resolve names, what a leak exposes, and each fix.

TL;DR

• A proxy carries the connection, and the DNS lookup can still happen locally. When the client resolves the target hostname itself and hands the proxy an IP, that lookup leaves through the local network.
• HTTP proxies resolve at the proxy by construction. The CONNECT request carries the hostname, so curl, requests, Chromium and Go make no local lookup for the target.
• SOCKS5 depends on the client. curl, Python requests and Node socks-proxy-agent resolve locally for socks5:// and at the proxy for socks5h://, while httpx, Chromium and Go send the hostname for both.
• A leak rarely throws an error. It leaks the target list to the local resolver, returns CDN answers for the wrong city and shows a resolver that does not match the exit.
• There are two halves to test. A local capture shows whether the client sends names; a far-side test shows where the provider resolves them, which only the provider can change.

Key takeaways

• Use an http:// proxy URL for HTTP and HTTPS jobs. It sends the hostname to the proxy in every standard client and removes the SOCKS DNS question.
• Write socks5h:// wherever a job must run over SOCKS5. In curl, requests and socks-proxy-agent the h is the difference between local and remote resolution.
• Run a port 53 capture once per client and after every library upgrade. Only the proxy's own hostname should appear, and a DoH client needs the Python hook or a NetLog instead.
• Test the far side before a geo-sensitive job scales. Compare the resolver's country with the exit's, for every provider, and ask the provider when they never match.

Read the full guide on proxymint, with the commands, tables and sources.