Rotating Unmetered Proxies: Stateless, Sticky and Queued Patterns

Three ways to use Node4 Rotating Unmetered, by connection pattern, not billing unit, with a worked connection-sizing calculation.

Best overall for independent requests: stateless rotation. Best for short, stateful workflows: sticky-session rotation. Best for multiple jobs sharing one allowance: a rotating endpoint behind a shared concurrency queue. This guide compares three ways to use Rotating Unmetered, Node4's connection-priced rotating product, not provider rankings.

TL;DR

• Rotating Unmetered suits independent requests without gigabyte-based billing; size it by concurrent connections, not data moved.
• Choose sticky sessions when cookies and exit identity must stay together during a short workflow.
• Use a shared concurrency queue when several projects consume the same connection allowance.
• No byte meter does not establish an uncapped throughput, an uncapped connection count, or assured target acceptance.

What "unmetered" changes, and what it doesn't

Unmetered describes traffic accounting: no gigabyte counter, no per-byte charge. It does not tell you how many requests your application can complete, how rotation works, or whether a target accepts a datacenter address. Those are separate decisions, and how rotating proxies work covers the rotation model this guide assumes.

The comparison below is three ways to deploy Rotating Unmetered, not three vendors or invented subscription tiers. Choose the connection pattern first, then size the plan. For how Rotating Unmetered's connection price compares with a per-GB plan, see unmetered rotating versus per-GB and what each provider's unmetered plan actually caps; this guide does not repeat that billing comparison.

What makes the best fit for Rotating Unmetered

• Connection accounting: Establish what consumes a concurrent connection, including idle connections and browser traffic. Size your workers against that definition.
• Rotation behavior: Verify when an exit changes. A new HTTP request, a new TCP connection, and an expired session are different events.
• Session continuity: Match exit persistence to the workflow. Cookies alone do not preserve network identity.
• Location coverage: Confirm the actual datacenter countries. Do not borrow the residential product's country count.
• Useful throughput: Measure completed, valid responses rather than counting every attempted request as useful work.
• Traffic terms: Read the applicable throughput and acceptable-use conditions as a separate limit from the byte meter.

A bandwidth label without connection accounting leaves you unable to size the application. A rotation claim without a trigger leaves you unable to predict session behavior.

Three connection patterns at a glance

The table compares application behavior, not measured provider performance. It does not rank latency, acceptance rate, or throughput, because those require workload-specific measurements.

1. Stateless rotation: best for independent page fetches

Stateless rotation fits requests that remain useful without a preceding login, cookie exchange, or persistent exit address. Each fetch should stand alone. A failed request can enter a controlled retry queue without carrying another task's state.

Best for: Public-page collection where individual requests do not depend on a stable network identity.

This is the default pattern to assess for a large collection of independent URLs. Keep concurrency bounded, validate the returned content, and record the exit behavior separately from the target response. Do not assume a different request automatically means a different exit.

Pros: independent tasks distribute across workers without replaying a session; cookie isolation is simple when requests genuinely need no shared state; connection usage is controlled centrally.

Cons: changing exits conflicts with workflows that expect stable identity; rotation does not make a datacenter address residential; successful proxy authentication does not establish target acceptance.

The practical limit is valid output, not traffic consumed. A response that contains a challenge page instead of the requested document should fail your content checks, even when the transport succeeded. Use representative target pages and the intended request headers, then compare the actual response structure against an expected schema or marker.

Verdict: use it for independent requests after target validation. Skip it when a workflow requires persistent exit identity.

2. Sticky-session rotation: best for short, stateful workflows

Sticky-session rotation groups related requests under one exit assignment. It suits workflows in which cookies, session tokens, and network identity need to remain aligned while you complete a sequence.

On Node4's rotating gateway, a sticky session holds one exit for up to 30 minutes from first assignment. The clock does not restart with the latest request, so a task that waits between steps can still run out of session.

Best for: Short workflows that require exit continuity and can finish within the sticky-session window.

Create a separate application session for each workflow. Keep its cookie jar and proxy session id together, and store the first-assignment timestamp beside the workflow state rather than the last-request time, so you know how much of the window is left.

Pros: related requests retain one exit assignment; session boundaries can match application workflow boundaries; separate cookie jars reduce accidental state sharing.

Cons: the window is not indefinite exit persistence; waiting between requests still consumes elapsed session time; a task that outlasts the assignment needs a defined recovery path.

Plan recovery before starting a stateful job: whether an expired workflow can restart safely, whether an action is repeatable, and whether duplicate execution causes a problem. Retrying the last request blindly is not a recovery strategy.

Verdict: use it for bounded, stateful workflows. Skip sticky sessions as a substitute for a permanently static proxy; nothing on the rotating gateway holds past the window.

3. Shared concurrency queue: best for multiple collection projects

A shared concurrency queue puts a scheduler between your jobs and the rotating endpoint, admitting work only while connection capacity remains. This is an application architecture, not a separate proxy product.

Best for: Data teams and agencies running several projects against one Rotating Unmetered allowance.

Rotating Unmetered is sold by concurrent connections, not gigabytes, and a connection allowance is not a fixed count of distinct addresses either. Several applications sharing one allowance need coordinated admission control; separate per-application worker limits do not create a shared global limit on their own.

