You check Android’s settings and find a custom Private DNS hostname. Then you open your browser settings and discover another option: Secure DNS.

Which one is handling your queries?

Android’s Private DNS setting, a VPN’s DNS configuration and a browser’s resolver settings can all affect DNS behaviour. A resolver name in a test result does not, by itself, establish whether the query travelled outside the VPN tunnel.

To investigate, separate three questions:

1. Which resolver handles the query?
2. Is the connection to that resolver encrypted?
3. Which route carries that connection?

Each question requires different evidence.

Private DNS and a VPN solve different problems

DNS translates names into records that applications use to locate services.

Android’s Private DNS setting concerns DNS resolution. Google’s Android Help documentation lists three options: Off, Automatic and Private DNS provider hostname.

Private DNS does not provide a general-purpose tunnel for the rest of your app traffic.

A VPN establishes a separate network connection and can configure both routes and DNS servers for traffic within its scope.

Android’s VpnService.Builder API reflects this distinction. It provides methods for adding routes and a separate addDnsServer() method for DNS configuration. Its documentation says that if no DNS server is specified, servers from the default network are used.

Consequently, “VPN connected” does not tell you everything about resolver selection.

It also does not mean the resolver must have the VPN provider’s name. A VPN service can use other resolver infrastructure.

Your browser introduces another variable

Some browsers perform DNS resolution through their own secure resolver configuration.

Google’s Chrome documentation distinguishes automatic Secure DNS from choosing a custom provider. It describes fallback to an unencrypted lookup when automatic mode encounters a resolution problem, while a custom-provider configuration does not use that same fallback.

Those are browser settings. They should not be treated as interchangeable with Android’s Private DNS setting.

Google also documents that Chrome can use its internal resolver instead of Android’s operating-system resolver.

That means a browser-based DNS test describes the lookups triggered by that browser under its current configuration. It does not automatically describe every other application on the phone.

A terminal lookup can differ too. The result depends on the tool, its resolver implementation and any explicitly selected server.

Resolver selection is different from tunnel routing

Consider this hypothetical result:

• A website sees your VPN exit IP.
• Its DNS test reports a public resolver.
• That resolver differs from the one you expected the VPN to use.

One possible explanation is that the browser selected its own resolver and reached it through the VPN.

Another is that the browser or resolver connection followed a route outside the VPN.

The resolver name alone cannot distinguish those possibilities.

For this investigation, define the concern precisely:

• Unexpected resolver: A different organisation handles the lookup than you intended.
• Tunnel bypass: DNS-related traffic travels outside the VPN route you intended.
• Unencrypted DNS transport: The resolver exchange lacks its own transport encryption.

These conditions can overlap, but they are not equivalent.

For example, DNS without its own encryption can still be carried inside an encrypted VPN tunnel. Conversely, an encrypted DNS connection can travel outside that tunnel.

Record the configuration before changing it

For the VPN for Android involved in your test, record the app version, selected location, DNS options and any app exclusions.

Also note:

• Phone model and Android version.
• Wi-Fi or mobile data.
• Android Private DNS mode.
• Configured provider hostname, if present.
• Browser name, version and Secure DNS mode.
• Whether the phone has a work profile or management policy.

Write down the intended result as well.

For example:

Browser queries should use the resolver selected in Android settings, and the resolver connection should travel through the VPN.

That gives you a configuration to investigate. “The DNS test should look right” does not.

Compare one variable at a time

Use the same network, browser and DNS test service throughout the initial comparison.

A useful sequence is:

This sequence separates the effect of connecting the VPN, changing Android’s resolver preference and changing the browser’s resolver preference.

Run a state only where you control the settings and have a valid configuration for it. Do not override workplace policies for the experiment.

The disconnected state is a baseline observation. Use ordinary test traffic rather than sensitive activity.

For each state, record:

• Whether the VPN reports connected.
• Whether fresh lookups succeed.
• The resolver identities reported by the test.
• The public IP observed by the website.
• Any browser or Android error.
• The time of the test.

