REGION / EXIT / PATH
Locations and route information
When reviewing a server list, check the country or region, city, route type, and target service separately. The same egress location can use different access paths, while routes of the same type can have different destinations and network hops. Don't infer speed from a location name or treat geographic distance as a definitive measure.
The table below uses the United States, Japan, Singapore, Hong Kong, and the Netherlands to show how to read route information. The route combinations are examples, not a promise that these routes are currently offered or available, and not a complete server list. Cities that have not been checked against the current dashboard are not specified here. To see whether a streaming service works, test it with your own account.
| Country / region | City | Example route types | Streaming support |
|---|---|---|---|
| Asia-Pacific | |||
| Japan | Check the dashboard | IEPL | Depends on actual access |
| Japan | Check the dashboard | Transit | Depends on actual access |
| Japan | Check the dashboard | Direct | Depends on actual access |
| Singapore | Check the dashboard | IEPL | Depends on actual access |
| Singapore | Check the dashboard | Transit | Depends on actual access |
| Singapore | Check the dashboard | Direct | Depends on actual access |
| Hong Kong | Check the dashboard | IEPL | Depends on actual access |
| Hong Kong | Check the dashboard | Transit | Depends on actual access |
| Hong Kong | Check the dashboard | Direct | Depends on actual access |
| North America | |||
| United States | Check the dashboard | IEPL | Depends on actual access |
| United States | Check the dashboard | Transit | Depends on actual access |
| United States | Check the dashboard | Direct | Depends on actual access |
| Europe | |||
| Netherlands | Check the dashboard | IEPL | Depends on actual access |
| Netherlands | Check the dashboard | Transit | Depends on actual access |
| Netherlands | Check the dashboard | Direct | Depends on actual access |
| Other regions | |||
| See the dashboard for the full list | Check the dashboard | Check the specific route details | Depends on actual access |
How to interpret location labels
Locations in server names generally indicate the egress region. They shouldn't be taken as the physical data center address, network provider, or a guarantee of fixed egress capabilities. If your workflow requires a specific egress location, check the region detected by the destination website after connecting; location databases can differ between sites. For accounts that stay signed in, sticking with a verified location can make troubleshooting easier than switching regions frequently.
Read the city field in the current client or user dashboard. A city name on a marketing page alone can't confirm which servers are available to your account or what location a target service will detect. This page therefore provides a way to verify details instead of presenting unchecked cities, data centers, or egress attributes as product specifications.
TRANSPORT MODULES
Route types and path differences
IEPL, transit, and direct describe different ways of organizing a network path; they are not a performance ranking. The overview below explains the general principles behind these labels to help you read the dashboard. Check current service details and test the connection for specific configurations, availability, and performance.
PRIVATE TRANSPORT
IEPL
How it works. IEPL generally refers to an international Ethernet private line used to carry network traffic between regions. Compared with a path that relies entirely on public internet routing, the private-line segment typically has more clearly allocated transmission resources. However, connections from your device to the entry point and from the egress to the destination website are still involved. The IEPL label doesn't mean that every segment of the end-to-end path uses dedicated resources.
When to consider it. For video calls, remote work, sustained uploads, and interactive tasks sensitive to fluctuations, consider this route type if it's listed in your dashboard. Focus on whether it reliably supports your actual workflow, not just its label. Congested home Wi-Fi, a sleeping device, or issues with the destination service can also affect your experience on an IEPL route.
Cost considerations. Private lines generally involve dedicated transmission and maintenance costs, with resource arrangements that differ from ordinary public internet traffic. This is a distinction in network infrastructure; it doesn't mean the service has additional, unpublished route fees. Check the plans page and dashboard for pricing and availability. Don't infer charges from route abbreviations.
RELAY TRANSPORT
Transit routes
How it works. A transit route adds an entry point or intermediate node to carry traffic between your device and the destination egress. Your device connects to the entry point first, then traffic travels over the next link to the egress. The purpose is to organize the access path differently; adding a node doesn't automatically make the connection faster. Results depend on the entry point, the link that follows, and the egress network.
When to consider it. If your local network has trouble connecting directly to an overseas egress, but a transit route in the same region performs more consistently, it may be worth trying for browsing, streaming, or work. When comparing routes, keep the destination website and local network the same so that only the network path changes.
Cost considerations. Transit routes require entry and egress resources, as well as transmission between them. Costs depend on the network resources and path used; the word “transit” alone doesn't determine the price. Transit and private-line segments aren't necessarily mutually exclusive. Use the full labels in the dashboard for context rather than treating an abbreviation as a complete topology description.
DIRECT TRANSPORT
Direct routes
How it works. Direct generally means your device connects to the selected node without an additional transit entry point configured by the service. It doesn't mean there are no carrier routes along the way or no other network segments between the egress and the website. Public network routing, peering conditions, and the destination service's response can still affect your experience.
When to consider it. When your local network connects smoothly to the selected egress, a direct route can work for everyday browsing, research, and general app access. It can also serve as a comparison point: if direct and transit routes in the same region behave differently, check the access path further rather than immediately assuming the destination website is at fault.
Cost considerations. Direct routes generally don't require an additional transit entry point of the same kind, but egress resources and public network transmission still incur costs. A simpler-looking path doesn't mean every region has the same resource conditions, nor does it guarantee a lower price or faster connection. Choose based on how well it handles your tasks, not assumptions about the label.
SELECT BY WORKLOAD
Choose an international route by use case
Different tasks have different network requirements. A webpage loading doesn't mean a long video call will run smoothly; a video playing doesn't mean a particular AI service will accept your account. Start with the task you need to complete, then choose a location and route instead of cycling through every server in the list.
BROWSING
Everyday browsing
For research and general web browsing, check that page text, images, and logged-in content all load properly. If the homepage opens but images keep failing, the cause could be split-tunneling rules, browser cache, or the route to resource domains. Don't judge a route solely by whether the homepage loads. Keeping proxy settings consistent between your browser and client usually makes troubleshooting easier than switching regions repeatedly.
Once you find a reliable option, keep one different route as a backup. If everyday browsing doesn't require a specific location, there's little reason to add path complexity by choosing a more distant egress. If a website's content depends on your account region, follow its rules and verify the actual egress location.
STREAMING
Streaming and video
Check your account's entitlements and the region where the content is available, then choose an appropriate egress. Being able to open the Netflix, YouTube, or another service's homepage doesn't mean your account can play all content. Services may determine availability based on egress, account region, and licensing arrangements, and different routes in the same region can produce different results.
To test playback, open the actual video and check that it plays smoothly over time. Picture quality also depends on the source, your device, and your local network; a route type is not a picture-quality guarantee. If you need to switch egress, stop playback first and reopen the video to avoid old-session effects. See the streaming access guide for more checks.
AI TOOLS
AI web apps and APIs
When using AI tools such as ChatGPT, first check the service's requirements for your location, account, and features. A web page loading doesn't mean API calls will work; they may use different domains, authentication methods, and request paths. Test sign-in, sending a prompt, and receiving the full response separately. In a development environment, also confirm that the process is actually using the proxy.
For ongoing tasks, use an egress you've already tested and avoid switching regions mid-request. If your workflow requires a fixed egress, first check whether the current product offers that capability; don't infer a dedicated or fixed IP from a server name. If a long request fails, check the client, app timeout settings, and service response. See the AI tools access guide for details.
INTERACTIVE
Gaming and interactive apps
Check the game's region and network requirements before deciding whether to use a proxy. Normal web browsing only confirms that the browser's request path works; the game process may use a different connection method or may not follow the same proxy rules. The connection targets may also differ between sign-in and gameplay, so check both.
When comparing routes, keep the game region, local network, and client settings the same. If an issue affects only one game, don't immediately route all network traffic through a proxy. First check the supported connection methods and follow the platform's rules. Service coverage doesn't guarantee compatibility or in-game performance for every title.
OFFICE
Work and remote collaboration
For video calls, remote desktops, and cloud file collaboration, prioritize sustained connections and successful completion of the task. Test your actual workflow: join a meeting, share content, upload a file, and confirm it's saved. These steps reveal more about a route's suitability than simply opening a sign-in page.
Corporate networks may have their own access requirements, so check your company's policies before use. Switching nodes may change your egress and trigger reauthentication, so avoid repeated switches in the middle of important work. VPNUPS supports unlimited simultaneous devices, but check each device's configuration separately. When several devices are connected, keep an eye on local network capacity and account traffic.
CHECK / COMPARE / RETAIN
Test your connection and keep a backup route
Start by checking your local connection
First confirm that your device can access commonly used local websites without a proxy, then check that the client has fetched the current subscription. If the subscription update fails, resolve that issue before using an old list to judge whether a server is available. Get the client and subscription through the user dashboard. See the getting started guide for instructions.
Change only the route when comparing
Use the same device, local network, and target task. Compare different paths in the same region first, then compare other regions if needed. If you change Wi-Fi networks, split-tunneling rules, and servers all at once, it's difficult to tell which change improved the result. Note the route name shown in the client and the exact error message; these are more useful for troubleshooting than simply saying the connection is unreliable.
Keep a tested backup
Keep separate routes for everyday tasks and backup use. A backup should have successfully completed your usual tasks, not merely shown a connected status. If something goes wrong, pause uploads and other ongoing activity before switching paths and testing again. This is practical route redundancy, not a guarantee that every network segment will stay connected.
When to submit a support ticket
If the same issue persists after switching routes, continue troubleshooting by symptom in the troubleshooting handbook. For further help, submit a ticket through the user dashboard and include your operating system, client name, selected route, network environment, and a redacted error message. Don't include passwords, full subscription links, or other access credentials in screenshots.