The trombone-routing trap: a packet between two Indian cities can physically leave the country — some cheap transit routes send Delhi↔Mumbai traffic through Singapore or even Europe before returning. The result is 90ms+ for a journey that geography says should take under 30ms. It happens more often on discount providers whose upstream buys the cheapest transit, not the best-peered.
1. The math nobody can cheat
Light in fiber moves at roughly 200,000 km/s — about 1ms per 100km one-way, plus equipment delay. So physics puts hard floors under honesty:
- Same metro (you in Mumbai → server in Mumbai): ~2–8ms achievable.
- Cross-country India (Delhi↔Mumbai, ~1,150km): ~15–35ms is normal for well-routed traffic.
- India → Singapore (~3,200–4,100km): ~60–100ms minimum — no amount of "premium bandwidth" changes the distance.
- India → Europe (~6,500km+): 120–180ms floor. India → US East: 200ms+.
If a provider's "India region" returns 90ms from a Delhi broadband connection, the machine isn't in India regardless of what the IP's geolocation record says.
2. Why GeoIP lies — and what doesn't
Geolocation databases map IP ranges to countries, and the records are set by whoever registered the block — a provider can announce India-registered IPs from hardware sitting in Frankfurt. WHOIS/geolocation answers "where is this IP registered", not "where is this server".
The checks that can't be faked:
- Latency: ping from your own connection — physics beats databases. Use our ping tester for a browser-side measurement.
- Path:
mtrortracerouteshows the actual hops — watch for international gateways appearing on an "in-country" route. - Consistency: test at peak evening hours, not noon — congested transit and oversold nodes both show up at 19:00.
3. What this means for our pages
Our VPS and Windows RDP nodes sit physically in Delhi NCR (one node is in Noida) and Mumbai datacenter facilities, on 10 Gbps ports. From major Indian metros that means ~5–50ms depending on your city and ISP — which is why our city pages publish expected ranges instead of a universal "low latency" claim, and why we built a ping tester instead of asking you to trust the map.
For interactive desktops the threshold that matters: under ~40ms an RDP session feels local; 60–100ms is workable; beyond that the lag is constant background friction. That's the entire argument for Indian users running Windows RDP on Indian nodes rather than a cheaper US box.