The lifetime token holds the exit
Sticky mode on a Proxynade pool lives in the username string, not in a separate flag. The lifetime-<minutes> token tells the gateway to route every request carrying that exact username through the same exit for the duration. The gateway is http://proxynade.net:2555 with username and password auth — the host and port do not change between rotating and sticky mode.
A Volume Residential sticky username looks like this:
rt97db6958d9-plan-volume-country-us-lifetime-30Breaking that down: base username, plan token (volume, premium, or datacenter), optional country code, rotation window in minutes. Datacenter lines skip the lifetime token. The password is unchanged.
A mistyped or URL-encoded username is the most common reason a sticky window silently fails. Check the string character-for-character before adjusting anything else.
Verify the exit holds before running the real flow
Before running the actual workflow, hit an IP echo endpoint three times with the same credentials and a pause between calls. The returned address should stay constant for the full window duration.
curl -x "http://rt97db6958d9-plan-volume-country-us-lifetime-30:PASS@proxynade.net:2555" https://httpbin.org/ip
curl -x "http://rt97db6958d9-plan-volume-country-us-lifetime-30:PASS@proxynade.net:2555" https://httpbin.org/ip
curl -x "http://rt97db6958d9-plan-volume-country-us-lifetime-30:PASS@proxynade.net:2555" https://httpbin.org/ipIf the IP changes on the second call, the username is wrong or the window already expired. If it stays constant, the sticky side is working and any subsequent failure is in the workflow logic or the target.
If the client resolves hostnames locally before the proxy sees them, test socks5h:// separately rather than changing session mode, country, duration, and protocol in the same run. One variable at a time.
Read a failing trace before changing the window
A trace like this is common when a sticky session breaks partway through a workflow:
09:14 echo 200 exit kept
09:16 step-one 200 180 KB
09:22 step-two 200 940 KB empty parse
09:23 retry 429 5 KB
09:25 echo 200 exit changedThe exit changed at 09:25, but the empty parse at 09:22 needs its own investigation. A stale selector or a changed page structure produces the same symptom on a perfectly good sticky session. The 429 could be pacing, target rate limiting, or retry logic firing too fast. A 407 in that trace points directly to credentials or line format.
Open the dashboard usage logs for those rows. Each entry shows host, plan, protocol, outcome, HTTP status, latency, and provider-metered bytes. Read those before concluding the sticky window was the cause.
Window length is a timing decision, not a safety margin
Time the clean path end-to-end. A seven-minute form on a five-minute sticky window is a misconfigured test, not evidence that the target blocked the route. Add a realistic retry buffer to the measured time, then set lifetime-<minutes> to that total.
A longer window is not free. The proxy meter counts every byte transferred: scripts, fonts, images, redirect chains, blocked pages, partial transfers, and responses the application discards. Application-level counters read low because they only count states the app kept. Check provider-metered bytes from the usage logs against what the app actually retained before extending the window or moving the sequence to a more expensive plan.
When the sequence finishes, start a fresh session. Carrying an old sticky window into the next job inflates byte costs with no benefit.
Stateless requests don't need sticky
Public catalog reads, price checks, and broad SERP pulls have no state to carry between steps. Rotating mode is the right default for those. Keep sticky for sequences where step two depends on something established in step one — a session cookie, a form token, a server-side state that ties to the originating IP.
If nobody can point at a specific step that breaks after rotation, rotating mode is correct. Sticky adds cost without benefit when the workflow doesn't actually require exit continuity.
Sticky session FAQ
How do I keep the same exit IP across multiple requests? Add a lifetime-<minutes> token to the username: rt97db6958d9-plan-volume-country-us-lifetime-30. Every request using that username string within the window routes through the same exit.
Why does my sticky session drop mid-flow? Three causes cover most cases: the window expired before the flow finished, the username string changed between requests (typo or encoding), or the client opened a second connection that didn't carry the same username.
How long should I set the sticky window? Time the clean path end-to-end, add a buffer for retries, then set the lifetime token to that total. A window shorter than the actual flow is the most common sticky-session misconfiguration.
Does Proxynade bill bytes during a sticky session even for failed requests? Yes. The proxy meter counts every byte transferred regardless of HTTP status. The dashboard usage logs show host, outcome, latency, and byte totals per request.
When should I not use sticky sessions? Stateless collection — price checks, public catalog reads, broad SERP pulls — doesn't need a fixed exit. Use rotating mode and save the sticky window for sequences where page two depends on state from page one.
Pre-flight checks
- Confirm the username string is exact — no URL encoding, no extra characters.
- Run an IP echo three times before starting the real flow.
- Time the full workflow before setting the window duration.
- Read usage-log bytes, not just application-level counts.
- Close the sticky session when the workflow finishes.