Why nslookup resolves over the VPN but the browser cannot

nslookup sends a query to the server you name and prints the answer, which is why it can succeed while every browser tab fails. A browser asks the operating system to resolve, and the operating system weighs per-interface resolvers, name resolution policy rules and the network location of the adapter. Then the browser may add its own encrypted DNS on top. Three different paths, one symptom, and the tunnel is usually not the broken part.

The checks below follow those paths from the system outward. Do not edit the VPN profile until you know which path answered and which one failed.

Three policies decide the answer

Each interface carries its own resolver list and search suffixes. A VPN adapter adds servers while the physical adapter keeps its own, and the system can take whichever answers first, so a lookup may be served outside the tunnel without anyone choosing that. Name resolution policy table rules can send selected domains to selected servers, which is how split DNS is normally expressed on Windows. And the VPN client or gateway can push a resolver address that exists only inside the private network.

Those three interact in ways that look arbitrary from a browser. A pushed resolver at a private address with no route through the split tunnel makes every lookup stall and then fail. A policy rule covering the internal suffix and pointing at a server that is down produces the same visible error as a missing route. A search suffix missing from the VPN adapter turns a short name into a public query for the wrong domain. Each one needs a different repair.

Why a browser asks a different question

nslookup issues its own query to the server it picks and follows neither namespace policy nor the browser's encrypted DNS setting. That is why a manual query against a public resolver answers while the browser reports that the site does not exist. You are comparing two programs, not two states of one program.

Address-family preference explains delay rather than failure. A browser that asks for IPv6 records first on a tunnel carrying only IPv4 waits for a timeout before falling back. Firefox has carried a preference for exactly this, and disabling it is a diagnostic step rather than a repair.

Read the resolver list and the rules

On Windows, dump what the system holds before theorising. Get-DnsClientServerAddress shows the servers per interface, Get-DnsClientNrptRule lists the namespace rules, and Resolve-DnsName answers the exact name through the system path. Compare that answer with a direct query against the VPN's server by address. When Resolve-DnsName fails and the direct query succeeds, the resolver list or a namespace rule is the suspect.

Check the name itself as well. An internal short name may need the private suffix that only the VPN adapter supplies, while the fully qualified name resolves fine. A certificate warning after a successful lookup belongs to a different problem.

The unreachable pushed resolver

A gateway or client can push a resolver address, and that address has to be reachable through the tunnel. On a split tunnel the private range holding the resolver may not be in the included routes, which produces a lookup that never gets an answer. Confirm the route exists, then query that address specifically, through the tunnel. This is the failure behind a browser domain error while a public resolver still replies.

If the resolver is unreachable, the repair is a route or an included subnet, not a different DNS server.

Encrypted DNS bypasses the whole path

Browsers with DNS-over-HTTPS resolve names themselves over an HTTPS connection to a chosen provider. With that on, the system resolver and the split-DNS rules are bypassed entirely for those lookups, so internal names fail in the browser while the operating system resolves them correctly. The reverse happens too: internal names succeed in the browser through a provider that should never see them, which is a policy problem rather than a connectivity one.

Decide deliberately whether encrypted DNS is allowed on managed devices, then configure it through the browser's management surface so the choice is visible. Leaving it to individual preference produces a fleet where the same VPN behaves differently on every laptop.

Repairs that match the failure

If the VPN pushes its resolver, make the tunnel carry traffic to it and make the same setting visible on the adapters that participate in resolution. If local sites stop resolving while connected, add explicit namespace exceptions or a conditional forwarder instead of replacing the resolver wholesale. If the browser's encrypted DNS bypasses policy, that is the setting to change. Never add a public resolver to fix an internal name: it leaks private queries and does not resolve the name.

Then separate lookup from connection. A name that resolves to the right address but refuses a connection is a service, firewall or certificate problem, and DNS changes will not fix it.

Record which path answered, which one failed and what you changed. The next report of the same symptom then takes one command instead of an afternoon.