Skip to content
bytetouristbytetourist

Sessions & sticky IPs

Some workflows need the same IP across several requests — logging in, paginating behind a session cookie, or completing a checkout. bytetourist supports this with session affinity.

How it works

Section titled “How it works”

Pick a stable session id and route with the session_affinity strategy. bytetourist pins that session to a node and keeps using it for as long as the session stays active:

Terminal window
# request 1 and request 2 leave from the same IP
curl -x http://dev.bytetourist.com:8080 \
  -U "YOUR_API_KEY-strategy-session_affinity-session-checkout-42:" \
  https://shop.example.com/cart


curl -x http://dev.bytetourist.com:8080 \
  -U "YOUR_API_KEY-strategy-session_affinity-session-checkout-42:" \
  https://shop.example.com/checkout

Or with headers:

Terminal window
-H "X-Proxy-Strategy: session_affinity" -H "X-Proxy-Session: checkout-42"

Choosing session ids

Section titled “Choosing session ids”
  • Use a unique id per logical session (per user, per cart, per crawl worker).
  • Reuse the same id for every request that must share an IP.
  • Combine with targeting — e.g. pin a session to a residential IP in one country:
Terminal window
-U "YOUR_API_KEY-cc-de-iptype-residential-strategy-session_affinity-session-u_8841:"

When the pinned node goes away

Section titled “When the pinned node goes away”

If the pinned node becomes unhealthy or is recycled by the scaler, the session falls back to another eligible node (unless you set strict-true). Long-lived sessions should tolerate an occasional IP change.