Why Some VPNs Put Their “India” Servers Abroad—and When the Flag Is the Wrong Choice

The upload reached 31 percent and froze. I was in a Bengaluru hotel, trying to deliver a campaign video to a client in Mumbai before their 6 p.m. review. My VPN said India, the hotel Wi-Fi showed full signal, and the client portal had already restarted the upload twice. I blamed the router, switched to my phone hotspot and began again. The percentage stopped at 31 exactly as before.

The file was 840 megabytes.

I had forty-seven minutes left.

Without the VPN, the client portal opened quickly. With it, the connection felt as though the file had taken a long detour before coming back to India.

That made no sense. I had selected an Indian server while sitting in India.

At least, I thought I had.

The India label described the IP, not the hardware

I checked my public IP address.

The lookup placed me in Mumbai.

Then I checked the provider’s support page. Its “India” location was virtual: it supplied an Indian IP address, but the physical server handling the connection was outside India.

Some providers route virtual India locations through Singapore or the UK. Others use different nearby data centres. The destination website sees an Indian IP, while the traffic still travels to wherever the hardware is actually running. (Expressvpn)

That does not make the location useless.

Someone outside India may need an Indian IP for a workplace system, local search results, a regional account or a website that checks location. A virtual server can provide that access without placing the hardware inside India.

But the route remains physical.

From my hotel room in Bengaluru, the upload was leaving India before reaching the client’s system. The India flag had solved a location problem I did not have while adding distance to a task that needed a steady connection.

The provider had disclosed the arrangement. I had simply mistaken an IP label for a promise about where the server stood.

To understand why the server had moved, I had to look beyond the map.

The server moved because the rules changed

In April 2022, the Indian Computer Emergency Response Team issued cybersecurity directions covering VPN providers, cloud services, data centres and other companies.

The rules require covered organisations to keep system logs for 180 days. VPN providers must also retain specified customer information—including names, assigned IP addresses, contact details and the stated purpose for using the service—for five years or longer after the service ends. (Org)

The requirements apply to providers, not ordinary people using a VPN.

For services built around collecting as little user information as possible, operating physical hardware in India created a direct conflict. Several major providers removed their Indian servers rather than redesign their privacy model around the new retention requirements.

Demand for Indian IP addresses did not disappear with the hardware.

People abroad still needed to reach workplace systems, regional services and accounts that expected an Indian location. Providers therefore brought the India option back virtually.

NordVPN says it closed its physical Indian servers after the CERT-In rules and introduced a virtual Indian location in January 2024. (Nordvpn) ExpressVPN offers Indian IP addresses through virtual locations physically hosted in Singapore and the UK. (Expressvpn)

The India button remained.

The machine behind it moved.

Once I understood that, the route on my laptop stopped looking like a technical mistake. It was a deliberate compromise: preserve the Indian IP without keeping the server under India’s local retention requirements.

That explained the design.

It did not finish my upload.

The virtual server was solving the wrong problem

I restarted the established provider and tried its second Indian location.

The service had genuine strengths: years of public history, a mature application and clear documentation about where its virtual servers were hosted.

The client portal opened.

I selected the file again.

Ten percent.

Twenty-four.

Thirty-one.

The upload paused, fell back to 29 and failed.

The hotel Wi-Fi had weakened briefly as the laptop moved between two access points. The VPN reconnected, but the client portal discarded the interrupted transfer.

I tried the phone hotspot again. The mobile signal inside the room moved between two and four bars, while the virtual India route still sent the traffic through its physical host abroad.

The practical distinction was simple: an IP could appear Indian while speed and latency still followed the real server location. (Reddit)

That was exactly what the upload exposed.

The virtual server was doing its intended job. It gave me an Indian IP without placing the provider’s hardware inside India.

I was asking it to do a different job: provide the most direct and resilient route for a large upload from Bengaluru.

Those were not the same requirement.

The client messaged me:

“Can we at least get the low-resolution version before the meeting?”

I had already compressed the video once. Compressing it again would make the text in the final scene difficult to read.

Instead of reducing the file, I changed the question.

I stopped asking for an Indian IP

The client portal did not require an Indian location. My client had colleagues signing in from London and Dubai every day.

I had selected India because it looked local, and I had assumed local meant faster.

What I actually needed was a protected connection that could survive weak hotel Wi-Fi and a switch to mobile data without restarting the upload.

I opened OnlydogVPN, the smaller backup on my laptop.

It did not begin with a country map. Its first options described the situation. I selected the preset for a weak or changing network.

The connection opened.

I returned to the client portal and selected the same 840-megabyte file.

The upload passed 31 percent.

Then 48.

At 63 percent, the hotel Wi-Fi dropped for several seconds. The laptop moved onto my phone hotspot.

The progress bar paused.

Then it continued from 63.

I left both devices on the desk and watched the number rise without touching the VPN screen.

Eighty-two.

Ninety-six.

Complete.

The portal generated a preview and sent the client an automatic notification. I opened the review page and played the final scene from beginning to end.

No missing frames.

No compressed text.

No third upload.

The smaller app’s weak-network preset used an HTTP/3-based connection that recovered when the laptop moved from hotel Wi-Fi to mobile data. More importantly, it removed the country and protocol guessing that had consumed most of the previous half-hour.

The upload finished with eleven minutes remaining.

That was the result I had been trying to achieve from the beginning. I did not need an Indian-looking IP. I needed the same transfer to remain alive while the network underneath it changed.

The India IP became useful later

The client opened the file during the meeting and asked me to check the mobile version of the campaign page.

My phone was not connected to the VPN. With a conventional account-based service, I would have needed to find the password, sign in again and approve another device.

The smaller service displayed a verification code on the laptop.

I entered it on the phone, connected and opened the mobile preview without creating another login. Then I checked the button spacing and sent the client a screenshot.

That second-device connection was not why I had opened the app. The upload had already solved the urgent problem. It simply removed the next piece of friction once the meeting began.

The virtual India server also became useful later.

Two days after leaving India, I needed to check the regional version of the client’s website. This time, an Indian IP was exactly what I needed. The fact that the hardware sat elsewhere did not prevent the website from recognising the intended location.

The server had not changed.

The task had.

That was the distinction I had missed in Bengaluru.

A virtual India location answers one question:

What country should this IP appear to be in?

It does not automatically answer:

Where is the hardware? How long is the route? Will the connection survive a weak hotel network? Is it the best choice for a large upload from inside India?

I could not inspect the provider’s internal routing decisions or every handoff between the hotel, mobile operator and remote server. I could see the outcome: the virtual India routes repeatedly lost the upload, while the smaller app carried the same file through a network switch and completed it.

The flag is useful only when location is the task

Virtual India servers let providers offer Indian IP addresses without operating physical hardware under India’s retention rules. That is why several privacy-focused services use them.

For someone abroad who needs an Indian online location, the arrangement can be exactly right.

For someone already in India, the same route may send traffic farther than expected. The difference becomes visible during live calls, remote desktop sessions, gaming and large uploads, where the physical path matters more than the country shown in the menu.

The smaller service has fewer locations, fewer independent ratings and a shorter public history than the established provider I tried first. That is its clearest limitation.

But my deadline was not testing how many flags an app could display.

The established provider’s virtual India option successfully produced an Indian IP. It failed the upload because an Indian IP was never the real requirement. The smaller app ignored the flag, kept the transfer alive through a network change and delivered the file before the review began.

Virtual India servers exist because providers want to preserve Indian online access without keeping physical servers under India’s retention rules.

That afternoon in Bengaluru, the useful decision was knowing when the India button was solving a problem I did not have.