A useful proxy leak test runs four separate checks from the exact application being evaluated: the HTTP or HTTPS exit IP, the DNS resolver path, WebRTC ICE candidates, and any IPv6 route. Start with a direct baseline, enable the proxy, repeat the same observations, and compare each result with the written routing design. A single green “anonymous” result is not enough because one request can use the proxy while another protocol, browser feature, or address family remains direct.
Scope: this guide is a diagnostic procedure for authorized browser and application traffic. It does not claim to prove anonymity, identity protection, or the absence of every side channel. Begin with the basic proxy working test, then use the Proxy Testing and Troubleshooting hub when a layer fails.
Define what “leak” means before testing
A leak is an observation that contradicts the intended routing or disclosure boundary. If the design says only one browser’s HTTP requests use a proxy while system DNS remains local, seeing the local resolver may be expected rather than a defect. If the design says all browser name resolution must follow the proxy path, the same observation is a failure.
Write a small contract before opening a checker: which application is in scope, which protocols should use the proxy, whether DNS should be local or remote, whether IPv6 is supported, what WebRTC behavior is acceptable, and which traffic should remain direct. The contract turns a vague privacy label into results that can be passed or failed.
Do not use an account-heavy destination for the first test. A neutral diagnostic request reduces cookies, redirects, scripts, and policy responses that can obscure the network path. After the route is understood, run one safe request against the intended destination.
Prepare a controlled browser or client
- Use a fresh test profile without unrelated proxy extensions, VPN software, or developer overrides.
- Record the operating system, browser or library version, connection type, and current time.
- Close applications that generate noise if you are observing DNS or network logs.
- Keep proxy credentials outside screenshots, page source, command history, and shared reports.
- Choose one neutral HTTPS IP observation endpoint and use the same endpoint throughout the comparison.
- Decide whether the test profile may use secure DNS, local DNS, or proxy-side DNS.
Run proxy and VPN tests independently. Combining them on the first attempt creates two route managers, two trust boundaries, and ambiguous results. The proxy vs VPN comparison explains why their scopes differ.
Step 1: capture a direct baseline
Disable the proxy for the test client and record the public address observed by an HTTPS request. Note whether it is IPv4 or IPv6. If both families are available, test each separately with a tool that can constrain the family or with endpoints that clearly report it. Record the country or network label only as supporting data because geolocation databases can disagree.
Next, record the DNS observation. This might be a resolver address reported by a diagnostic service, a query observed in an approved local capture, or a resolver log controlled by the organization. The visible resolver may be operated by an internet provider, a public DNS provider, a corporate network, or a browser secure-DNS service. It is not necessarily the same address as the client.
Finally, record WebRTC candidates from the test browser and whether native IPv6 connectivity exists. Keep this baseline private because it can contain network addresses and device information. The baseline is a comparison artifact, not content to publish.
Step 2: test the HTTP exit IP
Enable the proxy in the exact client and repeat the neutral HTTPS request. The observed address should match the assigned proxy exit or the provider’s documented pool behavior. Merely seeing an address different from the baseline is weaker evidence: another VPN, carrier gateway, or changing direct connection could also produce a change.
Confirm TLS validation remains enabled. A checker that works only after certificate validation is disabled has exposed a different and more serious problem. Record the status, family, sanitized endpoint label, and timing. Repeat after a new connection and, for a rotating service, after the documented rotation boundary.
If the direct address remains visible, verify that the application accepted the proxy setting, that the URL or protocol is supported, and that a bypass rule does not match the diagnostic hostname. Avoid cycling through endpoints before proving the client configuration.
Expected observation: the proxied HTTPS request completes with valid TLS and reports the assigned proxy exit, while a deliberately excluded control request behaves according to the documented scope.
Step 3: record the DNS observation
DNS testing asks where the destination name is resolved and which resolver path is visible. Some HTTP proxy clients send an absolute request containing a host name; some tunnel to a host; some libraries resolve before contacting the proxy. SOCKS clients can expose separate local-resolution and proxy-resolution modes. Browser secure DNS can bypass an operating-system resolver while still remaining inside the browser.
Repeat the same DNS observation used in the baseline. Compare the resolver, query transport, and returned A or AAAA records. A resolver in the same country as the proxy is not proof that the proxy performed the query. Conversely, a resolver address associated with a large public provider may use globally distributed infrastructure and reveal little about the request’s actual location.
If remote name resolution is required, select a client mode that explicitly supports it and confirm behavior with controlled evidence. The SOCKS5 setup guide explains why local and proxy-side name resolution need different client syntax.
Step 4: inspect WebRTC candidates as a separate channel
WebRTC uses Interactive Connectivity Establishment to find paths between peers. The architecture is defined in RFC 8445. A browser can gather host, server-reflexive, peer-reflexive, and relayed candidates depending on policy and available STUN or TURN services. These candidates describe possible media paths, not ordinary page HTTP requests.
Modern browsers have privacy controls that can conceal or obfuscate local addresses in some contexts. RFC 8828 describes using mDNS hostnames to protect local IP addresses in WebRTC. An obfuscated host candidate is therefore not the same as proof that every WebRTC packet uses the forward proxy.
The transport and privacy considerations in RFC 8835 help explain why WebRTC connectivity has its own requirements. Conventional HTTP proxy settings may not carry UDP media. If the workflow includes WebRTC, define whether it should be disabled, restricted, relayed through an approved TURN service, or allowed directly. Test that policy with a controlled call, not just a candidate list.
Record candidate types and redacted address categories rather than publishing full local addresses. If a direct public candidate appears where policy requires a relay-only path, treat it as a failure and inspect enterprise browser policies, TURN configuration, and application behavior.
Step 5: test the IPv6 path independently
An IPv4 proxy can work correctly for one request while a client reaches an IPv6-capable destination directly. The reverse is also possible. Check whether the device has native IPv6, whether the proxy service supplies an IPv6 exit, and whether the application honors the proxy for IPv6 destinations.
Force or select an IPv6 test where the client supports it. Compare the result with the direct IPv6 baseline. If the design does not support proxied IPv6, the safe outcome might be a controlled failure inside the application rather than a silent direct fallback. Do not assume disabling IPv6 across the operating system is the correct fix; first identify the component making the route decision.
Use the IPv4 vs IPv6 proxy guide to distinguish client-to-gateway family, exit family, DNS answers, and destination compatibility.
Step 6: prove the browser and application scope
Open a second application that should not use the proxy and repeat only the neutral exit check. If it also shows the proxy, the configuration may be system-wide rather than profile-specific. If the design intended system-wide routing, test a known exclusion instead.
Within a browser, extensions, service workers, secure DNS, WebRTC, downloads, and external protocol handlers can have different paths. Test the features the workflow actually uses. A standard page navigation does not prove that a native helper application or video call shares the route.
For scripts, confirm the specific HTTP client or SDK uses the configured transport. Environment variables are not universally honored. Dependency updates can change defaults, so keep a small automated acceptance check alongside the application.
Result matrix: record observations without a fake score
| Channel | Expected | Observed | Decision |
|---|---|---|---|
| HTTPS exit | Assigned proxy address | Address and family | Pass only on exact route match |
| DNS | Local or remote per design | Resolver and answer path | Pass when it matches policy |
| WebRTC candidates | Disabled, obfuscated, or relay-only per design | Redacted candidate types | Pass when no forbidden path appears |
| IPv6 | Proxy exit or controlled failure | Address, family, or error | Fail on silent direct fallback |
| Excluded control | Documented direct route | Observed exit | Pass when routing scope is correct |
| Intended destination | Approved response | Status and timing | Pass when safe smoke test works |
A checker should not combine these rows into an “anonymity percentage.” The importance of each row depends on the workflow. A command-line HTTP client may have no WebRTC surface. A browser-based call application may treat relay-only media as essential.
How to interpret common combinations
- Proxy HTTP exit, direct DNS: may be expected for a locally resolving client, or a failure if remote DNS was required.
- Proxy HTTP exit, direct IPv6: routing scope is incomplete for an IPv6-capable request and needs correction.
- Proxy HTTP exit, local WebRTC candidate: determine whether it is obfuscated and whether the application can establish a forbidden direct media path.
- Correct diagnostics, destination rejects request: the proxy route works; destination policy, authentication, or workflow is the next layer.
- Different exit after every reconnect: may be correct rotation, but it fails a requirement for a stable allowlisted address.
- No direct control path after disable: stale system settings, a VPN, or another gateway may still be active.
Avoid false positives and false confidence
Geolocation mismatches are not necessarily leaks. Databases can lag. Private local addresses are not public exits, though exposing them may still matter to a threat model. A public resolver address is not necessarily the client’s address. Browser changes can alter candidate display without changing every underlying media path.
Repeat tests after a browser restart, network transition, proxy reconnect, and normal session duration. Cache can hide DNS activity, and an existing connection can survive a configuration change. Close connections deliberately between scenarios when the client permits it.
Do not paste raw diagnostic reports into public tickets. Redact public baseline addresses, local addresses, proxy credentials, account identifiers, cookies, and full URLs containing private paths. Preserve enough structure, timestamps, and endpoint labels for support to reproduce the problem.
Remediate the failed layer only
| Failure | Corrective direction |
|---|---|
| HTTP request remains direct | Fix client proxy selection, protocol, bypass, or authentication |
| DNS contradicts design | Choose explicit local or remote resolution and test the exact client mode |
| Forbidden WebRTC path | Apply browser/application policy or approved relay configuration |
| IPv6 silently bypasses | Use a complete IPv6-capable route or enforce controlled application failure |
| Destination alone rejects | Stop changing network layers and review destination rules and request behavior |
| Unstable exit breaks allowlist | Use a documented stable assignment and retest |
Operational checklist for recurring tests
Automate only the non-sensitive observations the team needs: exit family and address or approved prefix, DNS mode, destination status, certificate validation, latency bands, and timestamp. Run at a reasonable interval. Alert on a route mismatch or sustained failure rather than one noisy timing sample. Store reports with limited access and retention.
If the acceptance contract requires a stable exclusive exit, confirm that behavior with a small trial before reviewing private proxy options. Selection comes after the client, DNS, WebRTC, IPv6, and destination paths are understood; a larger plan cannot correct an application that bypasses its proxy.
Responsible-use boundary: test only systems and traffic you are authorized to inspect, avoid collecting other users’ network data, protect diagnostic evidence, respect destination rules, and stop on explicit denial.