How to check a VPN: IP, DNS, IPv6, and routing | NetGuardVPN
GuideNetGuardVPN9 min read

How to check a VPN connection: IP, DNS, IPv6, and routing

A step-by-step connection check covering the public IP, DNS requests, IPv6, split tunneling, kill switch behavior, speed, and safe troubleshooting.

Updated:

A green status in a VPN client means the app believes the tunnel is established. To confirm the result, check which IP websites see, where DNS requests go, and whether the target app is excluded from routing. A methodical test does not require advanced tools.

Do not publish complete results: a public IP, server address, UUID, subscription URL, or client log can contain connection details. Redact secret fields before contacting support.

Record a baseline without the VPN

Before connecting, open a reputable IP-checking service and privately note:

  • the public IPv4 address;
  • whether a public IPv6 address is present;
  • country and approximate region;
  • the internet provider name;
  • the result of a DNS test.

Do not post this baseline in a public chat. It is only for comparison. Geolocation databases make mistakes, so the city does not have to be exact.

Step 1: check the public IP

  1. Connect the VPN and wait for its connected status.
  2. Close the old IP-test tab.
  3. Open a fresh private tab or reload without cache.
  4. Compare the IP and network owner with the baseline.

With a full tunnel, IPv4 should change to an exit-server address. The country should roughly match the selected location. The network-owner name can differ from the VPN brand because services often use data-center infrastructure.

If only the city shown by a website changes while the IP remains identical, you may have changed a region setting rather than the network route.

Why geolocation can show the wrong city

IP databases update at different times. A reassigned range may still be associated with an old country or city, and mobile or data-center IPs are often located only approximately.

Consider several signals together:

  • did the IP itself change?
  • does it belong to a different network provider?
  • does at least the country match?
  • does the target service work?
  • is an old cookie or manual region setting still active?

One incorrect city in a test is not proof of a leak.

Step 2: check DNS

DNS translates a website name into an IP address. With a correctly configured full tunnel, requests usually go through DNS selected by the VPN client or server. If they still go to the home provider, this can be a DNS leak.

Run an extended DNS test and inspect the owners of the discovered servers:

  • the home or mobile ISP appearing during a full-tunnel connection needs investigation;
  • a data center or DNS provider intentionally configured by the client can be normal;
  • multiple DNS servers do not automatically mean a leak;
  • the DNS country can differ from the exit-IP country because of distributed infrastructure.

Manual Private DNS, browser DNS over HTTPS, or another security app may intentionally override the client’s DNS path. That is not always a leak, but it differs from the expected route.

Step 3: check IPv6

A device can use IPv4 and IPv6 at the same time. If a VPN changes only IPv4 while a website still sees the original public IPv6, some connections may travel directly.

Compare IPv6 before and after connecting:

  • the original address disappears or changes to a VPN address — expected behavior;
  • the home provider’s public IPv6 remains unchanged — inspect client IPv6 support;
  • IPv6 is absent in both tests — there is no separate IPv6 exposure;
  • local addresses beginning with fe80:: are not a public leak.

Do not disable IPv6 in the operating system as the first response. Update the client, enable its intended protection, and read its documentation. Manual disabling can hide a symptom without fixing the configuration.

Step 4: inspect split tunneling

Split tunneling sends selected apps or sites outside the VPN. It is useful for local services, but often explains why a browser sees the new IP while another app sees the old one.

Check:

  • the excluded-app list;
  • Include versus Exclude mode;
  • domain rules;
  • local and private network ranges;
  • whether the target app was restarted after rules changed;
  • whether the browser uses a separate VPN extension.

For diagnosis, temporarily turn split tunneling off, reconnect, and repeat the test. Avoid changing routes during an important banking or work transaction.

Step 5: test the kill switch

A kill switch blocks traffic if the VPN disconnects unexpectedly. Not every client provides it, and it may conflict with split tunneling.

A low-risk test:

  1. Enable the kill switch if the client supports it.
  2. Open a harmless IP-checking page.
  3. Briefly switch between Wi‑Fi and mobile data or force the VPN to reconnect.
  4. While the tunnel is recovering, the page should not load over the direct route.
  5. After reconnection, confirm that the server IP is shown again.

Do not test during a download, video call, or financial operation. Behavior differs by platform, so read the description for your exact client.

Step 6: measure speed fairly

Compare the VPN and direct connection close together in time, on the same network, and using the same test server. Run three tests and look at the median rather than one unusually high or low result.

Assess:

  • latency;
  • download and upload throughput;
  • packet loss;
  • stability over several minutes;
  • the target app, not only a synthetic benchmark.

Distance, congested Wi‑Fi, and poor routing can matter more than the protocol name. See the VPN and proxy protocol comparison for a deeper explanation.

When results do not match expectations

Work through these steps in order:

  1. Restart the browser or app after connecting.
  2. Disable split tunneling and browser VPN extensions.
  3. Remove a conflicting Private DNS setting or another VPN.
  4. Update the client and import a fresh profile.
  5. Test another network and another location.
  6. Review the log for DNS, TLS, REALITY, or routing errors.
  7. Contact support with the time, platform, and app version.

Before sharing a log, remove UUIDs, keys, subscription links, private resource addresses, and other secrets.

A one-minute minimum check

  • The IP changes after connecting.
  • The country roughly matches the chosen location.
  • DNS does not belong to the original ISP without a known reason.
  • The original public IPv6 is no longer visible.
  • The target app is not excluded by split tunneling.
  • A connection drop does not send traffic directly when the kill switch is enabled.

When these checks pass, the connection is behaving as expected for normal use.

Sources