Server locations and route list

How to read the route table

The table has four groups; each row is one route with four columns: country/region, city, route type and streaming support. Read the exit location first, then the route type, then fine-tune by use case.

• Country/region · City Where the route exits. Catalog region, service availability and default page language usually follow the exit location, so confirm this column first.
• Route type IEPL, relay or direct. The three take different paths, so peak-hour behaviour and cost differ too — see the route type section below.
• Streaming support Platforms commonly used at that exit location, useful for judging catalog region. For platforms not listed, actual availability applies, and catalogs themselves change as platforms adjust.

Asia Pacific routes

The Asia Pacific group handles most everyday requests. Hong Kong and Tokyo are close with plenty of entry points, so they work well as defaults; Singapore covers Southeast Asia, while Sydney and Bangkok add Oceania and mainland Southeast Asia. At peak hours the IEPL routes in Hong Kong and Sydney hold up better than direct routes in the same region, and Tokyo and Seoul relays are a middle ground.

In the Asia Pacific group, IEPL routes are concentrated in Hong Kong and Sydney; the other cities are mostly relay and direct.

North America routes

The North America group exits at both ends of the continent. Los Angeles, San Jose and Seattle serve the US West Coast and return paths to Asia, New York and Toronto cover the East Coast, and Dallas fills in the middle. US catalogs, some AI tools and developer services are sensitive to exit location, so confirm which region a service is available in before choosing a city.

The three West Coast cities and the two East Coast cities back each other up: when one city is congested you can move across without changing catalog region.

Europe routes

The Europe group is led by Frankfurt, London and Amsterdam. Frankfurt's IEPL route is steady both for hops inside Europe and for transatlantic return paths; London suits UK services and BBC iPlayer; Amsterdam and Paris carry general Western European traffic; Stockholm and Milan add Northern and Southern Europe. Common uses for European routes are UK and EU catalogs, European developer services and cross-time-zone collaboration.

EU catalogs are split by language: if the exit city and your account region don't match, the catalog may still be the original region's.

Routes in other regions

The other regions group covers exit needs in the Middle East, South Asia, South America and Africa. Dubai and Mumbai serve the Middle East and South Asia, São Paulo covers South America, and Johannesburg serves southern Africa. These regions have fewer routes than the first three groups and are mostly relay and direct — at peak times prefer relay and fall back to direct as needed.

Routes in this group are about coverage rather than peak performance; for stability-critical work, go back to the Asia Pacific or Europe groups.

Route types explained

The same Hong Kong route behaves and costs differently depending on whether it runs as IEPL, relay or direct. The difference is the path: where traffic joins the backbone, how many hops it takes, and where it queues.

Choosing a route

There is no single right answer: decide the use case first, then filter by exit location and route type. Below are suggested orders for six common use cases — try the first option for a given use case, then move down the list, and don't change two variables at once.

FAQ

Common questions about route counts, route types and switching rules — answers stick to the facts, and nothing is promised that isn't offered.