The VPN Said “Connected,” but My DNS Was Still Taking the Hotel’s Route

The VPN icon was green, my public IP had changed, and the client’s launch dashboard still would not open.

I had forty minutes before a new payment page was due to go live. From a hotel room, I needed to check the final build, approve two translations and send the release message to the client’s team.

Instead, Chrome displayed:

DNS_PROBE_FINISHED_NXDOMAIN

I blamed the dashboard first. Perhaps someone had changed the domain record too early. I copied the address into Firefox.

Same result.

Then I disconnected the VPN.

The page opened immediately—but it showed the public holding screen rather than the private preview I was supposed to review.

That made no sense. The VPN application said I was connected to the correct region. An IP-checking page agreed. Yet the domain was still resolving as though the laptop were using the hotel’s network.

I flushed the DNS cache, restarted both browsers and reconnected to another VPN server.

The green icon returned.

So did the wrong page.

A changed IP does not mean DNS changed with it

I had treated the VPN status light as proof that the entire connection had moved into the tunnel.

It had not.

Before a browser can open a website, it must translate the domain name into an IP address. DNS performs that lookup. When web traffic uses the VPN but DNS follows another route, the browser can ask one network where a site lives and then use a different network to reach it.

That split produces confusing failures:

A private company address returns “not found.”

A service opens in the wrong regional version.

A filtered domain stays blocked.

One browser works while another fails.

A DNS test still shows the hotel, internet provider or public resolver even though the VPN reports a different location.

DNS requests also reveal which domain names a device is trying to reach. Encrypting the final website connection does not automatically bring those separate lookups into the same protected path. (RFC 9076)

In my case, the client’s dashboard had both public and private answers. The VPN route could reach the private environment, but the laptop was still asking the wrong resolver where to find it.

The traffic had moved.

The directions had not.

The browser had quietly chosen its own resolver

The first useful clue was inside Chrome.

Modern browsers can handle encrypted DNS independently of the operating system. Chrome’s “Use secure DNS” setting can send lookups to a chosen provider, while Firefox offers several DNS-over-HTTPS protection levels.

That can prevent an untrusted hotel resolver from seeing ordinary DNS requests.

It can also bypass the DNS route created by a VPN.

Months earlier, I had selected a custom Secure DNS provider in Chrome and forgotten about it. The setting lived inside the browser, so changing VPN servers did nothing to it.

Chrome was encrypting its DNS requests, but sending them to the resolver I had selected before the trip. The VPN’s DNS path never saw them.

Firefox behaved differently because its DNS setting was automatic. But the laptop still had both the hotel connection and the VPN adapter available, so its result was not consistently better.

That explained why my fixes kept missing the problem. Restarting the VPN did not change Chrome’s private setting. Flushing the operating system cache did not necessarily clear the browser’s own answer. Switching servers moved the tunnel while leaving the lookup route untouched.

Other users have described the same maddening split: direct DNS tests work, but ordinary applications keep choosing the physical network’s resolver. (Reddit: r/sysadmin) The detail mattered because it matched the failure in front of me. The tunnel existed; the applications were not using it consistently.

That led me back to the VPN settings.

Split tunneling created too many valid paths

The established provider had been a reasonable choice.

It had years of public history, a large support operation and hundreds of server locations. I trusted it enough to install it on my work laptop.

It also had split tunneling enabled.

Split tunneling lets some traffic use the VPN while selected applications or destinations remain on the ordinary connection. At home, I had used it to preserve access to local devices.

In the hotel room, it gave the laptop another way to make the wrong decision.

Chrome had its custom resolver. Windows had the hotel adapter and VPN adapter. The VPN had an exclusion list I barely remembered configuring. The private domain needed an answer available only through the correct protected route.

I disabled split tunneling, returned Chrome’s Secure DNS setting to automatic and reconnected.

The dashboard opened once.

Then the hotel Wi-Fi dipped, and it failed again.

I changed servers. The preview loaded, but the translation tool beside it returned another name-resolution error. After restarting the browser, the translation tool worked while the dashboard disappeared.

