Configuring a Japanese proxy IP address

Why anyone needs a Japanese exit address

Three reasons cover almost every case. The first is content that is only served inside Japan: ticketing pages, telecom and bank portals, regional shop sections, and media pages that return a polite refusal to everybody else. The second is regional pricing — storefronts, SaaS plans, travel and game stores frequently show a different price in yen, and the only way to see the Japanese figure is to ask for it from a Japanese address. The third is quality assurance on your own site: if you serve a Japanese version, you need to see what a visitor in Tokyo sees, including the language you actually send them, the currency you quote and whether your CDN routes them somewhere sensible.

All three want the same thing: a request that leaves the network from an address registered in Japan, with the rest of the request consistent with that. Residential and mobile addresses matter here more than in most countries, because a great deal of Japanese consumer infrastructure treats datacentre ranges with suspicion and will show a challenge page rather than the content you came for.

The configuration: the country goes in the username

On an authenticated rotating gateway you do not change the host to change country. The host stays the same and the username carries the options. For Japan, append -country-jp to your username:

Host:     gw.pyproxy.com
Port:     1111
Username: USERNAME-country-jp
Password: PASSWORD

The equivalent as a single curl line, which is also the fastest way to confirm it works at all:

curl -x http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip

Two properties of that line are worth knowing before you build anything on it. It is an HTTP proxy, and HTTPS goes through it by CONNECT tunnel, which is what curl, browsers and every normal HTTP library do automatically. It is not SOCKS5 — the residential pool here is HTTP and HTTPS only, so configure your client as an HTTP proxy and not as a SOCKS endpoint. And by default the exit address can be different on every request, which is fine for independent page fetches and wrong for anything with a session.

When you need the same Japanese address to persist — a login, a cart, a multi-step form — add a session token to the username. The token holds one exit address for about thirty minutes, then the pool moves on:

curl -x http://USERNAME-country-jp-session-tokyo01:PASSWORD@gw.pyproxy.com:1111 \
     https://httpbin.org/ip

For shell tools that read the environment rather than accepting -x, exporting the proxy once is usually less error-prone than threading the credential through every call:

export http_proxy="http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1"

Verifying it properly, not just looking at an IP page

The usual verification is to load an IP lookup site, see "Japan" and stop. That is the weakest test available, because geolocation databases are exactly the thing that is often wrong. Do it as a smoke test, then do the two checks that matter.

First, confirm the address and cross-check it against a second, independent database rather than trusting one verdict:

IP=$(curl -s -x http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111 \
     https://api.ipify.org)
echo "$IP"
curl -s "https://ipinfo.io/$IP/json"

Second — and this is the real test — check the target site's own behaviour. A site that cares about your country will tell you what it thinks in its response, and the signals are easy to read: the Content-Language header, the lang attribute on the html element, a redirect to a /ja/ or /jp/ path, a currency symbol, or a geolocation cookie it sets on your behalf. Read the headers first:

curl -sI -x http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111 \
     https://your-target.example/ | grep -iE 'location|content-language|set-cookie'

Then read what came back and compare it with the same request made without the proxy. If the two responses are identical, either the site does not do geo-targeting at all or your Japanese identity is not convincing, and the next section is about the second case.

curl -s -x http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111 \
     https://your-target.example/ | grep -oE '<html[^>]*lang="[^"]*"'

The usual failure: Japanese address, foreign browser

This is the problem that brings most people to this page. The exit IP is unquestionably in Japan, the lookup page agrees, and the site still serves English, still quotes dollars, still shows the international version. Nothing is broken. The address is one signal among several, and the others are still saying you are somewhere else.

The ones that actually cause it, roughly in order of how often they are the culprit:

• The Accept-Language header. If your client sends en-US,en;q=0.9, a well-built site will honour your stated preference over its guess about your location — which is correct behaviour on its part and the wrong outcome for your test.
• The browser timezone. Any page running JavaScript can read it in one call, and a browser reporting Europe/London from a Tokyo address is an obvious contradiction. Scripted geo gates check this constantly.
• Cookies and account state. A previously set country or currency cookie, or a logged-in account with a billing country on file, beats geolocation every time. Test in a clean profile or private window.
• CDN and edge caching. A cached response from your earlier non-Japanese request can be served back to you; a cache-busting query string or a hard reload settles it.

For command-line work the header fix is one flag, and it should be part of every Japan test you run:

curl -s -x http://USERNAME-country-jp:PASSWORD@gw.pyproxy.com:1111 \
     -H 'Accept-Language: ja-JP,ja;q=0.9,en;q=0.5' \
     https://your-target.example/

Doing it at browser level

For anything visual — checking layout, fonts, a rendered price, a page that only assembles itself in JavaScript — you need a real browser through the same gateway, and you need its locale to match. Point the browser at the proxy first. Chrome takes the endpoint on the command line and will prompt for the credentials on the first request, since it does not accept them inside the flag:

chrome --proxy-server="http://gw.pyproxy.com:1111" \
       --user-data-dir="$HOME/chrome-jp-profile"

Then make the browser's own story match the address. Set the browser's preferred language to Japanese in settings, or in Firefox set intl.accept_languages to ja-JP, ja, en-US, en in about:config. Override the timezone to Asia/Tokyo: in Chrome DevTools the Sensors panel sets location, locale and timezone together, and for headless automation the cleanest route is the environment, TZ=Asia/Tokyo before launching, or the CDP call that sets the timezone override. In Playwright or Puppeteer, create the context with the proxy, locale: 'ja-JP' and timezoneId: 'Asia/Tokyo' in one go, so the three signals can never drift apart.

Finally, verify from inside the page rather than from the shell. Open the console on the target site and read what the site itself can read — Intl.DateTimeFormat().resolvedOptions().timeZone, navigator.language, navigator.languages. If those three come back Japanese and your exit address is Japanese, you are seeing the page as a visitor in Japan sees it, and any remaining difference is the site's own logic rather than your setup.

Questions people ask