Latency is the time it takes for data to travel from your device to a server and back, measured in milliseconds. Before anything else, it helps to understand that the internet isn't instant teleportation โ data travels through your local ISP, across international links, along backbone networks and undersea cables, passing through a dozen or more routing hops along the way, and each one adds time.
As a rough guide to what different latency ranges actually feel like:
| Latency Range | Real-World Experience |
|---|---|
| 5โ30ms | Extremely smooth, nearly imperceptible |
| 30โ80ms | Normal, web browsing unaffected |
| 100โ200ms | Noticeable; SSH sessions feel sluggish |
| 300ms+ | SSH input clearly delayed, streaming and API calls affected |
Why Physical Distance Sets a Hard Floor
Light travels through fiber at roughly two-thirds of its vacuum speed, which means geography imposes a minimum latency that no amount of hardware can beat. The straight-line distance from Los Angeles to Tokyo is about 9,000 kilometers, putting the theoretical minimum around 45ms. Real routing paths are longer and involve multiple hops, so actual latency runs higher.
Cross-continental access adds not just distance but routing complexity. A U.S. East Coast user hitting a European server typically sees 80โ120ms. Reaching an Asian node from there might be 150โ200ms. These numbers don't improve by upgrading the server โ they're physical constraints.
Why China Access Is Its Own Category
Accessing overseas VPS from mainland China involves more than just distance. Three factors stack on top of each other: available international bandwidth at the exit points, interconnection quality between China's three major carriers (China Telecom, China Unicom, China Mobile), and congestion during peak hours.
The result is that the same Tokyo VPS might show 50ms latency during the day and climb to 150ms or worse during evening peak hours, with packet loss rising alongside it. That's not a server problem โ it's international routing under heavy load.
This also explains why a Los Angeles VPS can sometimes feel smoother than a Tokyo node. If the LA server uses CN2 GIA or another China-optimized routing path that bypasses congested public exit points, the actual experience can beat an unoptimized Tokyo node despite the greater distance. Route quality beats geographic proximity when mainland China access is the priority.
What Each Region Actually Offers
U.S. nodes are the cheapest and have the most concentrated AI and GPU resources. They suit SaaS products and API services with a global user base. Asian users will see higher latency, which typically calls for a CDN layered on top.
Singapore is the default choice for Southeast Asian coverage. International backbone connectivity is stable, and the geographic reach across Southeast Asian markets is good. It costs more than U.S. nodes but makes sense for cross-border e-commerce and apps targeting that region.
Japan is relatively friendly for mainland Chinese users and delivers low intra-Asian latency. The main caveat is that some routes show evening peak-hour volatility. Testing during those hours before committing is worthwhile. Good fit for projects serving China and East Asian audiences.
Germany and the Netherlands are the standard European options. Hetzner and OVH offer strong price-to-performance here, with excellent intra-European latency. Asian access is poor โ this isn't the right region for an Asia-facing product โ but European GDPR compliance requirements often make it unavoidable.
Why SSH and AI Workloads Are More Sensitive
Regular web browsing tolerates latency reasonably well because most content can be cached, spreading the cost of a slow round trip across many assets. Two scenarios are different.
SSH is an interactive protocol. Every keystroke goes to the server and comes back before it appears on screen. 100ms of latency is noticeable when typing commands; 200ms is genuinely frustrating. If you're regularly SSH-ing in for Docker operations or debugging, server proximity matters more than almost anything else.
AI APIs and streaming services like Ollama are sensitive in a different way. High latency makes token-by-token output appear choppy and inconsistent, not just slower. Each packet arrives at irregular intervals, and the effect on perceived quality is worse than with traditional HTTP requests. As self-hosted LLM deployments become more common in 2026, data center selection for these workloads has become a more important decision.
What Cloudflare Can and Can't Fix
Cloudflare does improve latency in real ways, but it's important to understand the mechanism. It caches static content at edge nodes close to users, so most requests never reach the origin server. The path goes from "user โ VPS" to "user โ Cloudflare edge node" for static assets, and that shorter path reflects in lower latency.
Dynamic requests โ API calls, database queries, login validation โ still need to hit the origin, and Cloudflare can't change that. It's the right tool for accelerating content delivery to a global audience, not for masking API service latency.
How to Test Routes Before Buying
Most people buying a VPS look at specs and price, then order. Network testing gets skipped. That's how most bad data center choices happen.
Use Looking Glass. Most VPS providers publish a Looking Glass page where you can initiate ping and traceroute tests from their data centers to your IP. DigitalOcean, Vultr, and Linode all have them โ search for the provider name plus "looking glass." Results appear in seconds.
Test during peak hours, not just during the day. For mainland China access this is especially important. The 8โ11 PM window is when international routes are most congested, and that's when latency reflects real daily usage. A 60ms daytime result can easily be 200ms in the evening.
Look beyond ping โ check packet loss and jitter. Low latency with high packet loss still degrades performance significantly. Packet loss triggers TCP retransmission, which tanks actual throughput. The mtr command gives latency, jitter, and packet loss simultaneously:
mtr --report --report-cycles 20 <target IP or domain>Verify real bandwidth with a test file. Ping only measures round-trip time, not transfer capacity. Most VPS providers host test files for exactly this purpose:
wget -O /dev/null http://speedtest.tokyo.vultr.com/100mb.binSwap in the test file URL for your target node. Actual download speed reveals bandwidth quality in a way that ping can't.
Region Selection Quick Reference
| Primary User Base | Recommended Region | Notes |
|---|---|---|
| Global users | U.S. + Cloudflare CDN | Distribute static content via CDN |
| Mainland China users | Hong Kong, Japan, or LA with China-optimized routing | Route quality matters more than distance |
| Southeast Asian users | Singapore | Broad coverage, stable latency |
| European users | Germany or Netherlands | Hetzner offers strong value |
| AI / GPU workloads | U.S. West Coast | Most resources, lowest prices |
Closer isn't automatically better. The right data center is wherever your users are, not wherever you are. If you're based in China but your site serves a North American audience, the server belongs in the U.S., not Hong Kong. That sounds obvious, but I've seen it done the wrong way around more than once.