REGIONS / DIRECTORY
Example Regions and Routes
This table shows how regions, cities, and route types relate; it is not a complete list of currently available routes. Check the account panel and your updated subscription for available regions, protocols, and route groups. Examples do not guarantee that a specific city will always be available.
Streaming results depend on platform rules, account region, content licensing, and how the exit location is detected. Every entry is marked “Availability depends on the actual connection”; no region or route type guarantees access to a particular catalog.
On narrow screens, swipe horizontally across the table to view cities, route types, and streaming notes.
| Country / Region | City | Route Type | Streaming Availability |
|---|---|---|---|
| Asia-Pacific | |||
| Japan | Tokyo | IEPL | Depends on the actual connection |
| Japan | Osaka | Relay | Depends on the actual connection |
| Singapore | Singapore | IEPL | Depends on the actual connection |
| Hong Kong | Hong Kong | IEPL | Depends on the actual connection |
| South Korea | Seoul | Relay | Depends on the actual connection |
| Australia | Sydney | Direct | Depends on the actual connection |
| North America | |||
| United States | Los Angeles | IEPL | Depends on the actual connection |
| United States | San Jose | Relay | Depends on the actual connection |
| United States | Seattle | Direct | Depends on the actual connection |
| United States | New York | Relay | Depends on the actual connection |
| Canada | Vancouver | Relay | Depends on the actual connection |
| Canada | Toronto | Direct | Depends on the actual connection |
| Europe | |||
| United Kingdom | London | IEPL | Depends on the actual connection |
| France | Paris | Relay | Depends on the actual connection |
| Germany | Frankfurt | IEPL | Depends on the actual connection |
| Netherlands | Amsterdam | Relay | Depends on the actual connection |
| Switzerland | Zurich | Direct | Depends on the actual connection |
| Sweden | Stockholm | Direct | Depends on the actual connection |
| Other Regions | |||
| Brazil | São Paulo | Relay | Depends on the actual connection |
| Chile | Santiago | Direct | Depends on the actual connection |
| South Africa | Johannesburg | Relay | Depends on the actual connection |
| United Arab Emirates | Dubai | Relay | Depends on the actual connection |
| Türkiye | Istanbul | Direct | Depends on the actual connection |
| India | Mumbai | Relay | Depends on the actual connection |
The Same City Doesn't Mean the Same Route
A single exit city can use different entry points, transport paths, and protocols. Even when choosing a Tokyo route, check whether it uses a dedicated link, a relay, or a direct public-internet connection. The city label alone can't tell you what the connection will be like. Conversely, a geographically closer exit may not have the more suitable network path. Choose a region based on the service you need, then compare routes within that region; this is usually more useful than switching between regions repeatedly.
The table doesn't show live performance metrics or rank regions. Your connection depends on your local network, time of day, carrier routing, and the destination service. Judge a route by whether your apps can complete the tasks you need—not by the place name or route label.
TOPOLOGY / ROUTE GUIDE
Dedicated Links, Relays, and Direct Connections
Route type describes the network topology; protocol describes how the client transmits data. They are separate dimensions: changing protocols doesn't change the route, and changing the route doesn't necessarily change the exit region.
Illustrative paths · Not actual routing records
- IEPL
- Client → Entry → Dedicated link → Exit
- Relay
- Client → Relay entry → Exit
- Direct
- Client → Public internet → Exit
These diagrams explain the structure only. The destination service is beyond the exit, and your local connection also affects performance.
IEPL: Focus on the Cross-Region Transport Segment
IEPL generally refers to an international Ethernet private line. With this type of route, a dedicated link carries a particular cross-region transport segment, reducing reliance on changes in ordinary public-internet routing. Its value lies in greater control over that segment—not in a guaranteed speed implied by the name. Your local network between the client and entry point, and the route from the exit to the destination website, still affect the full connection. A dedicated link doesn't replace troubleshooting your local network.
From a network deployment and procurement perspective, dedicated links typically involve the cost of dedicated connectivity and access resources, as well as maintenance needs that differ from ordinary public-internet connections. If you rely on long video calls, extended transfers, or performance during peak hours, compare dedicated-link options in the same region first. This cost difference explains the technology; it does not mean VPNWhen charges extra by route type. Check the account panel for current availability.
Relay: Adjust the Route Beyond the Entry Point
A relay route first sends data to an entry point, which then forwards it to the exit. The extra entry point is intended to make use of different network interconnections—not to add steps for their own sake. Results depend on the entry point, its connection to the exit, and the exit's status. A suitable relay may be more stable than a direct public-internet route, but congestion at the entry point or a detour can make it a poor fit for your network.
Relays typically require additional forwarding servers, bandwidth, and maintenance, so their cost structure differs from a simple direct connection. For everyday browsing, streaming, and office work, use a relay as a comparison option within the same region. When switching, keep the exit region unchanged and compare page loads, playback continuity, or call quality before deciding which route to keep. Changing too many variables at once makes the results harder to interpret.
Direct: A Simpler Path That Depends on the Public Internet
A direct route connects the client to the exit over the public internet, without an additional service-side relay entry point. “Direct” describes the topology; it doesn't mean the physical distance is shortest or that no carrier equipment is involved. Public-internet interconnections, routing changes, and congestion all affect performance. If your local network has a good connection to the exit, a direct route can be a straightforward, easy-to-understand option.
Direct connections skip some service-side forwarding, but still require exit resources and public-internet bandwidth; they are not free of operating costs. If performance changes at certain times, compare a relay or dedicated link in the same region. Don't assume a more complex route is automatically better, or infer compatibility or privacy from the “Direct” label alone.
VPNWhen's security message centers on military-grade encryption. Encryption, route topology, and website account security each serve different purposes. Keep your password and subscription link secure, and follow the destination website's access rules.
For a closer look at the trade-offs between Shadowsocks, VMess, Trojan, VLESS, and Hysteria2, read our protocol guide. A protocol name alone doesn't confirm regional availability. Choose based on what your current client can import correctly and what the account panel actually offers.
INTENT / CHOOSE BY TASK
Choose a Cross-Border Route by Use Case
Separate “the website opens” from “the task works.” Start by checking any region requirements, then test how the app performs. If no particular region is required, there's no need to keep changing exit locations.
Check that pages and assets load fully
For reading international websites, researching, or accessing developer documentation, start with a region that performs reliably on your local network. If the page opens but images, attachments, or the login screen fail, different page resources may be following different rules; the exit city may not be the cause. First check the client connection and app routing rules, then compare another route in the same region.
Once you've chosen a regular route, keep a backup option. A backup with a different entry point or route type gives you a more useful comparison when network paths change. Saving routes with similar names may not help with the same network issue.
Match the catalog region, then test playback
First check that the platform account, content catalog, and exit region match. Reaching the home page doesn't mean a specific title will play, and an IEPL route doesn't guarantee support for a particular platform. Open the content you want to watch and check that playback, seeking, and extended viewing work before deciding whether to keep the route.
If the site loads but a title shows a region error, check the platform's account and content rules first. If playback keeps buffering, compare routes within the same region and check your local Wi-Fi and other downloads. Switching routes can't replace a platform subscription or guarantee that all content will always be available.
Consider service regions and session continuity
Each AI tool's supported regions, account eligibility, and access policies are determined by its platform. Check the platform's official guidance first, then choose a suitable region. A successful connection only means the network path is established; it doesn't change account permissions, payment eligibility, or feature availability. An exit label is not a guarantee of account approval.
For long-form generation, file uploads, and extended conversations, check that sessions complete reliably. Keep the same exit region while signing in or uploading, and avoid switching locations without a reason. If something is interrupted, first distinguish a service error or account notice from a connection problem, then compare other routes in the same region to avoid repeating steps unnecessarily.
Choose based on the game server's region
Use the game server you actually connect to as your reference, rather than choosing the nearest city in a client list. The lobby, login, and gameplay may use different network paths; a working website doesn't mean the route is suitable for a match. Test with the same server region and local network conditions, and check login, matchmaking, gameplay, and voice chat.
A general subscription service isn't a dedicated accelerator optimized for every game. Some game clients may not follow the system proxy; compatibility depends on the client, app rules, and game terms. If only one game is affected, first check whether the client is routing its traffic before changing routes.
Prioritize a stable exit and your organization's policies
For work, follow your organization's access and data-handling requirements first. Business logins, document collaboration, and video meetings may be sensitive to region changes; keep the route consistent once a meeting starts, a form is submitted, or a file transfer begins. If you also use a corporate networking client, check how the two are routed to avoid conflicts.
Windows / macOS / iOS / Android / Linux are supported platforms, with unlimited simultaneous devices. However, network conditions and client settings differ by device, so a successful connection on a computer doesn't verify other devices. Test each app you'll need before an important task, and keep a backup route in the same region.
CHECK / AFTER CONNECTING
Connection Checks and Route Updates
When troubleshooting, change just one variable at a time. Keep the affected app, exit region, and symptoms constant while checking the client, route, and destination service step by step. This is usually more helpful than switching routes at random.
Check Your Subscription
Get your subscription from the account panel, then import and update it according to your client's instructions. If a region shown in these examples isn't in your list, don't guess the server address. Update the subscription first, then check what's actually available in the panel. Your subscription link is an account credential; don't post it in public discussions or screenshots.
Check the App
Confirm that the target app is using the intended connection rule. A browser working doesn't mean other apps use the same route. If only one app is affected, check its rules and error message first, then test a backup route in the same region. This helps avoid mistaking an app permission issue for a route failure.
Record What Happened
When reporting an issue, include your platform, client message, route name, and the situation in which it occurred. Describe what happened—for example, “Login succeeded, but the upload stopped” or “The home page loads, but the show won't play.” Don't include your password or full subscription link. Clear symptoms are more useful for troubleshooting than simply saying “the connection is bad.”