Route table
How to read the route table
The table below groups samples by Asia Pacific, North America, Europe and other regions. Each row lists country / region, city, route type and streaming support; the full list expands by region in the app, with 110+ countries / 250+ routes in total. The number of sample rows is not the total route count — cities not shown here are also available in the app.
“Supported” means the exit usually works with major streaming platforms; “partial” means playback depends on the platform, the account region and the rights policy at the time. If your account region and payment region differ, you may only see the library for your account region even when the exit works. Before choosing, confirm the country of the target service, then compare route types within that country.
This page lists no connection quality, route load or rolling numbers. Those values change with your local network, time of day, device and target service, so a hard-coded figure on a static page would tell you nothing; the app reports real route status when you connect. To judge whether a route suits your case, narrow it down in the order target country → city → route type.
The cities in the table are samples, not the full route list; confirm the country of the target service first, then compare route types within that country.
- Asia Pacific
- North America
- Europe
- Middle East
- South America
- Africa
- Oceania
Region 01
Asia Pacific routes
Asia Pacific routes are the main entry point for users in the region reaching international sites, streaming services and AI tools. Tokyo, Hong Kong and Singapore run IEPL dedicated lines, a good fit for peak-hour work, long meetings and HD streaming; Osaka, Seoul and Taipei are mostly relay, useful as backup exits; Sydney, Melbourne, Kuala Lumpur, Bangkok, Jakarta and Manila are mostly direct, suited to local business and regional content.
| Country / region | City | Route type | Streaming |
|---|---|---|---|
| Japan | Tokyo | IEPL | Supported |
| Japan | Osaka | Relay | Supported |
| Hong Kong | Hong Kong | IEPL | Supported |
| Singapore | Singapore | IEPL | Supported |
| South Korea | Seoul | Relay | Supported |
| Taiwan | Taipei | Relay | Supported |
| Australia | Sydney | Relay | Supported |
| Australia | Melbourne | Direct | Partial |
| Malaysia | Kuala Lumpur | Direct | Supported |
| Thailand | Bangkok | Direct | Partial |
| Indonesia | Jakarta | Direct | Partial |
| Philippines | Manila | Direct | Partial |
Sample routes · full list in the app
Region 02
North America routes
North America routes cover Los Angeles, San Jose, New York, Seattle and major Canadian cities. Los Angeles and San Jose are the usual exits for US streaming, AI tools and cloud services; New York suits business aimed at the US East Coast; Seattle and Vancouver sit close to Asia Pacific and work well as extra exits for trans-Pacific work. Mexico City is mostly direct, suited to Mexican local services.
| Country / region | City | Route type | Streaming |
|---|---|---|---|
| United States | Los Angeles | IEPL | Supported |
| United States | San Jose | Relay | Supported |
| United States | New York | Relay | Supported |
| United States | Seattle | Direct | Supported |
| Canada | Toronto | Relay | Supported |
| Canada | Vancouver | Direct | Supported |
| Mexico | Mexico City | Direct | Partial |
Sample routes · full list in the app
Region 03
Europe routes
Europe routes cover London, Frankfurt, Paris, Amsterdam, Zurich, Stockholm, Madrid and Milan. London Amsterdam run IEPL dedicated lines, suited to UK and Dutch streaming, cloud services and cross-border work; Frankfurt, Paris and Zurich are mostly relay, suited to everyday access on the continent; northern and southern Europe are mostly direct, suited to regional content and local business.
| Country / region | City | Route type | Streaming |
|---|---|---|---|
| United Kingdom | London | IEPL | Supported |
| Germany | Frankfurt | Relay | Supported |
| France | Paris | Relay | Supported |
| Netherlands | Amsterdam | IEPL | Supported |
| Switzerland | Zurich | Relay | Supported |
| Sweden | Stockholm | Direct | Partial |
| Spain | Madrid | Direct | Partial |
| Italy | Milan | Direct | Partial |
Sample routes · full list in the app
Region 04
Routes in other regions
Other regions cover representative cities in the Middle East, South America and Africa. Dubai, São Paulo and Tel Aviv are mostly relay, suited to local services and regional content; Istanbul, Buenos Aires and Johannesburg are mostly direct, suited to local business and backup routes. If a platform is only offered in a specific country, choose that country's exit first and make sure your account region matches your payment region.
| Country / region | City | Route type | Streaming |
|---|---|---|---|
| United Arab Emirates | Dubai | Relay | Partial |
| Turkey | Istanbul | Direct | Partial |
| Brazil | São Paulo | Relay | Partial |
| Argentina | Buenos Aires | Direct | Partial |
| South Africa | Johannesburg | Direct | Partial |
| Israel | Tel Aviv | Relay | Partial |
Sample routes · full list in the app
Route type
Three route types
Route type decides the path, not everything. A city may offer IEPL, relay and direct at the same time, or only one of them; pick by target country first, then city, then type. The three types below are described by path, best-fit scenarios and cost.
IEPL dedicated line
IEPL is an international Ethernet private line: after local access, traffic reaches the overseas exit over a dedicated channel rather than the congested middle sections of the public internet. Its value is not a vague “faster” but a controllable path: at peak hours, public peering fluctuates more than a private line, and a private line suits sessions that must stay connected for a long time.
Best for peak-hour work, video meetings across time zones, HD streaming and tasks that need a stable long connection. It costs more than relay and direct, so it is usually deployed at core exits such as Tokyo, Hong Kong, Singapore, Los Angeles, London and Amsterdam; not every city has one, so check the city first, then the type.
Best for: peak-hour work · long meetings · HD streaming
Relay
A relay route first sends traffic to an optimised relay node, which forwards it to the target exit. It adds one hop, but that hop usually lands in a data centre with good peering, avoiding some public internet bottlenecks. Relay performance depends on whether the relay city matches the exit city: for US services, the relay node should have good trans-Pacific connectivity.
Best for everyday browsing, streaming, AI tools and cost-sensitive long connections. It costs less than a private line and more than direct, covers more cities than IEPL, and is the default for most scenarios. If peak hours bring noticeable fluctuation, switch to the IEPL line in the same country.
Best for: everyday browsing · streaming · AI tools
Direct
A direct route connects the client straight to the overseas exit: shortest path, simple scheduling, lowest cost. Its strength is a clear target — for a country's local services, that country's exit is often better than routing through a third country. The downside is more public peering segments, so peak-hour fluctuation can be more visible than on IEPL or relay.
Best for a specific country's local services, regional streaming, light browsing and backup routes. Large downloads can also start with direct, but if the platform is sensitive to exit quality, keep a relay or IEPL route as a fallback.
Best for: regional services · light browsing · backup
| Route type | Path | Best for | Cost |
|---|---|---|---|
| IEPL | Dedicated channel to the overseas exit, controllable path | Peak-hour work, long meetings, HD streaming | Higher, stability first |
| Relay | Forwarded through an optimised node, one extra hop | Everyday browsing, streaming, AI tools | Moderate, balances coverage and cost |
| Direct | Direct connection to the overseas exit, shortest path | Regional services, light browsing, backup | Lower, good for large downloads |
How to choose
Pick a route by use case
Narrow the range by the country of the target service first, then compare cities and route types within that country. The five common use cases below are listed in order of preference; the regions shown are common entry points, not the only ones.
| Use case | Usual regions | Alternatives | Route type |
|---|---|---|---|
| US streaming | Los Angeles / San Jose | Seattle / New York | IEPL / relay |
| Japan streaming | Tokyo | Osaka | IEPL / relay |
| UK streaming | London | Amsterdam | IEPL / relay |
| AI tools | Los Angeles / San Jose / Tokyo | Singapore / Frankfurt | Relay / IEPL |
| Trans-Pacific work | Tokyo / Los Angeles | Seattle / Vancouver | IEPL / relay |
| European local services | Frankfurt / Paris | Amsterdam / Zurich | Relay / IEPL |
Everyday browsing
Prefer relay, then direct. Everyday browsing means many requests but short connections; relay covers more cities and is cheap to switch. If pages slow down noticeably at peak hours, switch to the IEPL line in the same country. Don't go by city name alone — different route types in the same city can behave differently.
RelayDirect
HD streaming
For HD streaming, prefer IEPL and keep relay as backup. A working exit is only the first step; platforms also check account region and payment region. If the player opens but the library is wrong, confirm the account region first, then try another city in the same country. Cities marked partial are fine for content already licensed in that region, but not as your only exit.
IEPLRelay
AI tools
AI tools mostly use long connections and streaming responses, so prefer relay or IEPL. Switching routes often can trigger a fresh login; if you hit a login loop, stay on one route in one country, then clear the session or try another browser. For large uploads, direct can be a useful addition.
RelayIEPL
Gaming
For gaming, pick the exit closest to the game server first, then compare route types. IEPL has a controllable path and suits matches sensitive to fluctuation; relay adds a hop and may not suit competitive play; direct has the shortest path but public peering fluctuates more at peak hours. Choose the country of the target server first, then test cities within that country.
IEPLDirect
Cross-border work
For cross-border work, prefer IEPL and keep a relay route as backup. Video meetings, code repositories and cloud documents are sensitive to long connections, and switching routes interrupts sessions; pin your usual route in the app and switch only when travelling or when your local network changes. When you need several devices online at once, this service does not limit the number of devices.
IEPLRelay
Notes
Notes
The route table is static reference material; actual connection quality depends on your local network, time of day, device and target service. The points below are the usual order for choosing a route and troubleshooting.
After connecting, open the target service first, then check account region and payment region; if the page opens but the content is wrong, try another city in the same country; if nothing connects at all, switch route type first, then check the client version and subscription status. For full steps, see the quick start guide.