ROUTE DIRECTORY
Regional routes directory
The table shows selectable regions, cities, and route types; it does not display latency, load, or real-time bandwidth. Actual available endpoints are listed after login.
| Country / region | City | Route type | Streaming |
|---|---|---|---|
| Asia-Pacific routes | |||
| Hong Kong, China | Hong Kong | IEPL | Supported |
| Japan | Tokyo | Transit | Supported |
| Japan | Osaka | Direct | General access |
| Singapore | Singapore | IEPL | Supported |
| South Korea | Seoul | Transit | Supported |
| Australia | Sydney | Direct | General access |
| North America routes | |||
| United States | Los Angeles | IEPL | Supported |
| United States | San Jose | Transit | Supported |
| United States | Seattle | Direct | General access |
| United States | New York | Transit | Supported |
| Canada | Toronto | Direct | General access |
| Canada | Vancouver | Transit | Supported |
| European routes | |||
| United Kingdom | London | IEPL | Supported |
| Germany | Frankfurt | Transit | Supported |
| France | Paris | Direct | Supported |
| Netherlands | Amsterdam | Transit | Supported |
| Sweden | Stockholm | Direct | General access |
| Italy | Milan | Direct | General access |
| Routes in other regions | |||
| United Arab Emirates | Dubai | Transit | Supported |
| India | Mumbai | Direct | General access |
| Brazil | São Paulo | Transit | Supported |
| South Africa | Johannesburg | Direct | General access |
| Turkey | Istanbul | Transit | Supported |
| New Zealand | Auckland | Direct | General access |
Region does not determine use case. The same city may offer multiple endpoint types. The city determines the exit location and the region seen by the target service, while the route type determines how the international link is organized. Consider region, type, and actual use together rather than choosing by place name alone.
Streaming support does not guarantee a fixed content library. Platforms return results based on the account, region, licensing arrangements, and exit network conditions. For streaming, start with endpoints marked “Supported” in the table; if the library differs from expectations, try another route type in the same region.
ROUTE TYPES
Route types and cost differences
IEPL, transit, and direct routes are not a simple ranking. They use different link structures, suit different tasks, and carry different resource costs.
IEPL
IEPL routes place the international segment on a relatively independent transport link, reducing the impact of changes across public network paths. The goal is not a peak result in a single test, but a more consistent connection for long sessions, sustained uploads, remote collaboration, and high-bitrate content. For users who regularly access overseas work systems, attend online meetings, sync code repositories, or handle large files, IEPL generally makes connection fluctuations easier to control.
Dedicated route resources usually cost more to access and maintain than standard routes, making them better suited to tasks that demand continuity. If you only browse occasionally, look up information, or handle lightweight messages, there is no need to stay on IEPL. Use IEPL for demanding tasks and transit or direct routes for general access to make better use of subscription traffic.
Transit routes
Transit routes send a connection to a nearby access point first, then forward it through an intermediate node to the target region. Their value lies in reorganizing the international path and reducing uncertainty between the local carrier and a distant data center. Compared with a direct connection to a remote server, transit can balance regional coverage, access stability, and resource cost, making it suitable for everyday browsing, browser-based AI tools, code platforms, and common streaming use.
Transit performance depends on the access region, exit region, and network path at the time. For a target service in North America, start with a North American transit route; for services focused on Japan or Singapore, begin with an Asia-Pacific transit route. If a page opens but resources fail to load completely, try another transit endpoint in the same region instead of immediately switching to a more distant region.
Direct routes
Direct routes connect the local network straight to a server in the target region, with fewer intermediate steps and a simpler structure that is easier to expand geographically. They suit web searches, email, downloads, and tasks with less demanding continuity requirements. In nearby regions where the network path is already smooth, direct routes can also provide a straightforward and effective connection.
Direct routes rely more heavily on the public network path between the local carrier and the target data center. When the path changes or the international exit is busy, performance may fluctuate more than with transit or IEPL. If pages load intermittently, video quality changes frequently, or long connections drop, switch first to a transit route in the same region; for ongoing meetings, remote desktops, or lengthy uploads, consider IEPL.
Do not treat route labels as a single speed ranking
Route names describe network paths and access methods, not a fixed speed result. Actual performance also depends on the local network, access time, target service region, application connection method, and content size. Compare routes by keeping the same target service, device, and local network, then checking whether pages load fully, sessions remain continuous, and video quality changes frequently. A brief test only reflects conditions at that moment; it cannot replace testing with real tasks.
Cost differences do not mean every task should use the more expensive route. IEPL concentrates resources on a stable link, transit focuses on path optimization and coverage balance, while direct routes emphasize simple structure and regional reachability. Assigning routes by task is usually more effective than keeping one endpoint fixed.
TASK MATCHING
Choose recommended routes by use case
Keep the selection order consistent: identify the target service region first, decide whether the task needs a sustained connection, then compare route types within the same region.
Everyday browsing
For research, news, code documentation, or routine web pages, start with a nearby transit route. A shorter distance often means a shorter path, while transit can reduce uncertainty across parts of the public network. If the content clearly belongs to a specific region, switch to an exit in that region.
Everyday browsing does not require long-term use of IEPL. If pages load completely, login sessions remain stable, and images and scripts return normally, the current route meets the task. If only one website behaves unexpectedly, try another endpoint in the same region before assuming the entire route is at fault.
Streaming
For streaming, first choose an exit in the region of the content you want to access, then start with a route marked “Supported” in the table. Short videos and ordinary web pages may buffer quickly, but long-form video depends more on sustained transfer. Playback starting does not guarantee stable quality, so watch for frequent quality drops or rebuffering during continuous playback.
If the same region offers both IEPL and transit, try IEPL first for high-bitrate content and transit first for standard content. If the content library is unexpected, change the exit within the same region rather than clearing account data or repeatedly changing client settings. Platform content may also depend on the account region and licensing arrangements; the route is only one factor.
AI Tools
When using browser-based AI tools, prioritize continuity for login sessions, long responses, and file uploads. Start with a transit route near the service’s primary operating region; for lengthy conversations, document uploads, or developer APIs, switch to the more stable IEPL route. Frequent changes between exit regions may trigger the service’s own security checks, so keep the region consistent once selected.
If a page opens but the response stops midway, check the local network, browser session, and route type separately. Change the route within the same region first, then confirm whether other websites work normally; this helps distinguish a single-service issue from a link issue. For development tasks, also watch request timeouts and concurrent connection behavior rather than only the page’s initial load speed.
Online gaming
Choose a gaming route by matching the game server region, not by picking an apparently closer exit in a different service region. Before entering a game, check the account region and server location, then choose a transit route in the same or a nearby region. For games that require sustained sessions, compare the stability of transit and IEPL during a complete match.
Game downloads, login verification, voice chat, and live matches may use different network services. A normal download speed does not mean the match connection will be equally suitable. Judge performance during actual gameplay, and pause large sync tasks that consume the connection. If the issue affects only one server region, switch to the corresponding regional endpoint rather than changing every device configuration.
Remote work
Remote desktops, online meetings, enterprise consoles, code repositories, and large-file sync all depend more on connection continuity. First choose an exit in the region of the enterprise service or collaboration platform, then prefer IEPL. If the task mainly involves reading documents and sending email, transit is usually sufficient; reserve IEPL for meetings, uploads, and remote operations.
Avoid frequently changing regions during work, as enterprise systems may treat an exit-region change as a new login environment. Confirm the route before starting and adjust it after the task ends. When a connection problem occurs, record the platform, route region, route type, and symptoms, then submit a ticket through the user panel to reduce repeated troubleshooting.
COVERAGE NOTES
How to understand global coverage
120+ countries / 170+ routes describes the overall range of available exit locations. The city directory highlights common endpoints and does not reproduce every route in the panel.
This helps match the access region required by websites, content platforms, enterprise services, and applications. Choosing an exit near the target service is generally easier for troubleshooting than switching randomly between distant regions.
A single region can offer multiple route types, allowing you to switch between IEPL, transit, and direct connections. The route count provides regional and path options; it does not mean every route must be tested.
Supports Windows / macOS / iOS / Android / Linux. After login, get the client and subscription from the user panel, then choose the appropriate region for each device’s purpose.
Build your own route-selection rules
Keeping a few reliable combinations for common tasks is more efficient than choosing again from the full directory each time. For everyday browsing, keep one nearby transit route; for streaming, keep a route in the content region; for work and sustained sessions, keep an IEPL route in the relevant region; use direct routes for general access or as backups.
Change one variable at a time when switching routes. For example, hold the region constant while comparing route types, then hold the type constant while comparing nearby regions. If you change the region, client, and local network together, it is difficult to know what caused the improvement. Systematic troubleshooting depends on reducing variables, not cycling through many endpoints.
No email address is required to create an account; a username and password are enough. Plans support unlimited devices and include a 30-day money-back guarantee. For monthly subscriptions and traffic bundles, visit the plans page to review the complete rules.