Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


When a VPN says connected but your IP address does not change, first prove that the same controlled test is observing the same address family before and after connection. A saved result, an IPv4/IPv6 mismatch, browser-only proxy, split-tunnel rule, or stale connection can all make a healthy status and an unchanged-looking address coexist.
The complete VPN guide explains what a tunnel can and cannot change. This article focuses only on a public-IP test that still returns the original internet-facing address; DNS resolvers, GPS position, account country, and website profile location are separate signals.
Key Takeaways
- Use one trusted endpoint in a fresh session and record both public IPv4 and IPv6 before and after connecting.
- Confirm whether the product is a browser extension, per-app tunnel, split tunnel, or device-wide VPN.
- A connected badge proves client state, not that the tested flow uses the intended route.
- Close persistent connections and retest before changing protocols or servers.
- Never publish screenshots containing full addresses, account details, tokens, or private routes.
A public IP is the internet-facing source address a remote service observes for a connection. It is not the private Wi-Fi address shown in device settings, a DNS resolver address, a router management address, a GPS coordinate, or a country saved in an account profile. Cloudflare's overview distinguishes public addresses used on the internet from private addresses used inside local networks.[2]
Choose one reputable endpoint reporting IPv4 and IPv6 separately. For extension tests, first confirm the extension can run in the test window: private mode may disable it. If private access is not allowed, use its enabled normal browser profile and restart the browser normally to establish fresh sessions. Keep that window mode fixed throughout the comparison. Before connecting, record the time, network type, and available public IPv4/IPv6 as “baseline v4” and “baseline v6”; do not publish the values.
Connect the VPN, wait until the client settles, then start a fresh session in the chosen window mode at the exact same endpoint. Record “VPN v4” and “VPN v6.” Comparing one site's IPv4 before connection with another site's IPv6 afterward is not a valid unchanged-IP test.
Use a simple matrix rather than a single screenshot:
| Family | Before VPN | After VPN | Initial interpretation |
|---|---|---|---|
| IPv4 | Baseline A | Different B | Tested IPv4 likely uses the VPN exit |
| IPv6 | Baseline C | Same C | IPv6 may be outside the intended tunnel scope |
| IPv4 | Baseline A | Same A | Tested IPv4 may be bypassed or using stale state |
| Either | No result | New result | Availability changed; there is no like-for-like baseline |
A commercial VPN normally carries selected traffic to a VPN gateway, which then forwards it toward the destination. The destination sees the gateway-side source for tunneled traffic rather than the user's direct path.[1] An unchanged like-for-like result therefore justifies route investigation, but it does not by itself reveal why the route was bypassed.
Run the full VPN connection test if you need to assess more than the public address. Keep this article's evidence narrow so DNS, reachability, and location symptoms do not overwrite the IP result.
Identify the owner of the tested traffic. A browser extension may configure a proxy for browser requests without creating a device-wide tunnel. A per-app VPN can protect only managed or selected applications. Split tunneling can intentionally send listed apps or destinations outside the VPN. A full-tunnel profile usually installs broader routes, but policy can still define exceptions.
Test inside the exact application covered by the product. If an extension is enabled in one browser profile, testing another browser, a native IP checker, or a command-line tool may correctly show the direct address. Conversely, testing inside that browser says nothing about desktop applications.
Review split-tunnel rules before treating bypass as a defect. Record whether the test browser is included or excluded, whether a destination exception exists, and whether organizational policy controls the choice. Do not disable managed policy merely to force a different number on the page.
Modern clients keep connections alive. A page refresh may reuse a transport that began before the VPN connected, while a service worker, app cache, or test page may display a previous result. That creates a misleading comparison even if new connections use the intended path.
Close the test tab, wait briefly, and reopen the endpoint in a fresh session using the chosen window mode after the VPN is fully connected. If the application offers no private mode, quit it normally and relaunch it. Do not clear the entire device, remove profiles, or reset every network merely to replace one persistent session.
Run the test twice after connection. If the first result is old and the second is the VPN exit, note the transition instead of declaring intermittent routing. If both results remain the baseline address, continue to scope and route checks.
IPv4 and IPv6 are separate protocol families with separate addresses and routing decisions. RFC 8200 defines IPv6 as its own network-layer protocol and address architecture.[4] A test page may prefer IPv6 on one run and IPv4 on another, or show only the family that successfully connected.
Record both families explicitly. If IPv4 changes but IPv6 remains identical to the direct baseline, the evidence points to incomplete IPv6 coverage or an intentional IPv6 policy. If IPv6 is unavailable both before and after, there is no IPv6 bypass result to interpret.
Do not “fix” the symptom by permanently disabling IPv6 unless the VPN provider or administrator documents that action for the specific deployment. Disabling a protocol can hide a route gap, break local or enterprise services, and change the test rather than repair the tunnel.
Confirm the client finished connecting to the server you actually selected. A recommended-location mode may choose a nearby gateway, while a failed preferred server can cause an approved fallback. The public address may also geolocate imperfectly because IP-location databases are estimates and update at different times.
The decisive comparison is address and route, not the city label alone. If the numeric public address changes but a website shows the old city, use the guide to changing an IP address and treat geolocation as a separate database question. If the address remains exactly the baseline, record the server and protocol, reconnect once, and repeat the controlled test.
A selected server does not guarantee that every location database will show the selected city. If you want to test AethoVPN with this controlled comparison, compare one manually selected server with one automatic selection while keeping the device, network, browser, and endpoint fixed. Record the numeric IPv4 and IPv6 results so support can distinguish server selection from local routing.
Look for another active VPN, security client, browser proxy, enterprise traffic filter, or virtual network adapter that can own the tested route. Two controls may both show active while only one receives a particular flow. Disconnecting an unauthorized enterprise control can break access and violate policy, so document it and ask the administrator which component should own the route.
Check whether the VPN status survives a normal disconnect and reconnect. If it displays connected instantly but installs no working route, capture the sanitized status and time. A normal app restart or device restart is reasonable; deleting profiles, editing route tables, or reinstalling network drivers should wait for product or IT instructions.
Microsoft documents that VPN routing can be controlled through routes, traffic filters, and split-tunnel configuration.[3] The visible connection state alone cannot establish which route a particular destination matched.
Send the device and OS version, VPN client or extension version, product type, selected server, protocol, network type, test endpoint, timestamps, and the labeled before/after IPv4 and IPv6 outcomes. State whether the test app is included in split tunneling and whether a fresh private session changed the result.
Mask addresses in screenshots and logs unless support provides a secure, authorized channel and genuinely requires the full value. Remove account email, subscription identifiers, internal subnets, gateway names, tokens, cookies, and unrelated browsing history.
Escalate when the same endpoint repeatedly returns the same baseline public address for a flow that policy says must use the VPN, while a clean reconnect and fresh session do not change it. That is stronger evidence than a location label or a single cached page.
An unchanged public IP is meaningful only in a like-for-like test. Record IPv4 and IPv6 separately, use the same endpoint after a fresh connection, confirm which product owns the tested app, and check split scope and persistent sessions. Treat DNS, GPS, account region, and geolocation labels as different signals so they do not obscure a real route problem.
The client status may be healthy while the tested browser or address family is outside the tunnel, or the page may reuse an old connection. Repeat a same-endpoint IPv4/IPv6 test in a fresh session.
Usually no. A private Wi-Fi address identifies the device on the local network. The public address is the internet-facing source observed by a remote service.
Yes. They use separate addresses and routes. Record both; an unchanged direct IPv6 result may indicate that IPv6 is outside the intended VPN scope.
No. IP geolocation is an estimate, and databases can group different addresses in the same city or retain old labels. Compare the numeric public address separately from the location label.
Not as a default remedy. That changes the available protocol rather than proving correct coverage. Follow documented provider or administrator guidance for the specific deployment.
Usually a proxy extension controls supported browser traffic, not all device traffic. Confirm the extension's scope and test inside the browser profile where it is active.
Report it when one controlled endpoint repeatedly sees the same baseline address for the same family and an in-scope app after a fresh session and clean reconnect. Include the route scope and timestamps.
Disclaimer: This guide does not authorize disabling managed VPNs, security filters, IPv6, certificate checks, or organizational routing policy to force a different test result.
Sources:
Sources checked 8 September 2026.
Related Articles:
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.