You connect a VPN, open an IP checker and see a new address. A few minutes later, another checker shows something different. Before changing settings, establish exactly what each page measured. An address belongs to a connection observation; it is not a complete description of the device, the person using it or every route available to an application.
This guide follows a common support problem: a laptop appears to use the expected VPN exit for ordinary browsing, while a call application or another website seems to use a different route. The aim is to produce a finding that an administrator can reproduce. You will need the VPN configuration, the browser version and a small record of observations. You do not need to publish your addresses in a forum.
Start with the endpoint that saw the connection
A public IP service reports the source address visible to that service. If the request passes through a VPN gateway, a proxy or a carrier translation system, that intermediary can determine the address the service sees. A local address such as 192.168.1.24 normally describes an interface inside a private network and answers a different question.
The public IP tool makes a browser request to an external IP service when you run it. Its result therefore concerns that request. A request made by a site’s backend would show the backend’s route instead. This distinction matters when comparing screenshots from different products: confirm whether each measurement originates in the browser, an installed application or a remote server.
Write down the observed address family as well as the address. A service reached over IPv4 can report a translated IPv4 address while another service reached over IPv6 reports a different address assigned through your network. The difference alone does not establish that either request bypassed an intended policy.
Distinguish home NAT, carrier NAT and a VPN exit
A home router often translates connections from several private devices to one public IPv4 address. Carrier-grade NAT adds another translation layer in the provider’s network. RFC 6598 reserves 100.64.0.0/10 as shared address space for that use. Seeing an address from that block on a router’s upstream interface is evidence to investigate carrier translation, but an external IP service usually sees the public side of the translation.
Private address space, shared address space and publicly routable addresses serve different purposes. Do not infer ownership or reachability from whether an address contains familiar-looking numbers. Read the complete prefix. The shared block runs from 100.64.0.0 through 100.127.255.255; it does not cover every address beginning with 100.
A VPN can add a further exit point. Several customers may share that exit address, and the provider may rotate the address or route different destinations through different gateways. An address matching a provider’s expected network is useful routing evidence. It does not show that local applications, DNS queries and connection failures all follow the same policy.
Build a small comparison record
Start with a settled network connection. If a VPN is required for the activity, keep that requirement in place rather than disconnecting it merely to obtain a baseline. Record the expected route from the configuration or administrator. Use a non-sensitive test destination, and avoid changing Wi-Fi networks, VPN endpoints or browser profiles between measurements.
| Field | Example entry | Why it matters |
|---|---|---|
| Application | Browser profile A | A second browser can have a different proxy setup. |
| Expected route | Full-device VPN, endpoint selected manually | Defines the behaviour being tested. |
| Request type | HTTPS IP check | Does not stand in for UDP or another application. |
| Address family | IPv4 | Allows a meaningful comparison with another observation. |
| Network state | Wi-Fi connected; tunnel settled | Separates normal operation from a reconnect transition. |
| Time and result | Local timestamp and privately retained address | Helps correlate the result with configuration and logs. |
Run the same check twice before drawing a conclusion. If it changes without an intentional intervention, note the interval and inspect the connection state. Load balancing, a network transition or a provider-side reassignment may explain the variation. Repetition establishes whether the behaviour is stable enough to investigate; it does not turn an incomplete test into comprehensive coverage.
Work through an IPv4 and IPv6 mismatch
Consider a fictional laptop whose IPv4 check uses the expected VPN exit, while an IPv6-capable destination receives a global IPv6 address from the access network. The next question is whether the VPN configuration promises to carry IPv6. Some configurations tunnel both families, some deliberately block one, and others leave it outside the tunnel.
First confirm that the second observation is actually IPv6 and that it was made from the same application while the tunnel was active. Then review documented IPv6 handling in the VPN client and operating-system route information. If the configured requirement is full-device tunnelling for both families, an access-network IPv6 route is a concrete discrepancy worth escalating.
Do not respond by randomly disabling network features across the device. A temporary, documented configuration change can help isolate the issue, but it needs a recovery plan and a clear expected result. After the correction, repeat both address-family checks and test the applications that originally exposed the inconsistency. Keep the original observation so that you can explain what changed.
Check whether the product is a proxy or a device tunnel
A browser extension described as a VPN may operate as a browser proxy. That can be useful, but its coverage is defined by the browser’s proxy behaviour rather than by the product name. A desktop mail client, software updater or call application may continue to use the underlying network. Split tunnelling can create similar differences deliberately.
Review excluded applications, destination exceptions and any browser-specific proxy configuration. Corporate networks sometimes send internal services directly while routing public traffic through a gateway. The correct test is whether a request follows the intended rule. Treating every differing address as a defect makes an intentional exception harder to distinguish from a real routing error.
For WebRTC, use the candidate inspection tool as a separate observation. ICE candidate gathering can involve STUN and different transport behaviour. A candidate list is not a packet capture of every subsequent call. Retain candidate types and completion state when comparing it with an HTTPS result.
Avoid conclusions that an IP address cannot support
Geolocation databases can disagree about a city, region or provider because assignments and routing change. A database entry is not a GPS measurement. An address associated with a hosting network may represent a VPN gateway, a corporate service or another intermediary. A single lookup cannot reliably identify the person responsible for a request.
Likewise, an address changing does not establish that account recognition has stopped. A signed-in account, a session cookie and browser characteristics can continue to link activity. If your question concerns separation between activities, examine account and storage boundaries as well as network routes. Network troubleshooting and identity separation need different evidence.
Investigate failure states separately
If an inbound service is the actual problem, record that separately from outbound browsing. Port forwarding on a home router cannot by itself configure an upstream carrier translation gateway. Confirm whether the provider offers a reachable public address or another supported access method. An outbound IP checker can help describe the environment, but it cannot verify the firewall rule, listening service and return path needed for an inbound connection.
A successful check while a tunnel is settled says little about disconnection and reconnection. A kill-switch requirement concerns those transitions. Test them only in a controlled setup with suitable monitoring and non-sensitive traffic. A webpage that reports one address after a reconnect may miss a brief interval when another route was available.
When a check fails completely, preserve the error. A blocked endpoint, browser extension, DNS problem or unavailable service can all prevent the observation. “No result” is not an address and is not evidence that all traffic is blocked. Try to establish whether the test destination is reachable and whether the same failure occurs with other permitted destinations.
Frequently asked questions
Does restarting a router always change my public IP?
No. Assignment depends on the provider, lease behaviour and service configuration. A reconnect can retain the same address or receive another one. If you need a stable inbound endpoint, confirm the service’s addressing and reachability options instead of relying on restart behaviour.
Can two households show the same public IPv4 address?
Yes. Carrier translation or a shared proxy can place several customers behind one public address. Investigations that need to distinguish connections may require additional records, including timestamps and ports. A public address by itself does not uniquely identify a household.
Why does my browser show a different address from a command-line request?
The applications may use different proxy settings, address families or tunnel exceptions. Compare the same destination where practical and inspect each application’s configuration. Also verify that one result was not produced by a remote server acting on your behalf.
What should I send to support?
Send the expected route, application, address family, time, connection state and reproducible steps through an appropriate private channel. Include the smallest necessary address evidence. A precise report about one unexpected route is more actionable than a general claim that the whole VPN has failed.