“Browser Secure DNS off” means that browser feature is disabled. It does not establish that Android’s DNS exchange is unencrypted.

Use fresh lookups

An old results page is not a new measurement.

DNS caches can also make a configuration change appear to have no effect. Prefer a test that generates fresh, unique lookup names, and follow its instructions for starting another run.

Repeat each state before drawing a conclusion.

If a result changes only once, record it as an observation to reproduce. Avoid building an explanation around a single inconsistent run.

Understand what the test observes

Many browser DNS tests trigger queries for names beneath a domain the test operator controls. The operator then observes which resolver infrastructure contacts its authoritative DNS servers.

That is useful evidence about the resolution chain.

It is not a complete recording of the connection from your phone to the resolver.

Forwarding arrangements can also mean the infrastructure observed by the test differs from the server first contacted by your device. Reported locations are not reliable evidence of the packet route.

A resolver appearing in another country is therefore a reason to inspect the configuration, not a complete leak diagnosis.

For developers: inspect network properties carefully

Android exposes DNS-related information through LinkProperties.

Relevant methods include:

• getDnsServers()
• isPrivateDnsActive()
• getPrivateDnsServerName()

These describe the network represented by that LinkProperties object. They are not a universal summary of all DNS activity on the device.

The API documentation also distinguishes an active Private DNS configuration with a provider hostname from opportunistic mode, where Private DNS can be active without a configured hostname.

Record which network you inspected and when. A snapshot taken before a VPN transition may not represent the network used afterward.

Most importantly, network configuration does not prove that a browser with its own resolver used those settings. Combine configuration observations with the behaviour of the application you are testing.

When lookups fail after a setting change

A failed lookup can tell you that a combination is not working. It does not immediately identify why.

If resolution stops after entering a Private DNS hostname, check the hostname and whether that resolver is reachable under the current network and VPN configuration.

If only the browser fails after selecting a custom Secure DNS provider, investigate that browser configuration first.

Change one setting back and repeat the test. Preserve the error message before making further changes.

Avoid permanently disabling encrypted DNS simply because doing so restores browsing. First establish which component failed and what protection the alternative configuration provides.

When you need stronger routing evidence

If your main concern is tunnel bypass, a resolver list may not be enough.

You may need traffic observations on a network you control, VPN diagnostics, or a controlled test environment that can correlate resolver connections with tunnel activity.

Be careful with Android packet-capture apps: some use the VPN interface themselves. Starting one can replace or interfere with the VPN you intended to inspect, changing the experiment.

Encrypted DNS also limits what a capture reveals. A connection on port 443 is not automatically DNS over HTTPS, and the absence of readable DNS queries does not prove that no DNS traffic occurred.

Match the evidence to the claim you want to make.

End with a specific finding

A useful conclusion might be:

The browser test reports a different resolver after I enable its custom Secure DNS provider. The website still sees the VPN exit IP. I have confirmed a resolver change, but I have not established the route to that resolver.

Or:

Fresh lookups fail only when the configured Private DNS hostname and the VPN are both active. Returning Private DNS to Automatic restores resolution in repeated tests.

Both findings identify the next investigation.

Start with the application, record the settings, compare fresh results and separate resolver choice from routing. That is how an unexpected DNS result becomes a problem you can actually diagnose.

Did the VPN fail? Did the request escape the tunnel? Or did the phone simply need time to establish a working connection over a different network?

Switching from Wi-Fi to mobile data changes the network carrying your VPN connection. Depending on the VPN implementation and configuration, the tunnel may adapt or reconnect. A pause alone does not establish that traffic bypassed it.

To understand the transition, separate three things: the underlying network, the VPN tunnel and the application request.

Your phone changes networks beneath the tunnel

A VPN connection depends on an underlying internet connection.

At home, the phone reaches the VPN server through your Wi-Fi network and its internet provider. After the switch, it reaches the server through your mobile carrier.

