Browse by region
The directory below is organized by Asia-Pacific, North America, Europe, and other regions. It lists only the popular regions named in the service overview; it is not a complete list of available locations. Cities and route types are not specified unless confirmed.
| Country / Region | City | Route Type | Streaming Support |
|---|---|---|---|
| Asia-Pacific | |||
| Hong Kong | Check the dashboard | Check the dashboard | Verify on the platform |
| Singapore | Check the dashboard | Check the dashboard | Verify on the platform |
| Japan | Check the dashboard | Check the dashboard | Verify on the platform |
| North America | |||
| United States | Check the dashboard | Check the dashboard | Verify on the platform |
| Europe | |||
| Germany | Check the dashboard | Check the dashboard | Verify on the platform |
| Italy | Check the dashboard | Check the dashboard | Verify on the platform |
| Other Regions | |||
| Other Covered Regions | Sign in to the dashboard | Check the dashboard | Verify on the target platform |
Country and region names mainly identify the exit location. The client's entry point, the networks traffic passes through, and the exit seen by the destination website may all be in different places. Choosing Japan does not mean the route uses a dedicated connection, and choosing the United States does not guarantee access to any particular AI tool. Check the region, route type, and app support separately.
“Verify on the platform” means this page does not make a blanket promise about streaming support. Platforms may check the exit IP, account region, content rights, and client status. Results can also vary between routes in the same region. To check a catalog, use the page and playback results shown for your own account—not just the region displayed in the client.
For the complete list, check the dashboard and your latest subscription. If the client and dashboard show different information, update the subscription first, then check whether an old configuration or manually copied route is still in use. Don't infer unlisted cities, network providers, or service capabilities from geography alone.
Route Types & Network Paths
This section explains common networking terms; it does not mean every type is available in every VPNBaby region. Check the dashboard for available options. If a route is not explicitly labeled, don't assume it's a dedicated connection.
IEPL
Dedicated routes: designed for cross-region transport
IEPL usually refers to an international Ethernet private line, where a dedicated transport network is used for the cross-region segment rather than relying entirely on public internet routes. The user's local network, connection to the service entry point, and access from the exit to the destination website are still part of the full path. The term describes one aspect of network architecture; it does not replace checking the route end to end.
This type of transport generally involves higher resource costs and may suit use cases that depend on consistent traffic, such as long work sessions or video streaming. Higher cost does not mean it's a better fit at every time or on every access network, nor does it mean a platform will accept the exit. If IEPL is not shown in the dashboard, don't classify a route as dedicated based on how it feels to use.
- Check that the route type is explicitly labeled.
- Also check your local connection and how the app performs at the exit.
RELAY
Relayed routes: traffic forwarded through an entry point
A relayed route connects to an entry point first, which then forwards traffic to a further exit. This changes how the path is organized and may help when routing from the local network to a remote exit is suboptimal. A relay is not the same as IEPL; check the route details to see what transport is used for the cross-region segment.
Relayed routes require entry-point resources, forwarding capacity, and ongoing maintenance, so their cost structure is generally more complex than a direct connection. They may help when a local network performs poorly with a remote exit directly, but an entry point delivers a more consistent experience in practice. Extra forwarding hops are not inherently better or worse; compare routes using the same app under similar conditions.
- Useful for comparing how different connection paths perform.
- A relay label does not prove an app will work.
DIRECT
Direct routes: distinguish the network path from a routing rule
As a route type, direct usually means the client connects to the remote service entry point without going through a relay entry point configured by the service. This involves fewer steps and a more straightforward resource setup, but performance depends more on the public internet path between the local network and the remote location. Fewer steps do not necessarily make it a better fit for every region or app.
“Direct” in a routing rule means something different: the specified website or app uses the local network instead of a proxy exit. For example, setting a mainland China site to direct is a routing action, not a choice of an overseas direct route. When troubleshooting, first distinguish these meanings to determine whether to change the selected server or the matching rule.
- A direct route describes the path from the client to the entry point.
- A direct rule describes an app using the local network.
Choose an exit by use case
Choose in this order: app requirements, exit region, actual performance, then a backup option. Don't send every app through the same remote route before you've confirmed what each one needs.
Let rules handle split tunneling
Everyday browsing often involves both local and international services. In rule mode, requests that need an international route can use a chosen exit, while other sites connect directly according to the rules. If a site specifies an exit location, start there. Otherwise, compare candidate routes based on how pages open, images load, and browsing holds up over time.
If only one site won't open, you don't need to change every route first. Check whether it matches the expected rule, then see whether related domains referenced by the page follow the same route. Switching temporarily to global mode can help narrow down the issue, but return to a suitable rule configuration afterward.
Check the content region, then test playback
Start with the content you want to watch and the platform's regional requirements, not the route name. Choose the relevant region, reopen the platform, and check whether your account's catalog includes the title and plays it. Reaching the home page only confirms a basic response; it does not verify playback. A region warning also doesn't necessarily mean the local connection failed.
During playback, check for persistent buffering, repeated changes in picture quality, and large downloads running on other devices. Compare routes with the same content under similar playback conditions so changes in the source, account access, or local Wi-Fi don't skew the results. For more on regions and playback checks, see the streaming guide.
Keep your account session and exit consistent
AI tools may check service region, account permissions, exit IP, and browser session separately. Before choosing an exit, review the target tool's service area and terms of use. A working connection does not mean your account has access, or that the tool accepts every exit in that region.
Once you've confirmed a route works with your target tool, keep its related domains on the same exit. Avoid switching regions between sign-in, page loading, and submitting requests. If an error occurs, note its wording and distinguish a region notice from an account issue or failed network request. For access guidance on ChatGPT, Claude, and Gemini, see the AI tools guide.
Check the game region and test an actual match
A game's login service, content downloads, and match servers may be in different locations. Before choosing a route, identify the actual game region and check whether the client's proxy mode covers the game process. A working browser connection does not prove game traffic uses the same exit. In particular, check whether the client supports the connection method used by the game.
This page makes no compatibility claims for specific games. If the connection drops, compare results in the same game region and under similar network conditions. Check whether only the game is affected or other apps as well. Don't choose a route based only on its region name at the expense of the game's network requirements, and read the game's rules before changing configuration.
Follow your organization's policies and keep a backup route
For work, first confirm whether your organization allows external network services and whether its systems require a fixed exit, region, or access permission. If your company has deployed a dedicated access client, don't layer another network configuration on top without checking. Ask your administrator about compatibility to avoid conflicts between local routes, DNS resolution, and system proxy settings.
For routine work, assign work apps to a verified route and keep a backup option that meets your organization's requirements. Before an important meeting or a long upload, test sign-in and file access. Changing exits may trigger account security checks, so avoid switching regions repeatedly during a critical session. A route is not a substitute for workplace access permissions.
Split Tunneling Rules & Exit Verification
Rules determine where a request goes; the node determines which route it takes. Checking these separately is usually more effective than repeatedly switching nodes.
After importing, check that the configuration is up to date
Sign in to the dashboard to get your subscription, then import it into the client you're using. Supported platforms include Windows / macOS / iOS / Android / Linux. After importing, check the active configuration name and route list to make sure you're not still using an older saved configuration. The dashboard provides the client and subscription access; this page does not provide installers or live subscription URLs.
A subscription provides configuration details; it is not the currently selected node. After updating, also check the selected policy group and routing mode. If the list updates but an app still uses the old exit, the issue may be a manual policy group selection rather than a failed subscription update.
Use the target app to check the matching result
After opening the target app, check where its requests are routed using the connection details or rule-matching view provided by your client. First determine whether traffic is direct or proxied, then check which policy group and node the proxy uses. If a rule doesn't cover all relevant domains, the main page and its resources may take different routes; check the requests made by the app.
Examples of split-tunneling rules include “AI tools → route in a selected region” and “mainland China sites → direct.” These describe how to organize rules; they don't guarantee platform availability. After making changes, reopen the app and test the page, sign-in, and relevant features. Don't rely on the client's connection toggle alone to conclude that everything is working.
What to check when a route has issues
Narrow down the cause before changing configuration. Change one thing at a time so you can tell which adjustment made a difference.
All apps affected: start with your connection and subscription
Temporarily disconnect the proxy and check whether your local network can still reach sites that normally work. If it can, check that the subscription is up to date, your plan and data status are normal in the dashboard, and the client has an active route selected. Then try another candidate node to see whether the issue is limited to one route. Don't reinstall the client, change DNS, and rebuild rules all at once before confirming the connection is working.
Only one app affected: check its rules and platform messages
If other apps work, first check the affected app's matching rules, exit region, and account status. Keep the platform's exact error message; it's more useful than a vague report that something “doesn't work.” If behavior changes after switching modes, revisit the rules. If only specific content is unavailable, consider content rights and account permissions rather than assuming a route failure.
Intermittent issues: compare under similar conditions
For repeated loading problems or dropped connections, note the device platform, client, route name, network connection type, and time. First rule out local downloads, unstable Wi-Fi, and system background restrictions, then compare other candidate routes in the same app. Results from different times, devices, or content aren't a like-for-like route comparison.
Need help? Share what happened, not sensitive configuration
If you still can't identify the issue after updating the subscription and checking the rules, describe the target app, error message, route name, and steps you've tried in a dashboard support ticket. Redact subscription URLs, passwords, tokens, and sensitive account details from screenshots. Don't share your full subscription configuration publicly. A clear description of what is affected and what you did helps distinguish a local configuration problem from a route issue that needs further investigation.
For a systematic troubleshooting process, see the troubleshooting handbook. For common account and billing questions, see the FAQ. Choose routes for specific apps rather than sorting only by region or route type. Once you've found a route that works, keep a stable configuration and assign exits by use case.