Session Reliability: The Sticky-Proxy Metric Almost Nobody Measures

Session reliability is the percentage of sticky proxy sessions that hold the same exit IP from the first request to the last. Across the residential providers I benchmark, it ranges from 97.5% at the top to 72.2% at the bottom. The best provider keeps your IP for the whole session almost every time. The worst loses it in more than one session out of four. No "best residential proxy" listicle I have seen measures this number, and for any workflow with a login, it is the number that decides whether the job succeeds.

Key takeaways

• What it measures: whether a "sticky" proxy actually keeps the same IP across a multi-request session.
• The current spread: 97.5% (best) to 72.2% (worst) sticky-session survival; unexpected mid-session rotation runs from 1.4% to 7.3%, a roughly 5x gap.
• Why uptime hides it: a provider can return a 200 on every request (99.9% "uptime") and still rotate your sticky IP 7% of the time. Uptime is per-request; session reliability is per-session.
• Who should care: anyone doing stateful work behind a login, a cart, or a session cookie. Stateless scrapers can ignore it.
• Its weight here: the session dimension is 30% of the proxystats.io composite score, equal to core network performance.

---

Two ways people use residential proxies

People run residential proxies for two jobs that have almost nothing in common.

Stateless work: hit a URL, grab the HTML, move on. Each request stands alone. A provider that rotates your IP on every request is doing you a favor here, because it spreads your footprint across many addresses. Success rate and latency are the only metrics that matter.

Stateful work: log into an account, add an item to a cart, page through search results behind a session cookie, finish a multi-step checkout. The target server ties your session to your IP. Swap that IP mid-flow and the server sees a session that jumped to a new address and geography. It reacts the way any fraud system reacts: it logs you out, throws a challenge, or shadow-blocks the rest of the session.

For stateful work, an unexpected mid-session rotation is a failed workflow. You do not get a slow retry. You get a broken login and a CAPTCHA.

A fast proxy does not save you. A provider that drops your sticky IP 7% of the time breaks roughly one stateful session in fourteen, however quick each individual request is.

Why I do not trust the word "sticky"

Every provider sells a "sticky session" option. You request a sticky endpoint and the provider promises the same exit IP for a set window: one minute, ten minutes, thirty minutes, depending on the plan.

The promise and the delivery are separate facts. "Sticky" is a flag on the provider's gateway. Whether the gateway honors that flag under load, across a real multi-request session while the back-end pool churns, is something you can only learn by testing. So I test it, on a schedule, and count how often the IP I was promised is still the IP I hold a minute later.

How I measure it

The session dimension runs on a dedicated sticky credential pool, with a TTL set well above the length of the test. That detail bites people: a 60-second TTL expires in the middle of a 60-second continuity check and reads as a failure. The TTL has to outlast the session you measure.

Each probe does three things:

1. Open a sticky session and record the exit IP.
2. Run a sequence of follow-up requests across the session window, the way a real stateful workflow would.
3. On every follow-up, check whether the exit IP still matches the one we opened with.

From that I get two numbers per provider:

• Sticky session survival: the share of sessions that held one IP start to finish.
• Unexpected mid-session rotation rate: how often the IP changed while the contract said it should stay.

The rotation number carries a heavy multiplier in the composite score. An unexpected rotation breaks the core feature you paid for, so a provider cannot bury a few percent of rotation behind a strong latency figure.

The data

Here is the current spread on the sticky pool across the residential providers I track:

Sit with the rotation row. Both of these providers advertise sticky sessions on their pricing pages. One leaks the IP 1.4% of the time, the other 7.3%. Under continuous measurement that is not the same product, even though the marketing copy reads the same.

The survival row matters just as much. A 97.5% provider breaks one session in forty. A 72.2% provider breaks more than one in four. If your pipeline runs ten thousand logins a day, that is the difference between 250 broken sessions and 2,800.

None of this surfaces in an uptime figure. A provider can sit at 99.9% uptime, every request returning a clean 200, and still rotate your sticky IP 7% of the time. Uptime counts whether requests come back. It says nothing about whether they come back as the same session.

Uptime answers the wrong question

Uptime is a per-request metric. Session reliability is a per-session metric. They answer different questions:

• Uptime: "If I fire one request, will it return?"
• Session reliability: "If I fire ten requests as one logged-in session, will all ten share the same identity?"

For stateless scraping, uptime is what you want. For anything behind a login, a cart, or a cookie, session reliability is the number that predicts success. A provider chasing the uptime headline, the figure that sells, has no reason to surface the session number, let alone make it good.

That gap is why proxystats.io exists. The session dimension carries 30% of the composite score, the same weight as core network performance, because for a large share of real use cases it is the metric that decides the outcome.

What to do with this

If your work is stateless, ignore session reliability and optimize for success rate and latency. Rotation helps you.

If your work is stateful, compare session survival first, ahead of price and ahead of speed. A cheaper, faster proxy that drops one session in four costs you more in failed jobs and CAPTCHA-solving than you ever saved on the per-GB price. Session reliability carries 30% of the composite score in our best residential proxy ranking, so the leaderboard already prices this in.

The live numbers update continuously on the dashboard. Sort by Success Rate and Score Breakdown to see the session dimension broken out per provider. The full scoring formula, including how the rotation penalty works, sits on the methodology page.

No affiliate links. No sponsored placements. Just the number the listicles skip.

---

FAQ

What is a sticky session proxy?
A sticky session proxy gives you the same exit IP for a fixed window instead of rotating it on every request. You request a sticky endpoint, and the provider's gateway is supposed to hold one residential IP for the session duration set by your plan, commonly 1, 10, or 30 minutes.

Why does my proxy IP change in the middle of a session?
The provider's gateway dropped the sticky assignment before the window ended. It happens when the back-end pool churns under load, when the TTL is shorter than your session, or when the gateway does not honor the sticky flag well. Across the providers I benchmark, this unexpected mid-session rotation runs from 1.4% to 7.3%.

Is uptime the same as session reliability?
No. Uptime measures whether individual requests return a response. Session reliability measures whether a multi-request session keeps the same IP. A provider can show 99.9% uptime and still rotate your sticky IP 7% of the time, because the two metrics count different things.

How long should a sticky session last?
Long enough to outlast your workflow. Match the TTL to your longest stateful flow. A login plus a few page loads might fit in 60 seconds; a full checkout can need 10 minutes. Set the TTL above that length, since a TTL that expires mid-session reads as a rotation.

Sticky vs rotating proxy: which one do I need?
Use rotating for stateless scraping where each request stands alone, since fresh IPs spread your footprint. Use sticky for stateful work behind a login, cart, or session cookie, where the server ties your session to one IP. For sticky work, session reliability is the metric that predicts whether the job holds together.