The network path changes. The phone’s addressing, gateway and available connectivity can change with it.

The VPN must accommodate that transition. Some implementations support mechanisms that help preserve a session as the network changes. Others establish a new connection.

Even when the VPN recovers quickly, an application may still notice the interruption. A request might time out, a live connection might close, or a download might need to resume.

These outcomes describe availability. Establishing whether traffic travelled outside the intended tunnel requires additional evidence.

Three states worth distinguishing

A useful investigation records each layer separately.

1. Underlying network state

Can the phone reach the internet through Wi-Fi or cellular?

A Wi-Fi connection can remain associated with an access point even when that network has no working internet connection. Cellular reception also does not guarantee that a particular request will succeed.

2. VPN state

Is the VPN connecting, connected, reconnecting or disconnected?

Apple’s Network Extension framework exposes connection states through NEVPNStatus, including connecting, connected, reasserting and disconnected. Apple defines reasserting as the VPN being in the process of reconnecting.

The wording displayed by a particular VPN app may differ. Record the actual message rather than assuming every app presents those framework states directly.

3. Application state

Did the specific operation complete?

A page loading successfully tells you that its request found a working path. It does not, by itself, identify that path.

Likewise, an application error does not identify which layer failed.

Reconnection and traffic blocking answer different questions

Automatic reconnection concerns restoring the VPN connection.

Traffic blocking concerns what is allowed to happen while that connection is unavailable.

A VPN might reconnect automatically while a separate configuration controls whether affected traffic can continue outside the tunnel. A feature labelled “Kill Switch” needs to be evaluated according to its documented behaviour and platform support.

When reviewing an iPhone VPN, examine both questions:

• How does the connection recover after a network change?
• What happens to traffic during the interruption?

Apple also documents routing exceptions for some essential system traffic. Avoid interpreting “VPN connected” as proof that every packet generated by the device follows an identical route.

Run a controlled handoff test

A useful test compares stable connections with the transition between them.

Use ordinary, non-sensitive requests. Keep the VPN location and other settings unchanged during the initial comparison.

Step 1: Record the configuration

Note:

• iPhone model and iOS version.
• VPN app version.
• Selected VPN location.
• Relevant reconnection and traffic-blocking settings.
• Whether iCloud Private Relay or another proxy is active.
• Whether the device has work or school management profiles.

Private Relay and other intermediaries can affect how browser results appear. Record them before changing anything.

Step 2: Establish stable baselines

First, check behaviour while connected to Wi-Fi and the VPN.

Then check behaviour while connected to cellular and the VPN.

For each state, record whether a fresh request succeeds, the VPN’s reported status and the public IP observed by the same test endpoint.

If requests already fail on a stable cellular connection, investigate that before treating the handoff as the cause.

Step 3: Trigger one controlled switch

Start on Wi-Fi with the VPN connected.

Turn Wi-Fi off in Settings, allow cellular connectivity to take over, and attempt fresh requests during the transition.

Record the sequence rather than relying on a general impression:

A screen recording can help align visible events. Review it for personal information before sharing it.

This tests a deliberate switch. Walking out of Wi-Fi range introduces different conditions, including a period of weak or unreliable connectivity. Test that separately if it matches the problem you experience.

Step 4: Test the return journey

Reconnect to Wi-Fi and repeat the observations.

Wi-Fi-to-cellular success does not establish that the reverse transition behaves identically.

If the destination Wi-Fi requires a sign-in page, complete the network’s access requirements before treating a failed VPN connection as a tunnel problem.

Step 5: Repeat before changing settings

One successful transition provides limited evidence.

Repeat the same sequence several times. Then change one relevant setting and compare again.

If you change the VPN location, browser configuration and network simultaneously, identifying the cause becomes much harder.

Interpret results without overreaching

Requests pause, then resume through the VPN exit

This is consistent with a temporary interruption followed by recovery.

