← Blog · · 5 min read

Country Targeting with Residential Proxies: A Practical Guide

Country targeting lets an application request a residential exit associated with a particular country. It is useful when public content, prices, search results, availability, or compliance notices differ by location—but a reliable implementation requires more than appending a country code and assuming every downstream signal will agree.

This guide covers PacketStream’s targeting syntax, validation, failure behavior, and the boundary between supported country selection and approximate IP geolocation.

How PacketStream country targeting works

Append _country- and a two-letter ISO country code to the auth key. For a United States exit:

AUTH_KEY_country-US

PacketStream recommends uppercase, two-letter ISO codes such as US, GB, DE, JP, and BR. The proxy host and recommended HTTPS port remain the same:

proxy.packetstream.io:31111

If no exit is available for the requested country, the request fails. PacketStream does not silently route that request through a different country. This is important because an apparently successful response from the wrong country can corrupt a localized dataset more quietly than an explicit failure.

Make the requested country part of the job

Store the target country alongside the URL, parser version, and collection time. Do not hide it in a global proxy string that every worker shares.

A simple job record might contain:

{
  "url": "https://example.com/public-page",
  "country": "DE",
  "collection": "catalog-monitor",
  "attempt": 1
}

At execution time, validate the country against the allowlist your application supports and build the auth key. This prevents malformed or user-supplied values from becoming part of a proxy credential.

Validate the observed country

An inspection endpoint can confirm that the connection is using a proxy and report its approximate location:

curl --silent --show-error --fail-with-body \
  --proxy 'https://proxy.packetstream.io:31111' \
  --proxy-user 'USER:AUTH_KEY_country-DE' \
  'https://ipinfo.io' \
  | jq '{ip, country, region, city, org}'

For a country-targeted test, assert the country field. Treat city, region, postal code, and coordinates as approximate metadata rather than additional targeting guarantees. IP geolocation databases can differ, update at different times, and assign a nearby administrative location.

The destination itself may also use a different geolocation provider than your test endpoint. Keep that uncertainty in mind when a site and an inspection service disagree at the city level.

Country targeting is not localization by itself

Websites use more than an IP address to choose content. A response can also depend on:

  • Accept-Language and other request headers;
  • cookies from an earlier visit;
  • account or profile settings;
  • the hostname or top-level domain requested;
  • currency and locale parameters in the URL;
  • browser storage and device settings.

If a job expects German-language content, for example, define whether the requirement is a German residential exit, German language headers, a specific localized URL, or all three. Otherwise a correct proxy result can be misclassified as a failure.

Combine a country with rotation or stickiness

Country targeting narrows the eligible exit pool. Session behavior determines whether the application changes exits between connections.

For independent requests, use the country suffix and allow automatic rotation to select a qualifying exit for each new proxy connection:

AUTH_KEY_country-GB

For a multi-step workflow that must stay on one exit, add a session identifier:

AUTH_KEY_country-GB_session-checkout42

Sticky sessions can retain an exit for up to 60 minutes. If the associated Packeter disconnects, the session fails. The application should then decide whether restarting the complete workflow with a new session is safe.

Handle unavailable countries explicitly

Availability changes as residential devices connect and disconnect. A country with a large pool at one moment can still produce a transient failure, and a small pool may be unavailable when a job runs.

Use a bounded retry policy for safe, idempotent requests. Preserve the requested country across retries and record a distinct no eligible exit outcome when possible. Do not fall back to a different country unless the product requirement explicitly allows it and the resulting data is labeled accordingly.

For scheduled collections, consider a queue state such as:

  • complete: the requested country was validated and the page was parsed;
  • retryable: the request failed before a usable response;
  • unavailable: no eligible country exit was available within the retry window;
  • invalid: the requested country code was not in the application’s allowlist.

This is more useful than storing every failure as a generic timeout.

Use the same targeting modifier with SOCKS5

When a client requires SOCKS5, keep the country modifier in the auth key and use port 31113:

curl --proxy 'socks5h://proxy.packetstream.io:31113' \
  --proxy-user 'USER:AUTH_KEY_country-JP' \
  'https://example.com/'

Design for trustworthy localized data

A robust country-targeted job records three things separately: what it requested, what it observed, and what the destination returned. That provides enough context to distinguish proxy availability, geolocation disagreement, and real content changes.

Use country targeting for legitimate localization, public-data collection, and content verification. Respect destination terms, rate limits, privacy obligations, and applicable law. A residential exit changes the network path; it does not remove the responsibility to collect data appropriately.

To test the behavior before integrating it into a larger pipeline, follow the cURL residential proxy checklist and validate the country on every test run.

More articles Try PacketStream