Browse routes by region
The table shows sample locations and paths, not the full list of subscription options.
“Country or region” indicates the exit location, “city” distinguishes between exit points, and “route type” describes the general path to the exit. Read these details together: exits in Japan may use different upstream networks and access paths, and relay routes can perform differently depending on your local carrier and the location of the destination website. A nearby location is not automatically the best choice for every website.
Streaming availability is not guaranteed. Streaming services may determine what you can watch based on your exit region, account region, licensing rights, and their own detection systems. A successful network connection does not guarantee access to a particular catalog. Check what the platform currently offers and whether playback works. China routes are also subject to each platform’s account rules.
| Country or region | City | Route type | Streaming availability |
|---|---|---|---|
| Asia-Pacific | |||
| Hong Kong SAR | Hong Kong | IEPL | Availability depends on platform rules and actual playback |
| Singapore | Singapore | Relay | Availability depends on platform rules and actual playback |
| Japan | Tokyo | Direct | Availability depends on platform rules and actual playback |
| South Korea | Seoul | Relay | Availability depends on platform rules and actual playback |
| Australia | Sydney | Direct | Availability depends on platform rules and actual playback |
| China | Shanghai (China route) | Relay | Availability depends on platform rules and actual playback |
| North America | |||
| United States | Los Angeles | Relay | Availability depends on platform rules and actual playback |
| United States | Seattle | Direct | Availability depends on platform rules and actual playback |
| United States | New York | Direct | Availability depends on platform rules and actual playback |
| Canada | Vancouver | Relay | Availability depends on platform rules and actual playback |
| Canada | Toronto | Direct | Availability depends on platform rules and actual playback |
| Mexico | Mexico City | Direct | Availability depends on platform rules and actual playback |
| Europe | |||
| Germany | Frankfurt | Direct | Availability depends on platform rules and actual playback |
| United Kingdom | London | Relay | Availability depends on platform rules and actual playback |
| France | Paris | Direct | Availability depends on platform rules and actual playback |
| Netherlands | Amsterdam | Relay | Availability depends on platform rules and actual playback |
| Switzerland | Zurich | Direct | Availability depends on platform rules and actual playback |
| Sweden | Stockholm | Direct | Availability depends on platform rules and actual playback |
| Other regions | |||
| Brazil | São Paulo | Relay | Availability depends on platform rules and actual playback |
| Chile | Santiago | Direct | Availability depends on platform rules and actual playback |
| South Africa | Johannesburg | Direct | Availability depends on platform rules and actual playback |
| United Arab Emirates | Dubai | Relay | Availability depends on platform rules and actual playback |
| India | Mumbai | Relay | Availability depends on platform rules and actual playback |
| New Zealand | Auckland | Direct | Availability depends on platform rules and actual playback |
Coverage across regions does not mean every exit is always available. Maintenance, subscription updates, and route changes may affect the options shown in your client. To find a specific route, update your subscription first, then check the location and route labels.
Route types and how they differ
Dedicated, relay, and direct describe network topology—not protocol names or fixed levels of performance.
IEPL
When control over the transmission path matters.
IEPL usually refers to an international Ethernet private line. In a route design, the private line carries one segment of the path; it does not mean every segment between your device and the destination website is an exclusive connection. Your local Wi-Fi, carrier access, and the network between the exit and destination service all affect the experience. The “private line” label alone does not mean every app will be faster.
Compared with routes that rely entirely on public internet routing, a private-line segment is generally easier to manage and plan. It may suit continuous sessions, remote collaboration, and use during peak hours. However, the destination’s location, peering arrangements, and device performance can still be limiting factors. For a fair comparison, keep the destination website and local network unchanged, then check page loads, session stability, and task completion.
Private lines generally require ongoing investment in transport and access resources. A plan’s price alone does not reveal how resources are allocated to any particular route. VPNEG’s available routes depend on your subscription; the IEPL label on this page is not a promise of dedicated resources or performance.
Relay routes
Connect to an exit through an access point.
A relay route adds an access or forwarding hop between you and the exit. The connection first reaches the relay location, then continues along the remaining path to the exit. The relay and final exit may be in different regions, so the exit city shown in your client does not tell you every location the connection passes through.
An extra forwarding hop does not necessarily make the connection worse. Public routing can sometimes take inefficient peering paths, and a relay can change the route by using a different combination of access networks and upstream providers. But a congested access segment or an unsuitable path between the relay and exit can add latency. The best way to judge is to compare it with a direct route to the same exit region using the same task.
Relay routes combine access, forwarding, and exit resources, so maintaining them requires coordination across more components. They may suit users looking to balance location choice with everyday connectivity, but they are not a universally optimal option for every carrier. If something goes wrong, keep the error message and selected route name; this is more useful for troubleshooting than switching repeatedly.
Direct routes
Connect directly to a specified exit.
A direct route means the client connects to the specified exit service without an additional relay access point arranged by the subscription service. “Direct” does not mean there is no carrier routing between your device and the server, nor does it guarantee a shorter physical distance. Data still travels through local access networks, backbone links, and the network at the exit location.
Direct routes have a relatively simple topology, making it easier to identify the connection destination. They can also help you assess how your local carrier routes traffic to a particular region. When peering between your local network and the exit is suitable, a direct route may work well for everyday browsing or access to a specific region. But a simple topology will not automatically prevent congestion or inefficient public routing.
Compared with routes that add transport or forwarding hops, direct routes generally involve fewer corresponding resources and maintenance steps. However, the exit region, upstream network, and resource costs still matter. Direct does not mean low quality, and relay or private-line routes are not necessarily better for your needs. Identify the target region first, then test the application; this is usually more effective than ranking routes by name alone.
Choose your route and protocol separately
Trojan, VLESS, Hysteria2, and TUIC are connection protocols; IEPL, relay, and direct describe route arrangements. The same exit can perform differently depending on client capabilities, network conditions, and protocol implementation. First make sure your client supports the protocol, then compare routes. Avoid changing the exit, protocol, and local network at the same time, or it will be hard to tell what caused the difference. For protocol details and when to use each, see the route and protocol guide.
Choose an exit by use case
Everyday browsing
If you don’t need a specific region, start with one that has suitable peering with your local network. Test sites you visit regularly, checking initial page loads, images, and sign-in. Don’t stick with an exit just because it’s geographically close, or switch repeatedly over an occasional delay on one page. If the same site has problems on multiple routes, first check the site’s status, local DNS, and browser cache.
Streaming and China video services
For streaming, check the service region first, then test playback. For international content, choose an exit that matches the platform’s service regions. For access to China-based services, check the China route label in your client rather than using an international exit. Test by opening a title’s details, starting playback, and resuming after seeking. Picture quality also depends on your plan, licensing, device, and local network; route labels cannot replace an actual playback test.
AI tools
Before using AI tools such as ChatGPT, check the platform’s currently supported regions and account requirements. After choosing a suitable region, test sign-in, request submission, complete responses, and file operations—not just whether the homepage loads. Keep the same exit region during account use where possible, and avoid switching regions without a clear reason. Changing routes alone will not resolve regional rules, account verification, or platform security checks.
For a more detailed access checklist, see the ChatGPT connection guide. The regional table on this page does not guarantee availability on any AI platform.
Gaming
Choose a route based on the region of the game server you actually connect to, not the publisher’s location. First check whether the game’s traffic goes through the client, especially the client’s routing mode and UDP support. During a live session, check reconnections, input response, and voice chat stability. Loading the game website or downloading an update does not mean the game session follows the same route. These route examples do not guarantee dedicated support for every game or console.
Remote work
For work, session stability and your organization’s access policies matter most. When accessing code repositories, cloud documents, remote desktops, or meeting services, keep to a verified region where possible and check in advance whether your organization requires a fixed exit or dedicated access. VPNEG supports unlimited devices online at the same time, but performance may vary between devices due to Wi-Fi signal, client settings, or background tasks.
If your device is also running a network client provided by your organization, follow its requirements when checking routing and DNS settings. Avoid changing exits during important meetings or file uploads. If you need to compare routes, do so before starting the task.
Test your connection and maintain your subscription
Verify the exit with a real task
Get your current subscription from the user dashboard, import it into your client, and update it before choosing an exit. Once connected, check the exit details on the network test page, then open the app you want to use. Browsers and other apps may use different proxy settings, so the exit shown in your browser does not necessarily represent every connection on your device.
If something seems wrong, first check that the client is connected, your system clock is correct, and your subscription is up to date. Then confirm that routing rules include the app you need. Keep the destination service the same while comparing different routes in the same region. If the issue occurs only on one local network, test on another trusted network. This helps narrow down the cause instead of assuming every failure is due to the exit region.
Keep useful troubleshooting details
For help, use the support ticket portal in the user dashboard and include your client platform, route name, destination service, error message, and what you were doing when the issue occurred. Before sharing screenshots, hide subscription links, account credentials, and private content. Never post your full subscription URL in a public discussion. The route name and what happened are enough to describe the problem; do not share access credentials.