Session Persistence
Keeping a sequence of requests recognisable as one visitor. It requires the client state and the exit address to stay together.
A session lives in two places at once. The site keeps state and hands you a cookie that points at it. Your side keeps that cookie and returns it. Neither half works alone, and most session problems come from treating only one of them as the session.
The address is the half people forget. A cookie issued to a visitor in Warsaw and returned an hour later from Lisbon describes something that does not happen to real users, and many sites treat that combination as a stolen cookie rather than a returning customer.
That is what sticky sessions are for. Holding the same exit for the life of a flow keeps the two halves consistent, which is why anything with a login, a cart or a multi-step form belongs on a sticky session or on a static address rather than on rotation.
The opposite failure is quieter. Reusing one cookie jar across many workers makes dozens of parallel requests look like one very strange person, and it usually shows up as a rate limit rather than a block, so it gets diagnosed as pace when it is really identity.
The two halves and their lifetimes
Server state has its own expiry, usually longer than a visit. Cookie state has an expiry the server sets. Your exit has a lifetime you set. When the shortest of the three ends first, the session breaks in a way the other two cannot explain.
Our sticky sessions hold one residential address for up to fifty minutes, and a static ISP or datacenter address holds for the whole term. Those are the two ways to make the address half outlast the other two.
Cookie jars must be per identity, not per process. One jar shared by twenty workers is one identity making twenty simultaneous requests, whatever the address rotation is doing.
Making both halves last
Set the address lifetime to cover the flow, and keep one jar per identity:
A flow that stays one visitor
# one exit for the whole flow, with its own cookie jar
S="login_c_PL_s_12_ttl_50m:password@proxy.sotaproxy.com:10000"
curl -s -c jar.txt -b jar.txt -x $S https://target.example/login
curl -s -c jar.txt -b jar.txt -x $S https://target.example/account
# a second identity gets a second session id and a second jar
curl -s -c jar2.txt -b jar2.txt \
-x login_c_PL_s_13_ttl_50m:password@proxy.sotaproxy.com:10000 https://target.example/login- Match the ttl to the flow, not to the crawl. A fifteen minute session under a twenty minute flow fails in the last step, which is the most expensive place to fail.
- Where the work must survive longer than fifty minutes, that is what static ISP addresses are for.
- Never share a cookie jar between workers. It is the single most common cause of limits that look like pace problems.
What people get wrong
A sticky session is not a login
It holds an address. Whether the site keeps you logged in is its own state and its own expiry.
Rotation does not reset a session
The cookie still identifies you. A new address with an old cookie is more suspicious than either alone.
Longer is not always better
A single address doing a full day of work is its own signal. Sessions should match flows, not shifts.
It is not only about logins
Carts, multi-step forms, paginated searches and checkout flows all carry state that a changing address breaks.
Пов'язані терміни
Дивись на практиці
Готовий використовувати session persistence?
SotaProxy надає доступ до ротуючих резидентських, мобільних, дата-центр та ISP проксі. Без мінімальних платежів.
Почати