The country token goes in the username
On Proxynade, country targeting is a username option, not a separate endpoint. The gateway stays at http://proxynade.net:2555. The expanded username carries the plan token and the country-<cc> segment. A Volume Residential connection targeting Germany looks like this:
http://rt97db6958d9-plan-volume-country-de:password@proxynade.net:2555For US, substitute country-us. For Brazil, country-br. The plan token is required: volume, premium, or datacenter. Datacenter lines skip the lifetime token. Residential lines accept an optional lifetime-<minutes> token to hold one exit IP for the duration of a session.
A country-targeted rotating residential proxy still rotates. It does not become a static IP in that country. It routes exits through that country — selecting peers announced via BGP (RFC 4271) from ASNs registered in that region — and the exit changes on the next rotation window. If you need the same IP for days, use a Static ISP proxy instead.
The country code does not fix browser state
This is the exact thing that ruins geo runs: the proxy route is right, but the browser profile is not. The country-de token routes the exit IP through Germany. It does not set Accept-Language: de-DE, adjust the timezone, clear old cookies, or change stored currency choices from the previous session.
On a geo QA run covering US, DE, BR, and JP, two German rows had an old English browser profile active. One Brazil row carried a consent state from the previous day. The proxy log showed valid German and Brazilian exits. The screenshots showed the wrong locale. The proxy was doing its job. The rest of the browser state was not.
Treat the exit IP and the browser profile as two separate things that both need to be correct before a row is accepted.
A row is not proven by its filename
Saving a screenshot as geo-audit-019/DE/row-042.png does not make it a valid German row. The columns that matter are:
| Column | What to record |
|---|---|
| Requested country | The country-<cc> token used in the username |
| Geo echo country | Country returned by an IP lookup before the page fetch |
| Exit IP hash | Hash of the actual exit IP — confirms rotation happened |
| Browser profile | Which locale profile was active for this row |
| Cookie jar | Which cookie state was loaded |
| Status | HTTP status from the target |
| Provider bytes | Bytes from the provider log, not the scraper counter |
| Accepted | Yes/no flag after all columns are verified |
Keep the geo lookup beside the capture it belongs to. A separate lookup file stops proving much once reruns and partial fixes start mixing rows from different passes.
The scraper byte counter is optimistic
The scraper counts accepted responses. The provider meter counts every transferred byte. On a run of 76 landing pages across four countries with 231 accepted captures:
run: geo-audit-019
targets: 76 landing pages
countries: US, DE, BR, JP
accepted captures: 231
scraper counter: 0.41 GB
provider meter: 0.66 GB
dropped reasons: consent_loop, stale_cookie, wrong_locale, 403The 0.25 GB gap came from redirects, consent loops, blocked responses (including 403 responses), and rows the parser dropped before the final export. None of that traffic appeared in the scraper's tally. The provider dashboard network log shows host, outcome, latency, and byte totals per request. Usage logs export as CSV. Those numbers are the real cost baseline.
That gap matters when choosing between Volume Residential at $0.89/GB and Premium Residential at $5.00/GB. Start with Volume Residential when the target is forgiving and broad country coverage is enough. After the log shows which segments are wasting rows on blocks or wrong-locale responses, move those segments to Premium Residential. Starting with Premium everywhere does not fix a bad run manifest.
Sticky sessions and when country rotation is the wrong tool
Plain country rotation is correct for price monitoring, ad verification, local SERPs, regional landing pages, and marketplace availability checks. It is not the right tool for multi-step account flows or any work that requires the same exit IP across multiple requests separated by minutes.
For a short flow that needs one exit for the duration, add lifetime-<minutes> to the username. A 30-minute sticky window for Germany:
http://rt97db6958d9-plan-volume-country-de-lifetime-30:password@proxynade.net:2555For work that needs the same exit for days, a Static ISP proxy is the right answer. Rotating residential, even with a lifetime window, is not guaranteed to return the same IP across separate sessions.
A tight country filter also reduces the available exit pool, which can increase latency and retry rates. Do not add country-<cc> to runs that do not need it.
Validate one route before scaling
Run one country first. Check the geo echo, the browser locale, the cookie state, and the provider byte cost against what the scraper reported. If any of those are wrong, scaling the run hides which part failed and makes the provider meter harder to explain.
The checklist before accepting a row: the geo echo returns the requested country, the browser profile matches the locale, the cookie jar is from the right session, and the byte total comes from the provider log.
Country targeting FAQ
How do I target a specific country on Proxynade? Add country-<cc> to the expanded username. For Germany: base-user-plan-volume-country-de:password@proxynade.net:2555. The gateway and port stay the same.
Does a country-targeted rotating proxy stay on one IP? No. It rotates through exits in that country. Add a lifetime-<minutes> token for a sticky window, or use a Static ISP proxy for multi-day persistence.
Why does my scraper byte count differ from the provider log? The scraper counts accepted responses. The provider meter counts every transferred byte: redirects, consent loops, blocked responses, and failed rows all add up on the provider side.
When should I use Premium Residential instead of Volume Residential for country targeting? Start with Volume Residential at $0.89/GB. Switch the segments with high block or wrong-locale rates to Premium Residential at $5.00/GB after the log shows the cheaper route is wasting rows.
Does the country token fix Accept-Language or timezone? No. The country token routes the exit IP. Browser locale, Accept-Language header, timezone, and stored cookies are separate and must be set in the browser profile.
Run checklist
- Country code in the username, not a separate endpoint.
- Geo echo recorded per row before the page fetch.
- Browser profile and cookie jar logged beside each capture.
- Bytes read from the provider dashboard, not the scraper counter.
- Validate one route before running the full manifest.
- Use
lifetime-<minutes>for short sticky flows; Static ISP for multi-day work.