City exits / international routes

Global servers and city routes

Choose a destination region first, then compare connection types. The city indicates the exit location; the route type describes how the connection gets there. Your experience also depends on your local network and the service you’re accessing.

110+ countries / 170+ routes Unlimited devices Bank-grade encryption

This page provides static route references, not real-time performance data. Check the dashboard and client list after logging in for the route names, types, and regions currently available to your account.

View Plans View routes in the dashboard →

Exit regions

Browse city routes by region

VPNUrban covers 110+ countries and 170+ routes. The city and connection type references below are grouped by Asia-Pacific, North America, Europe, and other regions to help you compare options. This is not a complete route directory, and not every combination may be available to every account. Before connecting, check the routes included with your subscription in the dashboard, then refresh your client configuration.

The cities shown indicate exit regions, not your local entry point or the full path from your location to a destination website. Even with the same exit city, your experience may vary by carrier, access network, and destination. The Streaming column reflects this uncertainty: catalog availability, account region, and each platform’s exit-IP detection all affect playback. A city name alone cannot confirm access.

City and route type reference. Check the dashboard for available options; streaming access depends on your actual connection.
Country / region	City	Route type	Streaming availability
Asia-Pacific
Japan	Tokyo	IEPL dedicated line	Depends on actual access
Japan	Osaka	Relay	Depends on actual access
Hong Kong	Hong Kong	IEPL dedicated line	Depends on actual access
Singapore	Singapore	IEPL dedicated line	Depends on actual access
South Korea	Seoul	Relay	Depends on actual access
Australia	Sydney	Direct	Depends on actual access
New Zealand	Auckland	Relay	Depends on actual access
Malaysia	Kuala Lumpur	Relay	Depends on actual access
North America
United States	Los Angeles	Relay	Depends on actual access
United States	New York	Direct	Depends on actual access
Canada	Vancouver	Relay	Depends on actual access
Canada	Toronto	Direct	Depends on actual access
Europe
Germany	Berlin	Relay	Depends on actual access
Germany	Frankfurt	Direct	Depends on actual access
United Kingdom	London	Relay	Depends on actual access
France	Paris	Direct	Depends on actual access
Netherlands	Amsterdam	Relay	Depends on actual access
Switzerland	Zurich	Direct	Depends on actual access
Other regions
Brazil	São Paulo	Relay	Depends on actual access
South Africa	Johannesburg	Direct	Depends on actual access

Connection types

IEPL, relay, and direct routes

Route types are not a fixed ranking from fastest to slowest. They describe how traffic reaches an exit, while performance also depends on your local connection, carrier peering, and the path from the exit to the destination. For a fair comparison, keep the device, network, and destination service the same; otherwise, differences may come from changing conditions rather than the route.

Dedicated transport path

IEPL dedicated line

IEPL usually refers to an international Ethernet private line, using dedicated transport resources provided by carriers to connect different regions. Compared with paths that rely entirely on public internet peering, this type of connection offers greater control over the transport path. An IEPL label in a client still covers several segments, including your local connection to the entry point and the exit to the destination service. It does not mean the entire connection is isolated from public networks.

IEPL can be worth testing for office work, remote collaboration, and long viewing sessions that need a steady connection. Compare stability during the hours you typically use it. Dedicated resources generally cost more to procure and maintain, but that does not mean VPNUrban charges separately for each route or that a dedicated line is best for every destination. Check the exit region and test it with your actual tasks before choosing.

Forwarded through an entry point

Relay route

A relay route sends your connection to an entry point first, then forwards it to an exit. The entry and exit have different roles: the entry receives your local connection, while the exit connects to the destination service. Although this adds a forwarding hop, a better match with your local carrier or smoother peering along the relay segment may make the overall experience better than connecting directly to a distant exit. The number of hops alone is not a reliable measure.

Relay routes are worth considering for everyday browsing, AI tools, and working across regions. They require entry, forwarding, and exit resources, so costs depend on the route and resource setup; they do not always fall between dedicated and direct routes. If a connection has issues, try another route in the same region to see whether the problem is specific to an entry point before switching regions.

Connect directly to the exit

Direct route