It does not prove that no traffic bypassed the tunnel between observations. Manual checks sample moments; they do not continuously observe every connection.

The VPN exit IP changes

A new exit address can accompany a reconnection.

The address changing does not automatically mean the phone used its carrier’s public IP. Establish what the new address represents before drawing that conclusion.

A fresh request appears to use a direct-network address

This deserves investigation if the request was intended to remain inside the VPN.

Check whether the endpoint returned a current result, whether another relay affected the comparison, and whether the traffic falls within the VPN’s configured scope.

The finding becomes stronger when the request timestamp, server-observed address and VPN state line up.

Requests stop until the VPN returns

That may be consistent with traffic blocking during recovery.

It can also happen because the underlying network is temporarily unavailable. A blocked request alone does not distinguish those causes.

For developers: observe requests at an endpoint you control

A controlled HTTPS endpoint can provide clearer evidence than repeatedly refreshing an old results page.

Have a test client send a fresh request with a unique identifier. Record:

• Request identifier.
• Server receipt time.
• Source address observed at your trusted ingress.
• Response status.
• Client completion time or error.

Keep the response small and disable caching for the test.

If your server sits behind a reverse proxy or CDN, distinguish the proxy’s address from the client address supplied by a trusted forwarding configuration. Do not trust arbitrary forwarding headers sent by the client.

Correlate those records with the handoff timeline.

This establishes what reached that endpoint. Requests that never arrive remain unobserved, and successful samples cannot rule out activity between them. Browser-based probes also describe browser traffic; they do not establish the route taken by every app.

If the problem happens only during switching

Use the stable baselines to narrow the next step.

• Both networks work separately, but handoffs fail: focus on transition handling and reconnection.
• Cellular fails even before a handoff: check cellular access, signal conditions and VPN connectivity on that network.
• Only one app fails after recovery: investigate that app’s connection lifecycle and retry behaviour.
• Wi-Fi fails after joining a new hotspot: check whether the network requires sign-in or has connectivity restrictions.

For application developers, a network transition is also a reason to review retry logic. Retrying a read request differs from repeating an operation that creates a payment, order or other record. Use appropriate idempotency controls before automatically resubmitting writes.

Report a sequence someone can reproduce

“VPN breaks when I leave home” is difficult to diagnose.

A more useful report identifies the starting network, the change, the VPN status, the affected request and what restored connectivity.

For example:

On Wi-Fi, requests succeed through the expected VPN exit. After switching to cellular, the app reports reconnecting and fresh requests time out. Requests resume after the VPN returns to connected. The issue occurred on three of five switches.

That report gives the next investigation a clear starting point.

The goal is to establish what happened during the transition: whether connectivity disappeared, the VPN reconnected, an application failed to recover, or a request used an unintended route.

That confirms something useful about the connection you tested. But if the result shows only an IPv4 address, what have you established about IPv6?

A changed IPv4 address does not establish that IPv6 traffic follows the same path. On a network that supports both address families, test them separately and compare the results with the VPN disconnected and connected.

An IPv6 result also needs interpretation. A visible IPv6 address is not automatically a leak, and an unavailable IPv6 connection is not automatically a failure.

The question is whether traffic follows the policy you intended.

IPv4 and IPv6 can behave differently

IPv4 and IPv6 are separate address families. A device can have both available at the same time, commonly called a dual-stack connection.

A VPN configuration might:

• Carry both through its tunnel.
• Carry IPv4 and block IPv6.
• Apply different rules to each address family.
• Exclude particular applications or destinations.

The configuration matters more than the presence of an IPv6 address alone.

RFC 7359 documents VPN traffic leakage scenarios involving dual-stack hosts. Its accompanying IESG note also makes a broader point: traffic escaping an intended VPN policy is not exclusively an IPv6 problem.

Treat that document as an explanation of the underlying risk, rather than evidence about a current VPN provider.

Why one successful IP check is incomplete

