CROSS-NODE / ROUTE REFERENCE

Global servers and routes

Coverage includes 100+ countries / 240+ routes. Choose an exit region, compare route types, then test the connection with your actual use case.

Unlimited simultaneous devices No logs 30-day money-back guarantee

This page provides static regional previews and route selection guidance, not speed rankings. Check the user panel for full route names, city labels, and currently available options.

REGION INDEX

Browse routes by region

The table below previews selected regions; it is not a complete coverage list. The “Country” column includes regional names. Cities are not inferred when they are not listed, and route types are based on the specific entries shown in the user panel.

On smaller screens, scroll the table horizontally to view route types and streaming notes.

Selected VPNXN regional routes; check the user panel for current availability
Country / region City Route type Streaming support
Asia-Pacific
Japan Check route names in the user panel IEPL Depends on the platform’s own eligibility checks
Singapore Check route names in the user panel See user panel for details Depends on the platform’s own eligibility checks
Hong Kong Check route names in the user panel See user panel for details Depends on the platform’s own eligibility checks
North America
United States Check route names in the user panel See user panel for details Depends on the platform’s own eligibility checks
Europe
Netherlands Check route names in the user panel See user panel for details Depends on the platform’s own eligibility checks
Switzerland Check route names in the user panel See user panel for details Depends on the platform’s own eligibility checks
Other regions
For specific countries, cities, and route types in other regions, check the available routes in the user panel. This page does not list unconfirmed combinations as available routes.

An exit region does not guarantee access. Streaming catalogs, AI services, and other international websites may consider your account region, payment details, exit IP, and their own policies. Connecting through a particular region does not guarantee that a service will be available.

How to read regional labels

A regional label describes the exit location; it does not, by itself, indicate entry quality or the full route. In your client, consider the region, route type, and exact route name together. The same region may use different entry points and transmission paths, while routes with different names may share some underlying infrastructure. Switching regions will not necessarily resolve congestion at the entry point, and another route in the same region may perform differently.

City names can help confirm whether a route meets a service’s location requirements, but they are not a performance guarantee. Map distance is only a starting point: actual access also depends on your local carrier, connection method, routing, and the target service’s infrastructure. For browsing without location requirements, you can start with a nearby exit. For services with location requirements, check the platform’s published rules first, then choose an appropriate exit.

PATH TOPOLOGY

Dedicated lines, transit and direct routes

Route type describes the transmission path; protocol describes how the connection is made. They are different aspects, and neither can tell you everything about performance on its own.

Entry node Transmission path Exit node Target service

IEPL

IEPL: Focus on transmission across network segments

IEPL generally refers to an international link carried over dedicated Ethernet transport resources. For users, this means that transmission across network segments uses a different resource arrangement from a typical public-internet route. It does not mean that every segment from your device to the destination website is dedicated: the path from your local network to the entry point, and from the exit point to the target service, may still use public networks. When assessing performance, distinguish the dedicated transport segment from the complete access path.

This type of route may suit tasks that benefit from a sustained connection, such as remote collaboration, long browsing sessions, and continuous playback. Transport resources and operations typically cost more, but that cost structure does not translate directly into an exclusive plan benefit or guarantee faster performance at every time of day. Check the user panel to confirm whether a specific route is IEPL; this page does not infer route access from pricing.

If a page still stalls over a dedicated route, also check your local Wi-Fi, client rules, and the target service’s status. A dedicated route can affect only part of the transmission path; it cannot fix problems with the destination website’s response or replace account-level access requirements.

RELAY

Relay routes: connecting entry and exit points

A relay route sends the connection to an entry or intermediate node first, then forwards it along a later link to the exit. This adds a forwarding step, but also allows more flexibility in choosing a path. When the public-internet route from your local network to an exit is poor, a relay may improve access by using a more suitable entry point and onward route. Whether it helps depends on entry quality, the path between segments, and the connection from the exit to the target service.

For everyday browsing, web tools, and general access, a relay route is worth considering. Its costs come from entry resources, forwarding, and transmission across network segments, so it should not be viewed simply as a cheaper substitute for a dedicated route. A relay is not automatically slow, and fewer forwarding steps do not automatically mean faster performance; assess it on your current connection.

To troubleshoot, keep the exit region the same and try another route in that region first. This makes it easier to tell whether the issue is related to the access path or how the target platform evaluates the exit region. If you change the region, client rules, and route at the same time, even an improvement will not tell you which change made the difference.

DIRECT

Direct routes: using the public internet

A direct route generally means the client connects to the exit over the public internet, without an additional relay entry point provided by the service. The path is relatively simple and typically uses fewer forwarding resources, but performance depends more on public-internet routing between your local carrier and the exit. Even nearby locations can involve detours, so “direct” does not mean the shortest path or guarantee a better response.