Pros: one admission point enforces the aggregate connection budget; per-project queues stop one job consuming every worker; central scheduling makes retries and backpressure easier to inspect.

Cons: the queue adds scheduling and operational work; a global limit alone does not protect individual target domains; long-running tasks still need explicit timeout and cancellation behavior.

Run a global concurrency limit alongside per-target controls. They serve different purposes: one protects your purchased connection allowance, the other controls pressure on a destination, and neither establishes permission to collect data. A worker count is not automatically a connection count either, particularly with browser automation or clients that hold a connection pool; instrument actual client behavior before mapping workers to the subscription limit.

Verdict: use it when multiple projects need coordinated access. Skip the extra architecture for a single simple job that already has effective connection controls.

Verify routing before increasing concurrency

Use your own authorized test URL and the endpoint supplied with your account. The example below deliberately contains no guessed hostname, port, username format, or session syntax; enter those from your actual configuration.

read -r -p 'Proxy URL, including scheme and port: ' PROXY_URL
read -r -p 'Proxy username: ' PROXY_USER
read -r -s -p 'Proxy password: ' PROXY_PASS
printf '\n'
read -r -p 'Authorized test URL: ' TEST_URL

curl \
  --proxy "$PROXY_URL" \
  --proxy-user "$PROXY_USER:$PROXY_PASS" \
  --silent --show-error --fail \
  "$TEST_URL"

unset PROXY_PASS

The command tests an authenticated request through the endpoint you enter. It does not establish rotation frequency, available capacity, or target compatibility; use a test destination that reports the observed source address when you need to check the exit. Command-line credentials can be visible through local process inspection, so run this in a controlled environment and keep secrets out of shared logs.

Inspect transport errors separately from content errors. An authentication failure belongs in proxy configuration troubleshooting; a valid transport response containing unexpected content belongs in target-response validation. Combining them into one failure counter hides the next action.

Size connections with explicit assumptions

Start with a deliberately small test. Assume 4 concurrent requests, each occupying one connection for an average of 2 seconds. Under those assumptions, the theoretical completion rate is 2 requests per second before retries, scheduling gaps, or other limits:

completion rate = occupied connections / average occupancy time

That is arithmetic, not a service benchmark, and it stops applying the moment a logical task opens several connections or holds one after the useful request finishes. Record completed valid responses, elapsed time, occupied connections, retries, and transferred bytes, and keep the target mix consistent between runs, or a change in page size can look like a proxy improvement.

Do not increase concurrency while useful output stays flat and failures rise. Identify first whether the constraint is destination throttling, local CPU, connection handling, or the proxy service; more workers only help a shortage of admitted work. A retry consumes a connection slot even when it produces no new data, so fix an authentication error, an expired session, or an invalid content check before buying more connections.

Geography is a separate check from the meter

The datacenter, shared, and rotating datacenter products run on owned IP blocks in three countries: the United States, Italy, and Spain. Residential coverage is a separate product sourced from an upstream supplier; do not apply residential geography to a Rotating Unmetered purchase.

Choose a location because it matches the task's geographic requirement, then verify the observed exit against a geolocation source relevant to your project. A country selection alone does not prove how every destination classifies an address, and owning the infrastructure does not determine target acceptance; treat ownership, location, rotation, and successful collection as separate checks.

Which pattern should you choose?

Start with stateless rotation unless the workflow requires continuity. Add sticky sessions only for related steps that need one exit assignment. Add a shared queue when multiple jobs compete for connection capacity.

Keep those decisions separate: a queue can schedule sticky or stateless work, and a sticky session does not remove the need for concurrency limits. The cleanest setup is the least complicated one that satisfies the actual workflow. Rotating Unmetered plans start at $29.00/month for 250 connections ($0.116 per connection).

FAQ

What's the best setup for Rotating Unmetered?

Stateless rotation is the default for independent requests. Choose sticky sessions when related requests need one exit assignment, and a shared concurrency queue when several projects compete for capacity.

Does an unmetered plan mean an uncapped number of concurrent connections?

No. The byte meter and the connection count are different limits. Rotating Unmetered sells a fixed number of concurrent connections, so size your application against that allowance rather than treating it as open-ended.

How long does a sticky session keep the same exit on Node4's rotating gateway?

Up to 30 minutes from first assignment, not from the latest request. Store the assignment time, not the last-request time, when deciding whether a workflow is still inside the window.

Is Rotating Unmetered available in the same 170+ countries as residential?

No. Rotating Unmetered's owned datacenter blocks are in the United States, Italy, and Spain; the 170+ country figure belongs to the separate residential product.

Do rotating proxies stop a target from blocking a request?

No. Changing the exit address does not make a destination accept the request. Validate returned content and respect destination access requirements regardless of the network path.

How many workers should I run against one connection allowance?

Set worker concurrency from the connection allowance and measured client behavior, not from a round number. A browser or a pooled HTTP client can hold connections differently from a simple single-request worker.

Related guides

• Choosing a US proxy: network type and exit verification
• How long does a rotating proxy keep the same IP address?
• What each provider's unmetered plan actually caps
• aiohttp to high-concurrency async scraping
• Rotating Unmetered plans