An ordinary website request does not necessarily exercise both address families.

When a destination supports IPv4 and IPv6, applications can choose between available addresses. Connection strategies such as Happy Eyeballs try alternatives to reduce delays when one path is slow or unavailable.

A page loading successfully therefore does not tell you which family was used.

Start with three separate observations:

1. Does an IPv4 connection succeed?
2. Does an IPv6 connection succeed?
3. Which source address does the destination observe for each?

A local address shown in network settings and a public source address observed by a server are different measurements. Record which one your tool reports.

Establish a baseline before connecting

Use the same device, network and application throughout the initial comparison.

Record:

• Operating system and VPN application versions.
• Whether the VPN is device-wide or browser-only.
• Any split-tunnelling exclusions.
• Whether an explicit proxy is configured.
• Public IPv4 and IPv6 observations with the VPN disconnected.
• Whether IPv6 works at all before the VPN connects.

That last point is important.

If IPv6 already fails without the VPN, a failed IPv6 check after connecting cannot demonstrate that the VPN blocked it. Your baseline never established a working IPv6 path.

For baseline checks, keep unrelated applications paused if you do not want them communicating outside the VPN.

Test each address family explicitly

A browser test with separate IPv4 and IPv6 checks is a useful starting point.

For a command-line comparison, curl can request each address family separately.

Use a trusted HTTPS endpoint that supports both IPv4 and IPv6 and reports the source address it observes. This can be an endpoint you operate or an approved diagnostic service.

The following example uses a placeholder rather than assuming a particular service:

vpn_test_url='REPLACE_WITH_YOUR_DUAL_STACK_IP_ECHO_URL'

curl -4 --connect-timeout 5 --max-time 15 \
  "$vpn_test_url"

curl -6 --connect-timeout 5 --max-time 15 \
  "$vpn_test_url"

Replace the placeholder with the complete endpoint URL.

Run both commands before connecting the VPN, then repeat after the connection has settled. Save the response and any error message for each run.

These examples use a POSIX-style shell. In Windows PowerShell, use curl.exe when you intend to invoke the curl executable.

Keep proxy behaviour in view

If curl uses an explicit proxy, the test may measure a proxy connection rather than the direct path you intended to investigate.

Record proxy settings before interpreting the result. Do not change managed proxy policies just to make a test pass.

Also remember that terminal curl and a browser may have different VPN exclusions, proxy settings or networking behaviour. A successful curl check does not automatically validate the browser.

Compare the results without overclaiming

Use the baseline to interpret what changes:

“IPv6 unavailable” can be consistent with a VPN that intentionally blocks IPv6.

However, a timeout alone does not identify the cause. It can also reflect a destination problem, filtering or a connectivity failure.

Likewise, an unexpected address deserves investigation before you label it a leak. Confirm which application made the request and whether that application was meant to use the VPN.

Do not rely only on exact address matches

IPv6 addresses can change over time.

RFC 8981 describes temporary addresses intended to reduce the tracking implications of stable interface identifiers. As a result, comparing only the complete address string can miss a continuing relationship with the same access network.

If an address changes, investigate the allocated network prefix and provider information as well.

These are clues, not a substitute for route evidence. Geolocation databases can also be inaccurate, and matching countries do not establish matching network paths.

A VPN exit and your ordinary internet connection might be in the same country.

Separate IPv6 connectivity from DNS and WebRTC

A request sent over IPv6, a DNS lookup and a WebRTC address observation answer different questions.

Keep IP, DNS and WebRTC checks distinct rather than treating every unexpected result as the same type of leak.

For example:

• An IPv6 HTTPS request shows how that application reached a destination.
• A DNS test investigates resolution behaviour.
• A WebRTC test examines addresses or candidates exposed through browser functionality.

An address appearing in a browser diagnostic does not necessarily establish that a normal web request used it.

State what the test actually observed before drawing a wider conclusion.

When an unexpected result needs route evidence

