110+ Countries / 170+ Routes

Global Server Routes

The route directory is organized by region, city, and connection type. The page shows selected representative endpoints to help identify target regions and route types; the complete available list is provided in the client after login.

Unlimited Devices Bank-Grade Encryption 30-Day Money-Back Guarantee No Email Address Required
ROUTE DIRECTORY Regional Entry Points
110+ / 170+
AP
Asia-Pacific Hong Kong · Tokyo · Singapore · Seoul
IEPL
NA
North America Los Angeles · San Jose · New York · Toronto
Relay
EU
Europe Frankfurt · London · Paris · Amsterdam
Direct
GL
Other Regions Dubai · Istanbul · Johannesburg · São Paulo
Choose by Region
The client displays connection options based on currently available routes
ROUTE INDEX

Browse Server Routes by Region

The same country may include multiple cities and connection types. This table provides a regional overview without showing latency, load, or bandwidth. For an actual connection, test routes based on your network, the target service region, and the time of use.

Selected Server Route Directory
Country or Region City Route Type Streaming
Asia-Pacific
Hong Kong, China Hong Kong IEPL Supported
Japan Tokyo IEPL Supported
Singapore Singapore IEPL Supported
South Korea Seoul Relay Supported
Taiwan, China Taipei Relay Supported
Thailand Bangkok Relay Test with the Target Service
Malaysia Kuala Lumpur Direct Test with the Target Service
Indonesia Jakarta Direct Test with the Target Service
North America
United States Los Angeles IEPL Supported
United States San Jose Relay Supported
United States Seattle Direct Supported
United States New York Relay Supported
Canada Toronto Relay Supported
Canada Vancouver Direct Test with the Target Service
Europe
Germany Frankfurt IEPL Supported
United Kingdom London Relay Supported
France Paris Relay Supported
Netherlands Amsterdam Direct Supported
Poland Warsaw Direct Test with the Target Service
Spain Madrid Direct Test with the Target Service
Other Regions
United Arab Emirates Dubai Relay Test with the Target Service
Türkiye Istanbul Direct Test with the Target Service
South Africa Johannesburg Direct Test with the Target Service
Brazil São Paulo Relay Test with the Target Service
ROUTE TYPES

The Differences Between Three Route Types

Route names describe the approximate path from your local network to the target region. Dedicated, relay, and direct routes are not simply ranked from best to worst; the right choice depends on connection direction, use case, and current network conditions.

IEPL IEPL

Dedicated Cross-Border Transport Path

IEPL routes connect the entry and exit points through transport paths designed for enterprise network connectivity, with fewer segments relying on the public internet. Their main advantage is a clearer path, which can make performance more consistent for cross-border access, sustained transfers, and long-running sessions. Video calls, remote desktops, cloud document sync, and content that requires continuous loading are often good candidates to test on this route type first.

Dedicated route infrastructure costs more to build and maintain than ordinary public-network paths, so identical endpoints are not available in every city. You do not need to choose the geographically nearest city by default. First confirm where the target service is located, then compare IEPL and relay routes in the same direction. If the target is in North America, an Asia-Pacific endpoint may be geographically closer but still less suitable than a North America-facing IEPL route.

RELAY Relay

Connect to an Entry Point First, Then Reach the Target Region

A relay route sends the connection to a suitable entry point first, then uses an intermediate link to reach the target city. It helps avoid some less suitable direct paths while balancing regional coverage and route cost. For streaming, AI tools, web browsing, and regular file transfers, relay routes generally offer broad regional choice and are the main alternative when no IEPL endpoint is available.

Relay performance depends on the entry point, exit point, and local carrier network. Two relay routes in the same city may use different paths, so the city name alone cannot predict performance. If connection setup is slow or an app repeatedly retries, switch first to another relay route in the same region. If the target service supports multiple regions, consider a nearby region rather than repeatedly changing other client settings.

DIRECT Direct

Reach the Exit Through the Public Network

A direct route reaches the target exit from the current network with fewer intermediate routing steps, allowing more flexible city coverage. It suits everyday browsing, occasional access, backup connections, and situations where the local network already has a good path to the target region. Direct does not automatically mean lower performance; when the carrier network matches the exit direction well, it can be a simple, responsive option.

Direct routes are more sensitive to changes in the local network. Different access networks, regions, and busy periods can change the actual path, so one test is not enough for a long-term conclusion. Keep a relay endpoint in the same region for comparison. If direct access works for opening pages but stalls during long transfers, switch to relay or IEPL. If a relay route takes an obvious detour, direct may be the simpler choice.

How Cost Differences Affect Route Configuration

Dedicated routes require ongoing investment in cross-border transport resources, so they are best concentrated in high-demand directions. Relay routes expand coverage by combining entry and exit points with more flexible resource scheduling. Direct routes rely on public-network paths, cover more regions, and provide backup endpoints. A well-designed route directory normally retains all three types rather than relying on only one.

DvVPN monthly-plan traffic resets each month on the activation date. Traffic bundles remain available until used and never expire. Route type does not change the traffic rules included with a plan. Choose a monthly plan or traffic bundle based on usage frequency, then switch regions and connection types in the client for each use case.

