IP rotation and web sessions: what changes and what stays

HTTP itself is stateless, but cookies let a server relate subsequent requests. Their scope and lifetime are controlled by separate attributes.

Build four tests: same IP with existing cookies, new IP with existing cookies, same IP with a clean context, and new IP with a clean context. Compare sign-in, cart state, CSRF protection, and server session identifiers. This matrix reveals which signal actually affects application behavior.

A new connection receives a different outbound address. Existing connections may end, so the application should recover and confirm the new address.

Before rotation, close or mark long-lived WebSocket and streaming connections. After the command, measure time to the next successful connection and transient error count. The UI should distinguish expected reconnection from failure and must not offer another paid operation while the outcome is being verified.

Measure the address before rotation, perform the authorized change, wait for confirmation, and test again in the same context. Repeat separately in a clean context.

Run the post-check through a new TCP session and at least two authorized targets. Confirm the address changed, the current connection no longer uses the old address, and credentials remain consistent. If evidence is ambiguous, retain a verifying state instead of declaring success.

Do not repeat a paid or state-changing operation merely because of a network timeout. Verify the actual server-side outcome first.

Assign one operation ID and a lock scoped to the specific lease rather than a global queue for all customers. Repeated clicks return the current state of the same operation. A client timeout must not create another command; the worker or direct handler first verifies the address change before finalizing the record.