Short answers
Does a changed IP prove the sticky session failed?
No. It proves the destination reported a different address for that request. Check the actual connection settings and error history before deciding whether the device, the session or only its address changed.
Can a sticky session expire while my job is running?
Yes. The configured session lifetime and your job’s duration are separate. Confirm the requested lifetime and how its timer is measured before using timestamps to infer expiry. The rotation and duration guide explains the settings and the connection builder’s limits.
Should I clear cookies after an address change?
Only if the application’s recovery procedure requires it. A changed IP does not automatically delete cookies or invalidate every application session. Check the application’s response and state before restarting. How HTTP cookies work.
Should a test fail when the address changes?
If an unchanged IP is a requirement of that test, detect the change and pause or fail it clearly. Otherwise, record the observation and test the application behaviour that matters. Neither equal nor different addresses alone identify the underlying device.
The device, not the address
A sticky session keeps the same device; the carrier may still change the IP. Device availability, session lifetime and address continuity are separate conditions. An echo check reports an address seen by the endpoint, not a device identifier or the complete route.
Compare the generated proxy configuration used by the actual worker, not only what the dashboard currently displays. Keep the account portion and password out of shared logs; use a non-sensitive job label to relate requests.
Check settings, lifetime and connection failures
Start with settings. Look for a session name generated inside a request loop, a different worker configuration, a pool or country change, or a client that used its environment instead of the intended proxy. If curl and the application disagree, follow the client configuration checklist.
Next, check lifetime. Record the session’s first use, recent activity and requested lifetime. Those timestamps cannot establish expiry unless you know whether the timer runs from creation or inactivity and what lifetime actually applied. Changing a ttl value on a live name is not a supported extension mechanism; use a separately configured name for a new session.
Then inspect failures around the change. A device or network interruption may make the previous route unavailable. A network may also change its public address while the device remains online. An IP comparison cannot distinguish those events. Keep timestamps and relevant error codes, and use CONNECT troubleshooting if tunnel establishment failed.
Getting the tokens right
- sid-<name>
- One to 64 lower-case letters, digits or underscores. No hyphen inside the value: a hyphen splits the token.
- rot-sticky
- use sticky mode together with the intended session name. Portproof’s public connection builder supplies a stable name when the session field is omitted; separate jobs should use deliberate names rather than rely on that shared fallback.
- ttl-<seconds>
- a gateway username setting for the requested lifetime. It is not a field in the public build-url JSON request. Keep duration setup in the rotation and duration guide.
Compare the full generated settings between the two requests. Reusing just the same session text does not establish that the remaining configuration stayed the same.
Write a job that survives a change
Decide whether the change affects the job’s requirement. If the job needs an unchanged IP, pause it and record the last completed step. If the application still works and unchanged IP was not required, do not discard its state merely because the address changed.
For a read-only check, you can retry within a small, defined budget after a delay. For a submitted form, purchase or other write, establish whether it already completed before repeating it. Follow the application’s idempotency and recovery rules. HTTP retry semantics.
Review whether the job needs a sticky session
If the requests are independent, the job may not need to retain a device between them. If they share application state, keep the intended session boundary and test recovery from interruptions. Choose a mode in the rotation and duration guide; changing modes is not a substitute for respecting the destination’s access rules and request limits.
Check what you actually got
Repeat the same small permitted endpoint from the actual client with the same complete proxy configuration. Record the timestamp, response status and the endpoint’s reported IP. If the endpoint returns JSON, compare its IP field rather than the whole response, which may contain other changing values.
Equal results do not prove device identity or future continuity. Different results do not identify the cause by themselves. Use the settings, timing, errors and application outcome together. The curl setup guide provides the connection syntax.
If the cause remains unclear, provide support with the time window, non-sensitive job label, pool, requested country, configured rotation, and error codes. Do not publish credentials or a complete proxy URL.
What is not allowed
Use sticky sessions for permitted work such as QA, ad verification and market research. Follow the acceptable-use policy.