Country goes in the username, not the URL
The gateway endpoint is always proxynade.net:2555. Country selection is encoded in the username, after the plan token: base-user-plan-volume-country-us. The password is unchanged. Nothing about the host or port changes between countries.
The full username structure: base username, required plan token (volume, premium, or datacenter), optional country-<cc>, optional lifetime-<minutes> rotation window. Datacenter lines skip the lifetime token. A US volume residential line with a 10-minute rotation window looks like this:
# HTTP — US exit, volume residential, 10-minute rotation window
http://rt97db6958d9-plan-volume-country-us-lifetime-10:password@proxynade.net:2555
# SOCKS5 with remote DNS — Germany exit, premium residential
socks5h://rt97db6958d9-plan-premium-country-de:password@proxynade.net:2555HTTP, HTTPS, SOCKS5, and socks5h all hit the same host and port. socks5h resolves DNS through the proxy side, which is usually what you want for geo-sensitive targets. SOCKS5 is specified in RFC 1928.
One route test before the full job
Run one request through the new line before scaling. A geo check at this stage takes seconds and confirms the token parsed correctly. The typical test is a small IP-lookup endpoint — enough to read the exit country, not enough to burn bandwidth.
# curl: one request, read the exit IP and country
curl -x http://rt97db6958d9-plan-volume-country-de-lifetime-10:password@proxynade.net:2555 \
https://ipinfo.io/jsonIf the country field in the response matches the country-<cc> token, the line is working. If not, check the token spelling before touching anything else.
Wrong-country exits almost always trace to stale workers
A worker that ran a US job carries session state: the credential string, possibly a DNS cache, retry queues, open connections. Reassigning the country in config without restarting the worker leaves the old credential active. The geo check shows the wrong country because the worker is still using it.
The fix is mechanical: regenerate the line for the new country in the dashboard, copy it whole into the worker config, restart the worker, and run one clean geo check. Patching the old username by hand introduces typos and missed tokens.
Keep country lines split by worker. A single worker switching countries mid-run is harder to debug than two workers, each pinned to one country from start to finish.
Verify routing in the dashboard logs, not just the app
An IP-lookup endpoint confirms the exit IP. The dashboard network log confirms what the proxy layer actually did. Each row shows host, outcome, latency, and byte totals. If the plan column shows datacenter when you expected residential, that is a credential issue, not a pool coverage issue.
App-side byte counters are narrower than proxy-side ones. The proxy counts redirects, challenge pages, blocked responses, retried connections, and discarded bodies. The app usually counts only what made it into useful output. A job that looks small in the app can look much heavier in the logs for that reason.
The usage logs export as CSV from the dashboard. For debugging a mis-routed job, filter by time range and look at the plan, protocol, status, and latency columns together. A wrong plan or a protocol mismatch is a faster diagnosis than changing the country token repeatedly.
Datacenter country targeting behaves differently
Datacenter lines accept country-<cc> in the username, but the exit is a hosting-network IP, not a residential one. Geo databases classify these as datacenter ASNs (see the IANA ASN registry), and targets that check ASN type will see that regardless of which country is set. Use datacenter targeting when the job needs speed and datacenter IP class is acceptable; use Volume or Premium Residential when the target checks IP type.
If the dashboard does not show a country as available on the selected plan, editing the exported username is not a workaround. The routing pool must cover that country on that plan.
Country filtering FAQ
Where does the country code go in a Proxynade proxy URL? In the username field, after the plan token: base-user-plan-volume-country-us. The host and port stay the same for every country.
Can datacenter proxies target a country? Yes, with country-<cc> in the username. Datacenter lines skip the lifetime token. The exit is still a hosting-network IP, not a residential one.
Why does the geo check return the wrong country? Most wrong-country reports trace to a stale worker still using an old credential. Regenerate the line, restart the worker, and run one clean geo check before the full job.
How do I confirm which country a request actually exited through? Check the network log in the dashboard. Each row shows host, outcome, latency, and byte totals. An IP geo endpoint alone is not enough — the log shows what plan and credential the proxy used.
Does the country token work with SOCKS5? Yes. HTTP, HTTPS, SOCKS5, and socks5h all point at proxynade.net:2555. The country token is in the username regardless of protocol.
Setup checklist
- Generate the full line in the dashboard; do not patch old credentials by hand.
- Confirm the plan token matches the pool you intend:
volume,premium, ordatacenter. - Run one geo-check request before the full job.
- Restart any worker that previously ran a different country.
- Cross-check the dashboard log — plan, protocol, status, and latency — not just the app output.