International Route Directory

International Route Coverage

Start with your destination region, then choose a route type. VPNGain covers 110+ countries and 240+ routes. This page lists sample regions and cities to help you compare exit locations, connection paths and app requirements.

No email address required. Get started with a username and password. For currently available routes, maintenance notices and subscription status, check the client and user panel after signing in.

Start Free View Plans

Browse Routes by Region

The table groups routes by exit region. City names indicate the route’s exit location; they do not mean your local network connects directly to that city or that the destination website’s server is nearby. Routes in the same city may use different connection paths. Compare the city, route type and actual results rather than ranking routes by distance alone.

These are static route examples, not a complete directory or confirmation of current availability. Streaming support is marked as requiring testing: results can vary by platform, account region and content catalog, so a region name alone cannot tell you whether playback will work.

Sample regions, cities and route types; see the client for the current list
Country / Region City Route Type Streaming Support
Asia-Pacific
JapanTokyoIEPLTest on the target platform
Hong KongHong KongIEPLTest on the target platform
SingaporeSingaporeRelayTest on the target platform
JapanOsakaRelayTest on the target platform
South KoreaSeoulDirectTest on the target platform
TaiwanTaipeiRelayTest on the target platform
North America
United StatesLos AngelesDirectTest on the target platform
United StatesSan FranciscoRelayTest on the target platform
United StatesNew YorkRelayTest on the target platform
CanadaTorontoDirectTest on the target platform
Europe
GermanyFrankfurtRelayTest on the target platform
United KingdomLondonRelayTest on the target platform
FranceParisDirectTest on the target platform
NetherlandsAmsterdamRelayTest on the target platform
SwitzerlandZurichDirectTest on the target platform
SwedenStockholmRelayTest on the target platform
Other Regions
AustraliaSydneyRelayTest on the target platform
AustraliaMelbourneDirectTest on the target platform
United Arab EmiratesDubaiRelayTest on the target platform
BrazilSão PauloDirectTest on the target platform

Dedicated, Relay and Direct Routes: What’s the Difference?

Route types describe how a connection path is arranged; they are not a speed ranking. They cannot replace testing with your apps or determine whether you’re permitted to use an exit address. Consider your local connection, the cross-border segment and the destination service together.

IEPL

IEPL: A More Controlled Cross-Border Path

IEPL generally refers to an international Ethernet private line. Unlike routes that rely entirely on public internet routing across borders, an IEPL route uses dedicated transmission resources for the cross-border segment to reduce uncertainty caused by changes in public routing. An IEPL label in the client describes how the route is arranged; it does not mean each user has an entire physical link to themselves.

If you often see web pages stall, calls break up or remote sessions reconnect in the evening, an IEPL route may be worth comparing. Test it with the apps you actually need and see how they perform over time. Even with a dedicated cross-border segment, your local Wi-Fi, access connection and remote service can affect results, so performance cannot be guaranteed across all network environments.

Dedicated routes typically involve higher leasing and maintenance costs for network resources. However, a provider’s operating costs do not mean users face an extra charge. See the Plans page for pricing; this page does not infer additional fees from route type.

RELAY

Relay Routes: Connections via an Intermediate Node

A relay route sends your connection to an intermediate node before forwarding it to the exit. An extra hop does not necessarily make a connection slower: if your connection to the relay is smooth and the onward path is better suited to your destination, the app may perform better than on a direct route with significant detours. On the other hand, a relay that is a poor fit for your local carrier can become a weak point.

Try a relay route when you need an exit in a specific region but a direct connection is not working well. Everyday browsing, downloads and remote work can all serve as test cases. Comparing relay and direct routes in the same region helps you assess exit location and path separately, rather than changing both at once and making the cause harder to identify.

Relay costs cover the entry point, intermediate forwarding and exit maintenance, depending on how the path is arranged. It is not always cheaper than a dedicated route or more expensive than a direct one. Focus on repeatable performance at the times you use it and whether the route suits your actual destination, not just whether its name includes “relay.”

DIRECT

Direct Routes: Connect Straight to the Exit

A direct route generally means the client connects to the remote exit over the public internet, without a relay node specifically set up by the service. “Direct” does not mean there are no carrier routers along the way or that the geographic path is the shortest. Internet peering, carrier routing and connectivity at the destination data center all affect the final experience.

