The VPN Said New York. The Website Still Put Me in Madrid

The VPN app said I was connected to New York. An IP checker agreed. The client’s retail site did not: prices appeared in euros, the store finder placed me near Madrid, and the checkout refused to offer the Manhattan pickup option I needed to demonstrate in fifteen minutes. I blamed the VPN, changed to another New York server and reloaded the page. Madrid remained.

I had assumed that changing my IP address would change my location everywhere.

The green VPN icon proved only that one location signal had changed. The website had several others—and it appeared to trust them more.

The IP had moved, but the browser had not

A website can estimate location from an IP address. It can also ask the browser for the device’s physical position. When permission is granted, the browser may use the operating system, nearby Wi-Fi networks and other device signals instead of the VPN server’s location. (W3C, Geolocation, explaining how websites request device-location)

I clicked the icon beside the client site’s address.

Location access was set to Allow.

Months earlier, I had approved the request while testing the store finder at home. The browser had remembered that choice. Now, from a Madrid hotel room, it was giving the site a much stronger location signal than my New York IP address.

To confirm it, I opened a map in another tab and pressed the location button.

The blue dot landed within a few streets of the hotel.

That explained why changing VPN servers had accomplished nothing. The site did not need to guess where I was from the IP address because the browser was telling it directly.

I changed the site’s location permission to Block, closed the tab and opened it again.

The store finder no longer placed me beside the hotel.

For a moment, that looked like the solution. Then the homepage loaded in Spanish and the prices remained in euros.

Removing the precise location had exposed the next clue.

The website remembered where I had been

Search engines and retail sites do not always begin each visit with an empty memory. They may use cookies, account history, previous searches and recently stored location data alongside the current IP address. Google’s own location documentation describes this mix of device signals, IP information and previous activity. (Google, location documentation covering device location, IP)

A VPN changes the network route. It does not erase what the browser or account already remembers.

I cleared the client site’s cookies and local storage, signed out of the test account and opened a private window. Then I reconnected to the original New York server.

This time the site changed countries.

It still chose the wrong city.

The homepage displayed US prices, but the store finder placed me near Philadelphia. A separate IP checker continued to describe the address as New York.

I changed servers again. The site moved me to New Jersey.

A third attempt produced the right country but no Manhattan inventory.

The VPN was connecting successfully each time. The disagreement was happening after the website received the new address.

That distinction mattered. I was no longer fixing a browser permission or stale cookie. I was testing whether the target site recognised the VPN route as the location I had selected.

A city label inside the VPN app was not enough

IP location does not come from one universal map. Different websites use different databases, and those databases may associate the same address with different cities. An address can also remain linked to an older location after a network changes how it is used. (MaxMind, guidance on differences between IP-geolocation databases)

That was why the VPN app could say New York, an IP checker could agree, and the client site could still say Philadelphia.

The established provider remained a reasonable first choice. It had years of public history, broad server coverage and many locations to try.

But the large server list was not solving the immediate problem. Every new attempt meant reconnecting, clearing the session and checking the client site again. The label changed more reliably than the result.

Other users run into the same confusion: an IP test shows the chosen VPN location while Maps, Search or another website continues showing the real or previous one. (Reddit discussion) The useful lesson was brief—the IP checker was only one opinion.

By then, I had already blocked precise location and removed the old browser data. The remaining test was simple:

Could the VPN provide a route that the client’s actual website accepted as New York?

The established provider had given me several New York-labelled routes. None had completed the demonstration.

The smaller app gave the site a clean second attempt

I disconnected the established service and opened the smaller app named in the disclosure.

There was no conventional email-and-password registration before I could begin. Instead of sending me back through another long city list, the app offered a situation-based option for location-sensitive browsing.

I selected it and connected.

Then I kept the browser test clean.

Location permission remained blocked. The old cookies were gone. I opened a fresh private window and loaded the client’s homepage.

Prices appeared in dollars.

The store finder opened over Manhattan.

I selected the branch the client wanted to demonstrate, added the product to the cart and reached the pickup confirmation page. The option that had been missing for the previous twenty minutes was now available.

I joined the client call and shared my screen.

The regional homepage stayed in the United States while I moved through search, inventory and checkout. The campaign-preview tool also loaded the US version instead of redirecting me to Spain.

The original task was complete.

Only after that result did the connection design matter. The service uses an HTTP/3-based transport with additional obfuscation. In practical terms, it supplied a route the target site recognised consistently and kept that route active throughout the demonstration.

I could not inspect which internal location signal the client site weighted most heavily. I could see the sequence: once browser location and old site data were removed, the established servers produced inconsistent city results, while the smaller app opened the requested regional experience and kept it open.

That was the difference that mattered.

The network changed, but the location did not

Near the end of the call, the hotel Wi-Fi weakened.

Product images began loading slowly, so I switched the laptop to my phone’s hotspot. The meeting paused briefly and returned.

The client site stayed on the Manhattan store.

I refreshed the checkout page. The pickup option remained available.

That moment was more convincing than another IP-checking tab.

A location-sensitive session can fail again when the underlying network changes. The VPN may reconnect with a different route, and the website may reassess the visitor’s location. With the earlier provider, I had already seen how easily one New York-labelled server could produce a different city on the target site.

The smaller app recovered without sending me back through the server list or changing the regional storefront.

Once the call ended, I noticed its blocked-request counter had increased. The service had also stopped a number of advertising and tracking requests while I moved through the retail site.

That was not what corrected the store location. Blocking the browser’s location permission and clearing the stale site data had removed the stronger conflicting signals.

The counter did solve a smaller problem that followed naturally from the first one. Once the page was showing the correct region, fewer third-party requests were collecting additional information around the session.

The VPN had never been the only location setting

By then, the original failure looked less mysterious.

The first New York connection had changed my public IP address. The browser was still sharing the laptop’s physical location.

After I blocked that permission, the site still had cookies and account history from Madrid.

After I removed those records, the website relied more heavily on the VPN address—but the established provider’s New York servers were not interpreted consistently by the site’s location database.

Each step removed one reason for the wrong result.

The established provider offered more server locations, a longer public history and more independent reviews. The smaller service has fewer locations and less public history, which remains its clearest limitation.

For this task, though, the larger network created more options to test rather than a faster answer.

The smaller app gave me the one outcome the client cared about: the website opened in the requested city, showed the right inventory and stayed there when the connection changed.

That also changed how I now approach the “VPN connected but location is wrong” problem.

First, I confirm that the public IP has changed.

Then I block browser or operating-system location access for the site.

Next, I clear the site’s stored data or test it in a fresh private session.

Only after those signals are gone do I judge the VPN route itself.

A VPN can change where the internet connection appears to begin. It cannot erase a location permission, an old cookie or an account history that the website already trusts.

Once those competing signals were removed, the comparison became fair—and much shorter.

The established service kept offering New York by name. The smaller app delivered the New York page the client could actually use.

For that demonstration, the correct location was not the city printed inside the VPN window. It was the city that remained on the checkout page.