A direct route usually means the client connects to the exit server without a separately configured relay entry. “Direct” describes the service deployment, not a physically straight path, and it does not mean there are no routing hops between carriers. Data still travels over your local network, access carrier, and interregional links; congestion on public routes can affect performance.

When your local network has suitable connectivity to the destination region, a direct route can be an option for everyday access and regional checks, and a useful point of comparison with relay routes. Skipping an extra entry point can simplify deployment, but exit bandwidth, data-center resources, and carrier peering still incur costs. Direct does not mean lower quality, and a route label is not a guaranteed speed claim. Judge availability by testing your intended task.

Start with your use case

Choose a cross-border route by task

Decide what you need to do before choosing an exit region. For tasks without regional requirements, start with a nearby candidate exit. If a task has regional requirements, prioritize the destination service’s policies. Distance is a filter, not a performance guarantee. Keeping a backup route in the same region makes troubleshooting easier than switching regions frequently.

Everyday browsing: Check the whole page

When browsing, check more than whether the homepage loads. Sign-in, images, attachments, and embedded content may come from different domains, so test them together. Choose a nearby exit that suits your local network, then try the sites you use most. If text loads but images remain blank, check client routing and DNS settings before trying random distant cities. Once browsing works, keep that route to avoid unnecessary configuration changes.

Streaming: Check the catalog and account first

Streaming access depends on exit-IP detection, catalog licensing, account region, and playback device. If you need a particular catalog, choose its region, search for the program, and test playback. Loading a platform’s homepage does not confirm catalog access, and a working trailer does not confirm that the full program will play. If video quality is unstable, check your home network, downloads on other devices, and route stability separately. A route name does not guarantee streaming access.

AI tools: Keep your region and session consistent

Before using tools such as ChatGPT or Cursor, check which regions the service supports and whether your account is eligible. A working connection does not guarantee account access or replace the service’s own subscription. After choosing an exit, test whether sign-in, chats, and editing requests complete successfully. Browser and desktop apps may use different proxy settings, so check each one. Keep the same exit throughout an active session to reduce repeated verification.

Gaming: Check client compatibility first

A network-acceleration subscription is not the same as a dedicated gaming accelerator. Games may use different transport methods, and launchers, sign-in, and gameplay may connect separately. Check the game’s rules and the client’s proxy support first, then consider the region of the game server. Downloading updates successfully does not confirm that gameplay traffic is routed as expected. Test connection stability outside ranked or otherwise consequential matches. If support is unclear, do not judge by exit distance alone.

Work: Follow your organization’s policies

Business systems may require access from a specific region, a company-approved network entry point, or additional identity checks. Confirm the policy with your administrator before choosing a route; do not override company requirements with personal network settings. Test document access, file uploads, and meeting connections separately. Before starting a long task, keep a working backup route available, but avoid switching during an upload or meeting. For sensitive information, follow your organization’s data-handling rules.

From route list to live connection

Test routes and record issues

Check your subscription, then your client

After signing in to the dashboard, check your plan and data status, then get your subscription and refresh the client list. Windows, macOS, iOS, Android, and Linux are supported platforms; you must sign in to get a subscription. Other platforms can access the client after signing in; the iOS download option also requires an active plan. Avoid configurations from unknown sources, and never post your subscription link publicly.

Once connected, open the actual website or app you need and test page loading, sign-in, and the relevant task. If the client reports a successful connection but the app still does not work, check whether it follows the system proxy, whether routing rules cover the destination domain, and whether DNS matches the client’s requirements. First confirm that traffic is using the selected route; then assess whether that route is suitable.

Change one variable at a time

Compare different route types in the same region on the same device and network to better isolate the effects of the entry point and forwarding path. If switching to another local network resolves the issue, investigate the original access environment. If only one app is affected, check its configuration and your service account first. Avoid changing the network, region, and client all at once; even if the issue clears, you will not know why.

If the issue persists, open a support ticket through the dashboard and include the destination service, when the issue occurred, the platform and client message, and the steps you have already tried. Before sharing screenshots, hide your username, subscription link, and access credentials. If the issue is limited to a particular route, include its name from the client; do not send the full subscription. For troubleshooting steps by symptom, read the troubleshooting guide.