Coverage: 90+ countries / 200+ routes. Start with the region where your target service is hosted, then choose an IEPL, relay or direct route for your use case. The list shows static route details only and does not turn short-term network changes into fixed claims.
A route name only describes its entry point, exit point and routing category; it cannot replace real-world testing. Browsing, extended video playback, AI streaming output and connecting to workplace systems place different demands on a connection. The right order is to identify the target region, choose the route type, then verify performance in your own network environment.
Best for services hosted in East Asia, Southeast Asia and Oceania. Physical distances are often shorter, making these routes a practical first choice for everyday browsing, collaboration tools and persistent connections.
Tokyo · Hong Kong · SingaporeFor websites, AI tools, developer platforms and media services in the United States and Canada. Choose a western or eastern entry point based on where the target service is actually hosted.
Los Angeles · Seattle · New YorkIncludes commonly used locations in the United Kingdom, Germany, France and the Netherlands. For cross-region work or European local content, choose an exit in the same region as your business system.
London · Frankfurt · ParisFor targets in the Middle East, South Asia, South America, Africa and elsewhere. Over longer distances, prioritize connection continuity over momentary response time and keep a nearby region as a backup.
Dubai · Mumbai · São PauloThe table lists representative entry points from the available coverage to show how regions and route types are combined. Streaming services may assess account region, content rights and exit environment differently, so “supported” means a suitable route is available for the stated use case—not that every title will produce the same result at all times.
| Country / Region | City | Route Type | Streaming Support |
|---|---|---|---|
| Asia-Pacific | |||
| Japan | Tokyo | IEPL Route | Supported; choose based on the target service |
| Japan | Osaka | Relay | Supported; switch entry points when needed |
| Singapore | Singapore | IEPL Route | Supported; suitable for Southeast Asian content |
| South Korea | Seoul | Relay | Supported; verify against the account region |
| Hong Kong, China | Hong Kong | IEPL Route | Supported; choose based on the target service |
| Australia | Sydney | Direct | Supported; suitable for local content |
| North America | |||
| United States | Los Angeles | IEPL Route | Supported; choose based on the target service |
| United States | San Jose | Relay | Supported; suitable for western U.S. services |
| United States | Seattle | Direct | Supported; switch entry points when needed |
| United States | New York | Relay | Supported; suitable for eastern U.S. services |
| Canada | Vancouver | Relay | Supported; verify against the account region |
| Canada | Toronto | Direct | Supported; suitable for local content |
| Europe | |||
| United Kingdom | London | IEPL Route | Supported; choose based on the target service |
| Germany | Frankfurt | Relay | Supported; suitable for Central European services |
| France | Paris | Direct | Supported; verify against the account region |
| Netherlands | Amsterdam | Relay | Supported; switch entry points when needed |
| Switzerland | Zurich | Direct | Verify against the target content |
| Sweden | Stockholm | Direct | Verify against the target content |
| Other Regions | |||
| United Arab Emirates | Dubai | Relay | Supported; verify against local content |
| India | Mumbai | Direct | Supported; suitable for local content |
| Brazil | São Paulo | Direct | Supported; verify against local content |
| South Africa | Johannesburg | Direct | Verify against the target content |
| Türkiye | Istanbul | Relay | Supported; switch entry points when needed |
| New Zealand | Auckland | Direct | Supported; suitable for local content |
The complete available range is shown in the current route list in the user panel. The client and subscription are available after login; this page does not provide a static subscription URL.
Route names are not a simple quality ranking. Each type addresses a different need: IEPL routes focus on control across international links, relay routes focus on entry-point routing, and direct routes focus on a simpler path and cost efficiency. Choose based on usage time, target region and the need for a persistent connection.
An IEPL route connects its entry and exit through a relatively fixed international link, reducing unpredictable path changes on public networks. It suits long meetings, remote desktops, code repository syncing, AI streaming output and extended viewing where connection continuity matters. IEPL resources generally cost more to build and maintain than direct routes, so not every lightweight task needs one. For a quick web lookup or a small download, a relay or direct route may be sufficient. When choosing IEPL, confirm the exit region first, then assess whether the complete task finishes successfully—not merely how the connection feels when it is first established.
A relay route connects to a suitable entry point first, then uses an intermediate link to reach the target exit. Its value is avoiding an unsuitable direct path between the local network and a remote data center while allowing more flexible entry-point routing. Everyday browsing, cross-region collaboration, media access and ordinary file transfers are all good starting uses. Because relay routes add a routing step, performance depends on local access, entry-point status and the remote exit. If the target service is in the eastern United States but you connect through a western U.S. entry before crossing the region, the path may still be longer. A relay route does not mean choosing regions at random; the target service location remains the first consideration.
A direct route connects from the current network to an exit in the target region, with a clear path, fewer intermediate routing steps and relatively predictable resource costs. It suits stable network environments, nearby targets or tasks that do not require a persistent connection. Direct performance depends more heavily on the public path between the local carrier network and the remote data center, so the same entry point may perform differently across networks and times of day. Keep a relay entry in the same region as an alternative. If pages load normally but meetings, streaming output or large transfers disconnect repeatedly, switch to a same-region relay or IEPL route instead of immediately moving to a more distant country.
One route does not need to handle every task. Identify what you need to accomplish, then choose the region, route type and backup entry point. The sequence below is designed for practical troubleshooting.
For browsing, research and lightweight online tools, start with a nearby relay or direct route that matches the target service region. Check whether pages load continuously, login sessions remain active, and images and scripts return completely. A single fast page does not guarantee a smooth long session; stability across multiple pages is a better indication that the entry point suits your network. If only one site behaves unexpectedly, try another entry in the same region rather than switching immediately to a distant region.
First confirm that the account region matches the target content region, then choose an entry marked for streaming in the table. Before playback, fully close the existing app session, reconnect through the route, and reopen the service so old region data does not remain active. If the homepage loads but the catalog differs, check the region match first; if the catalog is correct but playback buffers, try a same-region relay or IEPL route. Content rights, account plans and network routes are separate factors and should be checked separately.
AI web apps, IDE extensions and command-line tools often depend on persistent connections and streamed responses. Match the service’s usual region first, then compare IEPL and relay routes in that region. Do not stop testing at the login page: complete a longer conversation, continuous code completion or a full file-processing task to check for repeated reconnects during output. If the web app works but the extension does not, check whether the extension follows the system network settings. Terminals, IDEs and browsers may use different paths in a development environment and should be tested separately.
Interactive applications depend more on path stability and controlled variation. Prefer an entry in the same region as the game server rather than choosing another continent because its name is familiar. Start with a direct or relay route for login and matchmaking; if feedback becomes inconsistent, switch to an IEPL route in the same region. Updates and live sessions can use different entries: updates need sustained transfer, while gameplay needs interaction continuity. If issues occur only at certain times, note the region and route type in use so you can switch directly to the backup entry next time.
Video meetings, remote desktops, cloud documents and code repositories need sessions to remain stable. Start with the region where the company system or collaboration platform is hosted, then prefer a relay or IEPL route. Test the complete flow, including login, file uploads, online editing and joining a meeting. If an enterprise system applies regional policies, frequently changing exit regions may trigger additional checks, so use a consistent primary entry for daily work and keep a same-region backup. When switching backups, change only the route and not multiple client settings at once, making the source of a problem easier to identify.
Changing the region, route type and client settings at the same time makes the source of a problem impossible to identify. Follow a fixed order and change one condition at a time to find the entry point that suits your network.
First confirm the main region for the website, media content, AI service or workplace system. If the region is wrong, switching route types usually will not resolve account-region or content-catalog issues.
Try direct or relay routes for lightweight tasks; compare relay and IEPL routes first for meetings, remote operations and sustained output. The deciding factor is whether the complete task can finish continuously.
Reopen the target app and complete login, loading, playback, uploading or sustained output. Do not judge whether a route fits your use case solely by whether its homepage opens.
After selecting a primary entry, save another route type in the same region as a backup. When short-term fluctuations occur, switch within the same region first to avoid suddenly changing the exit location.
Choosing a route is only one part of the process. Check subscription periods, traffic resets, device management and refund terms separately so route changes are not mistaken for plan changes.
Monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly from the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. The plan determines available traffic, while the route determines the current connection path. Judge them separately. Switching routes does not change the plan period and should not replace checking your traffic balance.
This service has no limit on simultaneous devices and works across computers, tablets and other supported platforms. Different devices can choose routes for their own tasks, but if a work account, media account or developer tool is sensitive to regional context, keep the exit region consistent for the same task. Unlimited devices does not mean every device must use the same entry; a better approach is to assign routes by use case and record frequently used regions.
No email address is required to register; a username and password are enough. Payments support Alipay / WeChat Pay / USDT. To change your plan, use the user panel rather than entering account details on the static route page. The service offers a 30-day no-questions-asked refund; see the refund policy for the application route and scope.