When your local network has a good connection to the destination region, a direct route can work well for everyday browsing and light office tasks. Its simpler path can also make troubleshooting easier: if performance changes when you switch to another access network on the same device, check the local connection or carrier route before blaming the app.

Direct routes do not require dedicated relay resources, but exit bandwidth and maintenance still cost money. Direct does not automatically mean cheaper or lower quality. Choose based on how the route performs with your target app. If the connection drops frequently, compare other route types in the same region instead of repeatedly switching between similar names.

Choose a Cross-Border Route by Use Case

First identify your destination and any regional requirements, then consider the route type. If you have no region requirement, start by comparing nearby exits. If an account region or company access policy applies, meet those requirements first. These suggestions are a testing sequence, not a guarantee that any particular app will be accessible.

Everyday Browsing

When browsing international websites, check that the main content, images and internal links all load—not just the home page. Try a nearby region first, then compare route types in the same region. Search, documents and images may come from different domains. If only some content fails to load, check whether your client’s routing rules cover those resources.

Once you find a route that works for you, keep it and a backup as regular options rather than starting your search over every time you open the client. If something goes wrong, check whether the website itself is having issues before switching routes; a temporary site outage does not mean all connections are unavailable.

Streaming and Video

Check the target content catalog and your account region first, then choose a matching exit. Platforms may determine content access based on your exit address, account details, subscription eligibility and device status. Being able to open a website on a route does not guarantee that a particular title will play. The “test on the target platform” note in the table cannot replace checking the specific title.

Test on the actual playback page. Check whether you can change video quality, seek and keep playback running. Switching regions repeatedly during playback may trigger extra verification and make results harder to assess. For more platform guidance, see Streaming Access. This service does not guarantee access to every regional catalog or platform at all times.

AI Tools and Coding

AI tools often use web sign-in, API requests and continuous output. Being able to open the sign-in page does not mean persistent connections or command-line requests are working. Choose an exit that meets the target service’s regional requirements, then test sign-in, chat and actual tool calls on that same exit. Avoid frequent region changes, which can trigger verification and complicate testing.

When using Cursor, Copilot or command-line tools, check whether the app uses your system proxy settings. Some terminal processes need to be configured separately; a working browser connection does not prove that terminal traffic follows the same path. A network route also does not replace the tool’s account eligibility, paid access or terms of service.

Gaming

Gaming depends on a stable connection during continuous interaction. Check the game server’s region first instead of trying countries one by one from the client list. Login, updates, matchmaking and gameplay may use different connections, so a smooth download does not predict how a match will perform.

Check whether the game’s rules allow proxy use, then test actual matches in compliance with those rules. Avoid running multiple large downloads during updates, as they can compete for shared access resources and skew your results. This service is a cross-border connectivity subscription, not a dedicated solution optimized for every game, and it does not promise to change matchmaking results.

Work and Remote Collaboration

Follow your organization’s access rules first. Remote desktops, file sync and video calls have different continuity requirements, so test each one separately when choosing a route. If your organization requires a fixed source address or an approved access method, check with your administrator first; a regular regional exit does not automatically meet an IP allowlist requirement.

VPNGain supports Windows, macOS, iOS, Android and Linux, with unlimited simultaneous devices. Devices using the same subscription share its plan allowance, so keep background sync and system updates in mind. Check your connection before important meetings and, where possible, keep the same exit throughout to avoid disrupting the session.

Connection Checks and Troubleshooting

Get the client from the user panel, then sign in to retrieve your subscription. After importing it, confirm the client is connected and test with the app you need. On platforms other than iOS, sign in to download the client; the user panel handles iOS download eligibility. Do not use an old configuration from an unverified source in place of the subscription in your panel.

When comparing routes, keep the device, access network and destination service the same, and change only the route. Record the exit region, route type, time of the issue and steps to reproduce it; this is more useful than a general report that “the internet is slow.” If a browser works but an app does not, check the app’s proxy path, permissions and account status before deciding whether to change exits.

If performance changes in the evening, compare other paths in the same region. Before switching, pause background transfers and make sure your local Wi-Fi signal is stable. If route names change after updating your subscription, use the names currently shown in the client; do not mix old directory entries with new routes. For a more complete troubleshooting process, see Troubleshooting.

For help from customer support, submit a support ticket through the user panel. Include your operating system, client message, route name, target app and the checks you have already tried. Before sharing a screenshot, hide your account password, subscription URL and other access credentials. Do not send your full subscription details or publish logs containing private conversations.

Start Free