# Proxy DNS leaks: what each check actually proves

[All guides](https://proxylane.dev/blog) 

TROUBLESHOOTING · 5 MIN READ

Understand DNS, exit-IP, and WebRTC observations, what each can reveal about a proxy route, and why one passing check cannot certify anonymity.

**Founder, ProxyLane** Published September 26, 2026

On this page [Identify the path being checked](https://proxylane.dev/blog/proxy-dns-leaks#identify-the-path-being-checked)  [DNS resolution belongs to a specific client](https://proxylane.dev/blog/proxy-dns-leaks#dns-resolution-belongs-to-a-specific-client)  [WebRTC is a separate connection path](https://proxylane.dev/blog/proxy-dns-leaks#webrtc-is-a-separate-connection-path)  [What a bounded result means](https://proxylane.dev/blog/proxy-dns-leaks#what-a-bounded-result-means)

**Enterprise from $2/GB at 5 TB+**

Non-expiring traffic, location targeting and rotating or sticky sessions for your existing tools.

 [Sign up](https://proxylane.dev/register?interest=proxies)

A proxy leak check separates DNS resolution, HTTP exit IP, and browser WebRTC candidates. One passing IP check does not cover other paths or applications. Each observation applies to the tested client, hostname, and network configuration.

 

## Identify the path being checked

 

An HTTP exit-IP test observes the address a particular web endpoint sees for that HTTP request. It does not show which resolver handled the hostname, whether a browser used another network path, or what a different app will do.

 

A DNS leak test asks which resolver sees a lookup; its result depends on the hostname, cache, resolver configuration, and test design.

 

Web Real-Time Communication (WebRTC) uses Interactive Connectivity Establishment (ICE) candidates to find possible network paths between peers. A web application can inspect candidate addresses; MDN notes that candidate addresses can reveal network details and that relay-only policy restricts candidates, with a tradeoff in available paths ( [RTCIceCandidate address](https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate/address) ). This is separate from an HTTP proxy setting.

 

| Observation | What it can support | What it cannot establish alone |
| --- | --- | --- |
| HTTP request reports proxy exit address | That tested request reached the checker with that source address | DNS resolver path or every app’s route |
| DNS test reports a resolver | The resolver visible to that test under its conditions | Which app made every lookup or whether another hostname behaves the same |
| WebRTC page lists ICE candidates | Candidate addresses exposed to that page | A complete inventory of all network traffic or identity |

 

No checker certifies anonymity. Results depend on software, permissions, cached state, proxy type, target behavior, and network configuration. Report the URL, client version, proxy scheme, settings, time, and exact observed output with the conclusion.

 

## DNS resolution belongs to a specific client

 

For SOCKS5, the request can carry a destination as a domain name ( [RFC 1928 §5](https://www.rfc-editor.org/rfc/rfc1928.html#section-5) ). Whether the client resolves it locally or asks the proxy to resolve it depends on the client’s proxy mode.

 

curl documents `socks5://` for local name resolution and `socks5h://` for proxy-side hostname resolution ( [`CURLOPT_PROXY`](https://curl.se/libcurl/c/CURLOPT_PROXY.html) ). Other clients use different configuration names. The  [SOCKS5 vs SOCKS5h guide](https://proxylane.dev/blog/socks5-vs-socks5h)  explains this client-specific setting and its limits.

 

A controlled test can compare the client configured for its intended proxy mode with the client’s direct behavior, using a hostname under the operator’s control and a resolver log that identifies query time and name. Avoid treating a public DNS checker’s result as proof of the resolver used by every request.

 

Browser Secure DNS settings, operating-system resolvers, application-level DNS, caches, and exceptions can change which path is observed.

 

An HTTP exit check from the same client supplies a separate observation: the source address visible to that endpoint. Browser and command-line clients may follow different settings. Proxy environment variables and bypass rules can route selected hosts directly even when another request uses the proxy.

 

## WebRTC is a separate connection path

 

A WebRTC candidate test reports addresses and candidate types exposed by the evaluated browser profile. It does not inspect every network connection or establish whether every candidate was used. Browser policy and application settings influence which candidates are available.

 

A supported browser policy or application setting may restrict candidate gathering when direct peer-to-peer connectivity is unnecessary. The appropriate setting depends on the browser and the application's connectivity needs.

 

A relay-only policy can reduce direct candidate exposure, but it may prevent connections when a relay is unavailable. It also does not change DNS behavior or prove that ordinary HTTP requests use the proxy. A setting that restricts candidates can also break a required application feature; its network and functional effects need separate validation.

 

## What a bounded result means

 

A useful finding names the path, not a broad label such as “leak fixed.” For example: “On 2026-09-26, Firefox profile A sent the test HTTPS request through exit address X; the controlled DNS log showed resolver Y; the WebRTC page exposed candidate type Z.” Replace this illustrative sentence with observed values and keep sensitive addresses private when publishing a report.

 

A path that differs from the intended route may be owned by the proxy mode, system resolver, browser setting, direct-connect exception, or WebRTC policy. Changing one component does not establish that the others changed too. A passing result narrows the tested configuration; it does not certify anonymity, other devices, or future network state.

 

## Sources and further reading

- [https://www.rfc-editor.org/rfc/rfc1928.html#section-5](https://www.rfc-editor.org/rfc/rfc1928.html#section-5)

- [https://curl.se/libcurl/c/CURLOPT_PROXY.html](https://curl.se/libcurl/c/CURLOPT_PROXY.html)

- [https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate/address](https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate/address)

ProxyLane  From $2/GB at 5 TB+

 

## Your next connection Starts here

 

Non-expiring traffic, location targeting and rotating or sticky sessions for your existing tools.

 

[Create an account](https://proxylane.dev/register?interest=proxies)   [View plans](https://proxylane.dev/pricing)

## Keep reading

[Use cases · 3 min read

### Amazon Scraper API vs Proxy: Choose a Product Data Source

Distinguish authorized Amazon APIs, licensed product data and proxy-based page checks by record quality and access rights.

 Read guide](https://proxylane.dev/blog/amazon-scraper-api-vs-proxy)   [Integrations · 5 min read

### Apify Custom Proxy Setup: Use Your Own Residential Route

Connect a buyer-owned proxy to an Apify Actor, keep the session boundary clear, and validate records instead of counting requests.

 Read guide](https://proxylane.dev/blog/apify-custom-proxy)   [Proxy fundamentals · 6 min read

### Australia Residential Proxies: Verify the AU Exit and State-Level Result

Separate Australian egress from en-AU content, AUD pricing, GST display, postcode validation and the state delivery context.

 Read guide](https://proxylane.dev/blog/australia-residential-proxies)

Canonical source: https://proxylane.dev/blog/proxy-dns-leaks

Documentation index: https://proxylane.dev/llms.txt