Tokyo VPN server: East Asia endpoint for low-latency routes

Tokyo is the second endpoint that meaningfully changes performance for users in East Asia. It is the best companion to Hong Kong: when one route is congested, the other usually is not, and the failover is a single tap in the app.

This page covers the Tokyo node's network location, peering, latency benchmarks, and when to pick it over Hong Kong.

Network location

Our Tokyo node sits inside a Tier-3 Tokyo data center with multiple upstream carriers and a short physical distance to the submarine cable landing points connecting Japan to mainland China and Korea. Peering is direct rather than transited, which is why the latency numbers below hold up even during peak hours.

Latency benchmarks

Origin city	Round-trip to Tokyo (ms)
Seoul	30–45
Beijing	50–75
Shanghai	45–65
Shenzhen	60–90
Hong Kong	55–70
Taipei	50–70
Singapore	70–95
Los Angeles	100–135

Northern Chinese cities generally route to Tokyo faster than to Hong Kong — the submarine cable topology favors Japan. That is why Beijing users often prefer Tokyo as their default.

When Tokyo beats Hong Kong

• You are physically in northern China (Beijing, Tianjin, Dalian, Shenyang)
• Hong Kong is slow on a given day due to route congestion (20:00–23:00 China time is often the worst window)
• You are connecting from Seoul, Taipei, or Japan itself
• You want a second-choice endpoint to switch to if Hong Kong hiccups mid-call

Protocols available

Same shipping transport stack as Hong Kong: OpenVPN UDP, OpenVPN TCP wrapped in Cloak on port 443, and Hysteria2 with salamander obfuscation. The client picks the working transport automatically.