Start by describing the difference
“The domain works differently on a VPN” can describe several problems. A name might resolve to a different IP address, fail to resolve at all, or resolve successfully while the website still will not load. Write down the exact hostname and the observed result with the VPN connected and disconnected. Include whether the problem affects a browser, an email application, or another service. Avoid recording passwords, VPN configuration files, or other credentials in shared troubleshooting notes.
Test the same hostname in both states, rather than comparing a bare domain with a www or mail hostname. Also check whether the issue affects only one device or multiple devices using the same VPN. These simple comparisons help separate a local device setting from a VPN-wide configuration. If the hostname belongs to an organization, ask whether it is intended to work only while connected to that organization’s network.
Understand what the VPN may change
Your device normally asks a DNS resolver to turn a domain name into an address. When a VPN connects, it may assign different resolvers or route DNS queries through its own network. Two resolvers can return different answers if one knows about private internal names, if their cached answers differ, or if the domain is deliberately configured to return different addresses to different networks. A public resolver may not know an organization’s internal hostname at all.
VPNs also vary in how they handle traffic. A full-tunnel VPN may carry most traffic through the VPN, while a split-tunnel setup may carry only selected traffic. Some organizations use split DNS: queries for certain domains go to internal resolvers, and other queries go elsewhere. Browser-based secure DNS settings may introduce another path. A browser can therefore appear to disagree with a command-line lookup on the same device. A different answer is not automatically an error; the useful question is whether each answer matches the network you are meant to use.
Compare DNS answers carefully
Run a lookup for the exact hostname with the VPN off, then repeat it with the VPN on. Tools such as nslookup or dig can show the returned addresses and, often, the resolver used. Record whether the query returns an address, a “name does not exist” response, or a timeout. If the service uses both IPv4 and IPv6, compare A and AAAA records separately. A device that prefers one address family may behave differently even when both lookups succeed.
For a public hostname, you can also query a known public resolver as a comparison, but treat that as a diagnostic step rather than proof that the VPN’s resolver is wrong. An internal hostname may be designed to resolve only through the VPN. Share only the details needed for support: the hostname, approximate test time, VPN state, resolver identity if appropriate, and the type of response. Private hostnames and returned addresses may themselves be sensitive in some workplaces, so follow local guidance before posting them publicly.
Check caches and application settings
DNS answers can remain in an operating system, browser, or application cache for a while. If a lookup changes after connecting the VPN but a browser continues to use the old destination, try a fresh browser session or clear the relevant DNS cache using your device’s documented procedure. A brief wait can also help when a cached answer has not yet expired. Repeatedly changing domain records is unlikely to fix a stale cache on one device.
Check whether the affected browser uses its own secure DNS feature and whether the VPN or organization expects that feature to be disabled or managed. On a work device, do not override managed settings without approval. Search domains can matter too: a short name such as “portal” may be expanded into different full hostnames on and off the VPN. Testing a complete hostname, such as portal.example.com, avoids confusing that behavior with a change to the same DNS record.
Separate resolution from reachability
If the hostname resolves to the expected address but the service does not open, investigate connectivity rather than assuming DNS is at fault. The destination may be reachable only through the VPN, or VPN routing, firewall rules, a proxy, or the service itself may be involved. A browser error saying a name cannot be found points in a different direction from a connection timeout or a certificate warning. Do not dismiss a certificate warning simply because the site loads without the VPN; it may indicate that you reached an unintended destination.
If only one VPN state fails, give the network administrator or service owner a concise comparison: exact hostname, application, DNS response in each state, and the resulting connection error. State whether other devices reproduce it. That evidence helps them check the intended DNS and routing policies without requiring you to guess at, or change, production records.
