Asia-Pacific: the country question comes first

APAC is an acronym, not a market

The markets under the label share almost nothing operationally. Japan and Korea run on mature fixed broadband behind their own dominant platforms. China sits behind a filtering regime that makes your exit address the smallest of the problems. India, Indonesia, Vietnam and the Philippines are mobile-first, where the same brand often serves a phone something different from what it serves a desktop. Australia and New Zealand behave far more like Western markets than like their neighbours.

That is why a request for an APAC proxy is usually under-specified. Naming the country turns a shopping question into a technical one you can settle: does this target vary by client address, or does it not.

What the exit changes, and what it does not

Most of the web does not care where a request came from. Public REST APIs, developer documentation, feeds, sitemaps, regulator filings and a large share of catalogue pages return the same bytes to Virginia, Oregon or Ireland that they would to a machine in Tokyo. If that describes your targets, an in-region exit buys a shorter path and nothing else.

The cases where the exit decides the answer are narrower than most vendor pages suggest, and short enough to check against your own URL list first.

Language is negotiated, and we cannot negotiate it

A frequent reason for wanting an APAC exit is to see Japanese, Korean, Chinese or Thai content, and that is usually the wrong lever. Many sites pick their language from the Accept-Language header, or from a locale path or subdomain such as /ja/ or ja.example.com, rather than from the address the request arrived on. Where that is true the URL does all the work and the exit region none of it.

Worth knowing before you plan around it: our nodes send a fixed Accept-Language of en-US,en;q=0.9, and the only outbound header a caller can influence is User-Agent. On a site that negotiates by header you get the English variant from every one of our regions, and an exit of ours in Tokyo would not change that. Where a localised URL exists, fetch that URL. Where negotiation is the only route to the local variant, we cannot get you there today.

Distance is paid in round trips

Physical distance is a real cost and it is not paid once. A fetch from Virginia or Oregon to a host in Singapore or Sydney crosses an ocean for DNS, again for the TCP handshake, again for TLS, and again for the request itself — and a redirect starts the count over. On a few hundred requests that is an annoyance. Across a crawl of hundreds of thousands it becomes the dominant cost of the run, in wall-clock time and in timeouts on slow origins rather than in money, since we bill per request rather than per second.

We will not put a millisecond figure on that, because we do not measure per-country latency and an invented number is worse than none. Measure your own targets — elapsed_ms comes back on every fetch. Two things help: us-west sits in Oregon, on the Pacific, so it is the shorter of our two US regions to most Pacific-rim hosts, and raising concurrency beats tuning any single request, because what you are paying is latency rather than bandwidth.

Asking for a region

Adding one is a scripted provision and deploy from the same repository as the API, so whether we run a node in Asia-Pacific is a question of demand rather than of engineering effort. Email support@roamingproxy.com for a straight answer about whether and when, rather than a roadmap date we would have to walk back.

Include the countries, the targets and roughly what volume — plus the thing people leave out: whether a datacenter address in that country would actually satisfy you. If you need to look like a home connection in Seoul, a node of ours in Seoul would not deliver that either, and it is better established in the first email than the third.

Questions

Do you have a proxy in Japan, Singapore, India or Australia?

No. The regions are us-east, us-west and europe, and GET /v2/proxy/regions is the live health-gated list. If you are fetching Pacific-rim hosts from us, start with us-west — Oregon is the shorter path of our two US regions.

Will a US exit work for an Asian website?

For a great many of them, yes. Public APIs, documentation, feeds and most catalogue pages serve identical content regardless of where the request came from; you pay round-trip time and nothing else. It fails on geo-gated media, country-restricted services and address-keyed pricing.

Can I set Accept-Language to get the Japanese variant?

No. The nodes send a fixed Accept-Language of en-US,en;q=0.9 and User-Agent is the only outbound header a caller can influence. If the site exposes a locale URL, fetch that URL directly; the region you choose makes no difference to which language you get.

Can I get residential or mobile APAC addresses?

No. Every address we egress from is a datacenter address on an EC2 instance we run. We have no residential or mobile addresses in any region, and rotation within our own range does not change what a site checking address type will see.

Related