Enterprise infrastructure. Zero compromises.

A pool gives you pinned sessions, not addresses you own: the longest hold is 24 hours, after which the IP returns to the pool. Build each profile around re-pinning — new session ID, same country, re-login if the site tied its cookie to the old exit. An IP you need for weeks is a different product.

Per profile

Unique -s- ID, fixed -cc- country

Pin ceiling

86400s, then a fresh IP

Parallel

Many sessions, one credential

Auth

user:pass, or whitelist up to 3 IPs

• Same ID inside the TTL resumes the same IP; a new ID gets a new one instantly.
• Keep session IDs alphanumeric — a hyphen is a delimiter and breaks the parse.
• The proxy changes the IP only; fingerprint and behaviour are still yours.

At volume the bill is set by what you fetch, not by how many pages you fetch: usage counts transferred bytes in both directions, and a fully rendered page often costs ten to twenty times a bare HTML request. Pilot around 1,000 requests against real targets, measure the per-request number, then size the buy.

Per page

HTML 50-200 KB, JSON 1-50 KB

Rendered

Often 10-20x a bare fetch

Output

Up to 50,000 lines per run

Protocols

HTTP, HTTPS CONNECT, SOCKS5

• Send Accept-Encoding: gzip, br and check the client actually decompresses.
• Skip the headless browser when the data is already in the HTML.
• Never fetch a URL twice inside its freshness window — cache raw responses.

Two modes in one run: rotating credentials for stock and release-calendar polling, a sticky session for the cart-to-confirmation path. The 60-second default pin is far too short for a checkout — 15 minutes is a sensible floor — and every task gets its own session ID.

Monitors

Rotating, one IP per request

Checkout

Sticky, -ttl-900 or longer

Ceiling

-ttl-86400 (24 hours)

Region

-cc- matched to billing country

• Poll at a rate you would defend in public; volume is abusive whatever the IP.
• Two tasks sharing one IP read as one very strange shopper.
• Orders get cancelled days later — a proxy prevents none of that.

Targeting and stickiness live in the username, so one set of credentials drives dozens of profiles in parallel — same password, a different suffix each. Keep every profile's country and session ID stable, and check the exit before you act rather than assuming the pin survived.

Per profile

-cc- country plus -s- session ID

Hold

60s default, 86400s maximum

Password

Never changes; only the username

Check

Checker: IP, country, latency

• One credential set, one suffix per account — no separate logins to manage.
• Rotating mid-flow logs you out: the cookie was issued to the first IP.
• Re-pin with a new ID after a drop; never revive a dead session's ID.

Search results, ad slots and prices are computed per country and often per city, so one vantage point audits one market. Point the same query at each market by changing the username suffix and read the page a local resident is served. Once or twice a day per market catches what matters.

Markets

195+ countries, city where needed

Precision

-cc- -ct- -st- -pc- -dma- -gid-

Cadence

1-2 sweeps per market per day

Sequences

-s- pin for consent, then page two

• Use the broadest filter that answers the question; narrow pools rotate less.
• Prefer an official API where one exists for ranking data.
• Postal codes with a space or hyphen cannot be encoded — target the city.

SOCKS5 forwards arbitrary TCP, so test traffic that is not HTTP runs over the same endpoint and the same credentials as everything else — only the scheme in the proxy URL changes. Throughput between the two is a wash; the exit link dominates. Choose whatever your tooling supports best.

Endpoint

One host, port 80, all schemes

SOCKS5

Any TCP; client picks where DNS runs

HTTP

Carries HTTPS via CONNECT

Targeting

Identical suffixes under both

• Give every worker its own -s- ID so a failure is one IP, not the whole fleet.
• Verify a sample in the checker before pointing production traffic at it.
• Targeting is fail-closed: one bad value 401s the entire username.