I could not observe the hotel network’s internal filtering or routing rules. What I could see was a setup with too many independent decision-makers.

Every layer was meant to improve security, privacy or convenience.

Together, they made the result unpredictable.

A public DNS server was not the answer

My next idea was to bypass the hotel’s resolver manually.

I entered a well-known public DNS service in the network settings, cleared the cache and tried again.

Ordinary sites loaded quickly.

The private dashboard did not.

That failure clarified the real problem. I did not merely need a different DNS provider. I needed the lookup to travel inside the same protected context as the traffic that would use its answer.

A public resolver could locate public websites. It could not provide the private answer expected through the client’s route.

The distinction was small but decisive:

“Change my DNS” was not the task.

“Keep DNS and traffic on one intended path” was.

By then, I had twenty-three minutes left.

I stopped adjusting browser, Windows and VPN settings one switch at a time. The number of possible combinations had become the problem.

The smaller app gave me one decision

I still had OnlydogVPN installed from an earlier trip.

It has fewer server locations than the established provider, a shorter public history and fewer independent reviews. Those limitations would matter if I needed a particular small city or an unusual exit location.

I did not need a map.

I needed the private dashboard to resolve correctly and remain open long enough for me to approve the release.

The smaller app organized its connection options around situations rather than geography and protocol names. I selected the setting for a restricted public network.

There was no split-tunneling list to audit and no custom DNS field to reconcile with the browser. I left Chrome’s Secure DNS setting on automatic, connected and repeated the test.

The DNS result changed.

More importantly, the dashboard opened.

Not the public holding page. The private preview.

The payment form displayed the correct currency. The translation panel appeared beside it. I moved through the English, Spanish and Japanese versions without another NXDOMAIN error.

I submitted the approval.

The client’s upload began. When the hotel connection weakened, the progress bar paused briefly and continued instead of forcing me to rebuild the session. A few minutes later, the release status changed from Pending to Ready.

That was the first result all evening that mattered.

Instead of asking me to coordinate a resolver, exclusion rules, server geography and browser behavior, the smaller app kept the task on one working route.

For the first time, the green VPN icon corresponded to something observable: the name lookup and the page it identified were both working inside the same connection.

The phone revealed the value of keeping the setup together

The client then asked me to verify the mobile checkout before publishing.

My phone was still using the hotel Wi-Fi with its own network settings. I expected another round of password entry, account verification and DNS testing.

The service let me connect the phone using a verification code.

I did not have to enter an email password on the hotel network or reproduce the laptop’s configuration. Once connected, the private mobile preview opened with the same release version.

I completed a test transaction, sent the screenshot and watched the client publish the page.

This was not the main reason the smaller app solved the problem. The launch had already been approved from the laptop.

But it removed the next place where the setup could split apart. One code gave the second device the same working path without another set of local exceptions.

I left it installed on both devices.

What an unchanged DNS result is really telling you

A DNS test is not the task itself. The real test is whether the site, service or private resource opens correctly.

Still, when a VPN says connected and a private, filtered or region-dependent domain continues to resolve incorrectly, the unchanged DNS result is an important clue.

Start with the browser. Check whether Secure DNS or DNS-over-HTTPS is locked to a custom provider. That choice may override the resolver expected by the VPN.

Then inspect split tunneling. An excluded browser or application may continue using the physical connection.

Clear both browser and operating-system DNS caches, then reconnect. An old negative or regional answer may survive after the route changes.

Finally, test the result that caused you to investigate. Does the private dashboard open? Does the correct regional page appear? Can the upload finish? Does the connection recover when the Wi-Fi drops briefly?

My established provider offered more servers and more advanced controls. Those strengths remained real. Under a deadline, they also left several different routes for me to identify and reconcile.

The smaller service offered fewer choices, but it produced one consistent result across the browser, the dashboard and the second device.

The VPN that saved the launch was not the one with the most convincing “Connected” badge. It was the one that made the domain name and the data take the same road.