If IPv6 appears to bypass the policy you intended, inspect the configuration before changing it.

Check whether:

• The tested application is excluded through split tunnelling.
• The VPN documents tunnelling or blocking IPv6.
• Another VPN, proxy or network extension affects the application.
• The result changes after a network transition or VPN reconnect.

For a deeper investigation, routing information and a packet capture on a device you control can help establish the path to the test destination.

Interpret the interfaces carefully. A physical network interface also carries the VPN’s encrypted outer connection. Seeing packets there is expected.

The distinction is whether the application’s connection reaches its destination directly or is carried inside the tunnel. Do not disable protections or force traffic onto another interface and then treat that altered configuration as evidence about the original one.

Retest the conditions you actually use

A check performed on one Wi-Fi network describes that test environment.

Repeat the relevant checks after changes such as:

• Moving between Wi-Fi and mobile data.
• Reconnecting the VPN.
• Changing split-tunnelling settings.
• Updating the VPN application.

Separate observations made after a connection settles from observations made during a transition. A passing steady-state check does not establish what happened while the VPN was reconnecting.

Avoid permanently disabling IPv6 simply because a website reports an unfamiliar address. First determine whether the behaviour conflicts with the VPN’s intended policy and supported configuration.

Write a precise conclusion

Instead of:

My IPv4 address changed, so everything is protected.

Write:

The IPv4 test used the expected VPN address. IPv6 was unavailable after connecting, and the provider documents that behaviour as intentional.

Or:

Both address families worked, but the IPv6 result appeared associated with my access network. I still need to verify the application’s exclusions and route.

Those statements distinguish observation, documented behaviour and unresolved questions.

A useful VPN check covers the paths your device can use. Test IPv4 and IPv6 separately, keep the conditions consistent, and let the evidence determine the conclusion.

You enable DNS over HTTPS in your browser, repeat the test and get another result.

Is your VPN leaking DNS requests, or is your browser simply using a different resolver?

DNS over HTTPS does not automatically cause a VPN leak. It changes how DNS queries reach a resolver. Whether that connection travels through the VPN depends on routing, exclusions and the software involved.

To investigate the result, separate three questions:

1. Who resolves the query?
2. How is the query encrypted?
3. Which network path carries it?

A resolver name alone cannot answer all three.

Resolver, encryption and route are different things

DNS translates domain names into information your device can use to establish a connection.

Ordinary applications often ask the operating system to perform that lookup. A browser with its own DNS over HTTPS configuration can instead send queries to a selected resolver over HTTPS.

RFC 8484 defines this exchange. HTTPS protects the communication between the client and the DoH service; it does not prevent that resolver from processing the query.

The network route is a separate layer.

A browser’s connection to a DoH resolver might travel through the VPN tunnel. It might take another route if the browser is excluded from the VPN, split tunnelling applies or the configuration behaves differently than expected.

This distinction matters:

Using a resolver other than the VPN provider’s resolver is not, by itself, proof that traffic bypassed the VPN tunnel.

It may still be a configuration you did not intend. But identifying the resolver and establishing the route require different evidence.

What a browser DNS test tells you

Many DNS test websites trigger lookups for unique names under a domain they control. Their infrastructure can then observe which resolver contacts the authoritative DNS server.

That helps identify the resolver—or forwarding infrastructure—involved in those lookups.

It does not automatically reveal the entire journey from your browser to that resolver.

Consider a hypothetical result:

• The website sees a VPN exit address.
• The DNS test reports your browser’s chosen public resolver.
• The resolver’s reported location differs from the VPN location.

That result deserves investigation, but it does not independently establish a tunnel bypass. Forwarding, distributed resolver infrastructure and imperfect location databases can complicate interpretation.

Keep IP, DNS and WebRTC checks separate. Each examines a different part of connection behaviour.

Browser DNS settings can differ from system settings

A browser may use its own resolver configuration even when other applications use the operating system’s DNS service.