Direct routes are worth comparing when public-internet routing from your location is good and your tasks mainly involve light browsing. If access changes noticeably in the evening, consider shared resources and routing changes on public-network segments rather than looking only at the protocol name. Conversely, if your local network is unstable, the same issue may persist with a different route topology.

These cost differences describe how network resources are arranged; they do not indicate extra charges. Check VPNXN’s actual plan prices, available routes, and traffic rules on the Plans and Pricing page and in the user panel. For more on route topologies and protocols, see the Route and Protocol Reference.

WORKLOAD SELECTION

Choose an exit by use case

Start with the task you need to complete, then choose a region and route. Different use cases call for different criteria; you do not have to send every app through the same exit.

Everyday browsing: test the pages you use

Browsing involves many short connections and resource requests. Loading a homepage does not guarantee that images, sign-in, attachments, and other requests will work too. Start with frequently used sites that have no specific location requirements. Check page loading, images, and sign-in sessions in turn, then decide whether to keep the route. You can start with a nearby exit, but judge it by the full experience on the sites you use.

If only a few sites have issues, first check whether client rules are sending their resources over a different route. Rather than repeatedly switching regions, confirm that the main domain and its supporting resources are using the expected connection method. New users can follow the Getting Started Guide to import a subscription and run basic checks.

Streaming: check regional eligibility and playback separately

For streaming, first check the catalog available on the target platform in your chosen region and confirm that your account is eligible to watch. Reaching the platform’s homepage only confirms that some access is available; seeing a title does not guarantee that playback will work on your current connection. Test playback, seek through the video, and check that subsequent segments load instead of judging by what appears on the page.

If the catalog is correct but playback is unstable, keep the region and compare routes. If the catalog itself is not what you expected, first check your account region and the platform’s eligibility checks. Streaming availability depends on the target platform’s policies; a regional label on this page is not a guarantee that specific content will be available.

AI tools: keep the session and exit consistent

AI tools may consider service region, account status, and exit IP together. Before choosing a route, check the tool’s supported regions and usage requirements, then select an exit that fits. After signing in, try to keep the same exit for the session to avoid frequent region changes that could trigger another verification step.

When a warning appears, distinguish between a connection failure, insufficient account permissions, service load, and regional restrictions. If the site loads but the model is unavailable, the route may not be the problem. If chat works but file uploads fail, file requirements or a separate upload endpoint may be involved. For more troubleshooting guidance, see the AI Acceleration Guide.

Gaming: check whether the route can help

Games are more sensitive to consistent interaction and packet delivery. A subscription service and a gaming-focused acceleration service are designed to cover different needs, so the number of routes alone cannot tell you whether a service will suit a particular game. First check whether your client can handle the game’s connections and whether the game permits that network setup, then test it in the game itself.

When choosing an exit, consider both the game server’s region and your local connection path. A nearby location does not guarantee a shorter route, and changing protocols cannot fix local Wi-Fi interference, limited device resources, or a busy game server. For a useful comparison, keep the game region and network conditions the same to avoid unrelated variables.

Work: judge the connection across the whole session

Work involves more than opening websites; it can include joining meetings, syncing documents, using remote terminals, and transferring files. Choose an exit that meets your work location requirements, then test each step in the order you normally do it. Follow your organization’s access policies when connecting to company resources. This service cannot replace internal authorization or change account permissions on the target system.

For long sessions, keep a route you have tested and have an alternative in the same region ready. Save your work before switching, and wait for sync to finish when needed. Windows / macOS / iOS / Android / Linux are supported platforms, and simultaneous device use is unlimited. Check client rules and connection status separately on each device.

VERIFY / COMPARE / RETAIN

Connection checks and route selection

A comparison process that helps explain the results is more useful than repeatedly refreshing the route list.

Set up repeatable test conditions

Make sure your subscription is up to date and the selected route still appears in both the user panel and client, then check that your local network is working. When comparing routes, use the same device, connection method, and target task where possible. Avoid changing your Wi-Fi and exit at the same time. A connected status in the client is only an indication of connection state; also verify that the task works in the target app.

When taking notes, include the region, full route name, target service, and what happened. For example, distinguish “page won’t load,” “error after sign-in,” and “file upload stalls.” This is more useful for troubleshooting than simply saying “the connection is bad.” Your subscription link is an account credential; do not include it in public screenshots or discussions.

Separate isolated issues from general ones

If several services are having issues, start by checking your local connection, client status, and subscription validity. If only one service is affected, check its account requirements, regional eligibility checks, and service status first. Changes in evening performance may also reflect shared network resources; they cannot be attributed to the exit country alone.

For help, submit a ticket through the user panel and include the platform, route name, what you were doing, and the adjustments you have tried. Leave out your password and full subscription link. Check the Help Center for common questions, or go to the Support Ticket Portal for further assistance.