USE CASES

Choose a Route by Use Case

The right order is to identify the target region first, choose a route type second, and then test the actual service. Looking only at route names or geographic distance can overlook account region, content licensing, and the local network path.

WEB

Everyday Browsing

For international websites, research, and everyday web services, start with a nearby Asia-Pacific endpoint. Hong Kong, Tokyo, and Singapore are often practical starting points. If pages open normally but images or files load inconsistently, compare relay and IEPL routes in the same region before switching to a more distant country.

Everyday browsing depends more on consistently responsive performance than on a single momentary test. Keep one stable primary route and retain another route type in the same region as a backup. When the access network changes, this makes it easier to tell whether the issue comes from the current path or the target website.

MEDIA

Streaming

Choose the exit region based on where the content is offered. For content available in Japan, test a Tokyo route first; for US content, try Los Angeles, San Jose, Seattle, or New York. Account region, billing region, and content licensing region may all affect the result. A route changes the network exit region but cannot replace the platform’s own account rules.

If the home page opens but the player reports a region mismatch, fully close the target app, switch to another route in the same region, and reconnect. If playback works but seeking causes repeated buffering, compare IEPL and relay routes in the same region. Do not switch accounts, clients, and routes at the same time, or it will be difficult to identify what made the difference.

AI

AI Tools

AI tools generally require a stable session and may offer different features based on the exit region. Before connecting, check which service regions the target tool supports, then use the corresponding exit. Japan, Singapore, the United States, and Europe are common starting points, but the tool’s regional policy and actual sign-in result should determine the final choice.

If the page opens but a submitted prompt fails, keep the account and browser unchanged and switch only to another route in the same region. If the sign-in state expires repeatedly, clear the target site’s old session and reconnect. For document uploads, longer generations, or extended use of a web workspace, compare IEPL and relay routes for session stability.

PLAY

Gaming Connections

For gaming, target the server region rather than the game’s publishing region. For Asia-Pacific servers, start by testing Tokyo, Seoul, or Singapore; for North American servers, choose a western or eastern US endpoint. Login, matchmaking, voice chat, and live gameplay may use different network services, so a successful login does not confirm that the entire connection is suitable.

Keep the device, access network, and game region unchanged while comparing routes one by one. If voice chat works but gameplay is unstable, switch to another route type in the same region. Cross-continent gaming is strongly affected by physical distance and game-server routing. Network acceleration can optimize the path but cannot remove every effect of geographic distance.

WORK

Remote Work

Remote desktops, video meetings, code repositories, and cloud documents require persistent sessions. First choose the region where the company service or collaboration platform is hosted, then test an IEPL or relay route. If the enterprise system restricts sign-in regions, confirm the permitted exit location before connecting and avoid switching regions repeatedly during work.

Verify work routes before an important meeting or large file sync. Test sign-in and permissions first, open real work content next, and finally confirm that a long session does not repeatedly reconnect. Windows, macOS, iOS, Android, and Linux clients are available from the user panel; one account supports unlimited devices, making it easier to keep route choices consistent across work devices.

SELECTION METHOD

Build a Reliable Route-Selection Order

You do not need to test every country repeatedly. Narrow the choice to a region first, then compare connection types within that region to reach conclusions that are easier to reproduce. The sequence below works for websites, streaming, AI tools, and work services.

  1. Confirm the Target Service Region

    Check which regions the target website, content platform, or enterprise system allows. If the service depends on the account region, keep the account settings unchanged and adjust only the network exit so an account issue is not mistaken for a route issue.

  2. Compare Routes in the Same Region

    Within the target region, compare IEPL, relay, and direct routes. Keep the device, app, and access network consistent. Change only the route each time so you can identify which path best suits the current environment.

  3. Validate with a Real Task

    For websites, open the pages you actually use. For streaming, enter the player. For AI tools, submit a normal task. For work services, complete sign-in and file synchronization. Seeing the client report a connection does not mean the target service is available.

  4. Keep a Primary and Backup Route

    After choosing a regular route, retain another connection type in the same region. If the access network or target platform changes, switch to the backup route first. This reduces unrelated setting changes and makes troubleshooting faster.

CONNECTION CHECK

Pre- and Post-Connection Checklist

Most route-selection issues can be isolated with a consistent checklist. Do not change several settings at once, and do not judge results solely by the route name.

Before Connecting

  • Confirm the region required by the target service and choose the corresponding country or city.
  • Close the target app if it is still maintaining an old session in the background, so it does not continue using the previous connection.
  • Choose one primary route first; do not change the account region or app settings at the same time.
  • For work and streaming, reserve a backup route in the same region whenever possible.
  • When you need a client, open the download page from the user panel and avoid installation files from unknown sources.

After Connecting

  • Reopen the target website or app and confirm the page region and account status.
  • Perform a real task instead of checking only the client’s connection status.
  • If the result is not as expected, switch to another route in the same region before considering a nearby region.
  • If the app retains old regional information, end the old session and establish the connection again.
  • Record the primary and backup routes that work well on the current network to reduce repeated testing.