That can explain why a browser test and a terminal lookup produce different results.

For example, a command such as nslookup or dig does not necessarily reproduce the browser’s resolution path. Its behaviour depends on the tool, operating system and configuration. You cannot assume a successful terminal lookup verifies browser DoH.

Firefox also has different protection levels rather than one universal DoH behaviour.

Mozilla’s documentation describes Default Protection as responsive to network conditions, including VPN detection and enterprise policies. Other levels can use a selected provider more consistently, with different failure behaviour.

Record the actual mode and status shown in your browser. “Secure DNS enabled” is too vague for a useful test record.

Fallback changes the question

What happens when the configured DoH service cannot answer?

Depending on the browser’s mode and policies, it may try another resolver, use system DNS or report an error.

Mozilla’s Firefox administrator documentation explicitly distinguishes configurations that allow system-resolver fallback from those that require DoH.

But fallback alone does not prove a leak.

If the system resolver’s traffic remains inside the VPN tunnel, falling back to it does not automatically expose the lookup outside that tunnel. If the fallback path bypasses the tunnel, the privacy outcome differs.

The practical question is:

When resolution changes, where does the replacement traffic go?

Avoid assuming that a strict DoH setting fixes every routing problem. It may change DNS failure behaviour without correcting the underlying VPN configuration.

Run a controlled comparison

Use this as an investigation method, rather than a claim that any particular browser or VPN has been tested.

1. Record the starting configuration

Note:

• Operating system and browser versions.
• VPN application version.
• Whether you use a device-wide VPN, browser proxy or extension.
• Whether the browser is excluded through split tunnelling.
• Browser DNS mode and selected resolver.
• Any custom system DNS configuration.

Keep the network connection unchanged during the initial comparison.

2. Compare four states

Where you control the settings, compare these combinations:

“Off” here means the browser’s DoH setting is off. The operating system may still use encrypted DNS.

Treat disconnected tests as baseline observations, not protected browsing sessions.

3. Change one setting at a time

Use the same test service and record each result before changing anything else.

A fresh test session that generates new lookup names helps reduce confusion from cached results. Follow the service’s instructions and avoid comparing an old results page with a new configuration.

If several settings change together, you lose the ability to identify which change affected the outcome.

4. Write observations before conclusions

Useful observations include:

• “The resolver changed after enabling browser DoH.”
• “The public IP remained the VPN address.”
• “The browser reported that secure DNS was inactive.”
• “Resolution failed in one configuration.”

Avoid immediately translating these into “VPN broken” or “no leak.”

The comparison narrows the investigation. It does not fully establish packet routing.

When you need network-level evidence

If the browser results remain ambiguous, inspect traffic on a device and network you control.

A packet capture can help establish whether traffic to a resolver endpoint appears directly on a physical interface or is carried inside the VPN’s outer connection.

Interpret captures carefully:

• A physical interface carries encrypted VPN packets too; seeing traffic there is expected.
• Plain DNS on port 53 is only one case. Encrypted DNS uses other transports.
• A port 443 connection is not automatically DoH.
• The absence of readable DNS does not establish the absence of DNS-related traffic.
• Timing, interface selection, endpoint identification and routing information all matter.

For encrypted connections, metadata and routing observations may help establish the path without exposing query contents.

Captures can contain sensitive information. Keep them local and avoid sharing raw recordings unnecessarily.

Use the result to identify the next question

An unexpected resolver can mean several things: an intentional browser setting, a forwarding arrangement, a fallback, or an unintended route.

The useful outcome is a specific finding.

Instead of:

My DNS test shows another provider, so the VPN must be leaking.

Aim for:

My browser uses a different resolver when DoH is enabled. I have confirmed the resolver change, but I still need to verify whether its connection travels through the VPN.

That statement tells you what you observed and what remains unresolved.

Before changing more settings, write down the resolver, transport and route you intended to use. Then investigate where the observed behaviour differs.