Why your proxy ignores the country you set (and how to make it stick)

You set -country-de, run a check, and the exit comes back United States. It feels like the targeting was ignored. It almost never was. Choosing a country is a single field — there is a full walkthrough in targeting by country, city, or ASN — and when the result does not match what you asked for, the cause is usually one of a handful of specific, fixable things. Here they are, in the order worth checking.

You asked for something your plan cannot target

This is the quiet one. Every product accepts a different set of parameters, and asking for one a product does not support is not silently dropped — it rejects the entire username. Add -city- or -asn- to a Budget Unlimited username and the whole string is refused, country and credentials included, so you land on a 407 or a failed request rather than “US instead of Germany.” Match the parameter to the plan: country-level work runs on any rotating product, but city or ASN precision means Premium Unlimited or Residential / ISP. If you are unsure what your plan accepts, the per-product list is at the bottom of the targeting guide.

The country code is wrong, or spelled out

-country- wants a two-letter ISO code and nothing else. -country-de, not -country-germany and not -country-deu. A full name, a three-letter code, or a typo is not a valid target — and an invalid target is exactly where “I set Jordan and kept getting the US” comes from. Check the code against the real one (Jordan is jo, Germany de, the UK gb), and confirm the country is one we carry; the targeting docs list every supported code.

A sticky session is holding your last IP

If your username carries a -session- value, that string is a promise to keep the same IP. Change the country but keep the same session and you get exactly what you asked for the first time: the old IP, in the old country, until its TTL runs out. This is the one that looks most like the setting was ignored — because your new country genuinely is being overridden, by your own earlier request to hold the previous one. Change the -session- value (or drop it) whenever you change location. There is more on that trade-off in rotating or sticky.

The proxy is right — your own connection is giving you away

Sometimes the exit IP is perfect and the site still pins you to the wrong place. That is not the proxy; it is your own machine leaking its real location around it. Two usual culprits: WebRTC, which a browser can use to expose your real IP directly to a page even while every ordinary request goes through the proxy; and IPv6, where your device quietly reaches a dual-stack site over its own IPv6 address instead of the proxy. Our network exits on IPv4, so an unexpected IPv6 in a geo-check is a sign the traffic left your machine, not ours. Disable WebRTC in the browser (or use a profile that does), and confirm with a plain terminal request — it cannot leak the way a browser can. The test is below.

You are reading the wrong port, or a stale list

On Budget Unlimited, country lives per port: the list your dashboard generates bakes a country into each port’s username, so port 10000 might be Germany and port 10001 the US by design. If a request lands on a different port than you think, you get that port’s country, not the one you meant. And a list you exported last week will not reflect a change you made today. Regenerate the list from the dashboard after any change, and check the exact port your tool is actually connecting on.

That exact location is thin right now

Residential availability moves in real time. A common country is always there; a narrow target — a specific city, or a smaller country at an odd local hour — can briefly have little live supply, and a request that cannot be filled at that precision falls back rather than failing outright. If a city keeps missing, widen to country level, retry, or move the job to a product with deeper coverage for that geography.

The thirty-second test that tells you which one it is

Do not guess — read it. One terminal request against a service that reports the country it sees settles the whole thing. Swap in your username, password, endpoint, and port:

curl -x "http://user123-country-de:[email protected]:10000" https://ipinfo.io/json

Then look at the country field in the response:

• It shows DE — targeting works. Anything different inside your app is client-side: WebRTC, IPv6, or a session holding an old IP.
• A 407 or a rejected username — a parameter your plan does not accept, or a stray space in the suffix. Trim it back to -country-de and try again.
• A different country with 200 — check the session value and the port first; those two explain most of it.

Because the terminal cannot leak the way a browser can, a correct country here means the network is doing its job and the fix is on your side of the screen.

Country targeting is dependable once these are out of the way: a valid two-letter code, a parameter your plan actually supports, a fresh session when you switch locations, and a client that is not quietly talking around the proxy. Set those and the country you ask for is the country you get. The full syntax reference lives in targeting by country, city, or ASN.