Session mode lives in the username, not the port
The gateway is proxynade.net:2555 regardless of which session mode you want. What changes is the expanded username. Omit the lifetime token and every connection gets a fresh exit. Add lifetime-<minutes> and connections from the same identifier share a route for that window. Changing the port number does nothing to session behavior.
# Rotating: new exit per connection
http://rt97db6958d9-plan-volume:PASSWORD@proxynade.net:2555
# Sticky 30-minute window
http://rt97db6958d9-plan-volume-lifetime-30:PASSWORD@proxynade.net:2555
# Sticky with country pin
http://rt97db6958d9-plan-volume-country-us-lifetime-30:PASSWORD@proxynade.net:2555Datacenter lines use the datacenter plan token; they accept the lifetime token only as part of a sticky session. HTTP, HTTPS, SOCKS5, and socks5h all point at the same host and port.
Rotating mode fits stateless collection
Rotating mode changes the upstream exit on every new connection. The target sees a different IP each time, and nothing carries over between requests. That is the right default for price checks, broad catalog reads, and SERP pulls, any workload where each request is independent and there is no server-side state to maintain.
If a request in rotating mode gets a block, the next connection is already on a different exit. No manual reset required.
Sticky mode covers short stateful flows
A sticky session maps a session identifier to an upstream route for the duration of the lifetime window. Same identifier, same route. Different identifier, different session. This matters when the target carries state across requests: a login cookie, a cart, a queue position, a server-side session that tied itself to the originating IP.
Set the window to cover the full flow with margin. A 15-minute checkout flow running under a lifetime-10 token will hit a new exit mid-session and break the state the previous requests established.
| Mode | Exit behavior | When to use |
|---|---|---|
| Rotating | New exit per connection | Stateless collection: price checks, catalogs, SERPs |
| Sticky (lifetime-N) | Same exit for N minutes per identifier | Short stateful flows: logins, multi-step forms, short sessions |
| Hard session | Same IP until released or unavailable | Long route continuity where window expiry is unacceptable |
Hard sessions trade flexibility for continuity
A hard session pins the same upstream IP until that IP is released or becomes unavailable. There is no expiry window. This suits workflows that genuinely need the same exit across many requests over a long period, where a mid-session exit change would break the workflow regardless of how long a sticky window is set.
The cost is that a pinned route showing weak responses does not self-correct. If the exit starts returning soft blocks, the session stays there until you release it. Monitor the dashboard network log for host, outcome, latency, and byte totals when running hard sessions over time.
One identifier per worker, always
Sharing a sticky identifier across unrelated workers makes the usage logs unreadable. There is no way to trace which worker drove which traffic, which session caused a block, or which exit was responsible for a billing spike. Give each worker its own identifier. The dashboard network log exports as CSV if you need to join it against your own records.
When a run looks expensive, compare the usage log against the app-side counter. The proxy meter counts redirects, failed TLS handshakes, blocked responses, and retried requests that the app layer never surfaces. The gap is expected, since the proxy still transferred those bytes.
Session mode FAQ
What controls session mode on Proxynade? The username token. Omit the lifetime token for rotating mode. Add lifetime-<minutes> for sticky. The gateway and port stay the same: proxynade.net:2555.
How long can a sticky session last? Up to the number of minutes in the lifetime token. When the window expires, the next connection gets a new exit. Datacenter lines use the lifetime token only inside a sticky session.
What is a hard session? A hard session pins the same upstream IP until that IP is released or becomes unavailable. It is longer-lived than a standard sticky window and suits workflows that need route continuity across many requests.
When should I use rotating mode? For stateless collection where each request is independent: price checks, catalog reads, SERP pulls. If the target does not need the next request to share state with the previous one, rotating mode is the right default.
Why do usage logs show more bytes than my app counter? The proxy side counts redirects, failed TLS attempts, blocked responses, and retried requests that the app layer never surfaces. The dashboard network log shows host, outcome, latency, and byte totals per request.
Can I share one sticky identifier across multiple workers? Technically yes, but it makes the logs unreadable. Unrelated workers sharing one identifier make it impossible to trace which worker drove which traffic or which session caused a block.
Decision checklist
- Each request independent of the last? Use rotating mode.
- Target carries state across requests? Use sticky with a window longer than the full flow.
- Long-running workflow where window expiry is unacceptable? Use a hard session.
- One identifier per worker, never shared across unrelated work.
- Check the dashboard network log when a run's byte total looks wrong.