---
title: "Sticky session"
url: https://proxy.wiki/glossary/sticky-session/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Sticky session

> A setting that keeps the same exit address for a fixed period, so a multi-step flow appears to come from one user.

**A sticky session holds one [exit address](/glossary/exit-node/) for a defined duration instead of rotating.** Typical windows run from one minute to roughly thirty, depending on the provider.

## Why it exists

Many tasks are not a single request. Logging in, adding to a basket, paging through results, or completing a form all involve several requests that a server expects to originate from one client. If the address changes halfway through, the session looks implausible and may be discarded or challenged.

## How it is usually requested

Most providers accept a session identifier inside the proxy username, for example a field such as `session-abc123`. Requests carrying the same identifier are routed through the same address until the window expires. The exact syntax differs by provider.

## What it does not guarantee

Stickiness is best-effort. If the underlying address leaves the pool — a residential peer disconnects, for example — the session ends early and you receive a different address. Code that assumes a stable address for the full window will eventually be surprised, so detect the change rather than assume it cannot happen.

## What sticky does and does not promise

| Promise | Holds? |
| --- | --- |
| Requests in the session prefer the same exit | Yes, while that exit is reachable |
| The address never changes | No. A consumer device can leave at any moment |
| The session lasts as long as you want | No. Providers cap the duration |
| The address stays in the chosen country | Usually, but confirm after any replacement |

Because the second row is false, code that depends on a stable address must detect the change rather than assume it cannot happen. Check the address at the start of the session, and again after any unexpected authentication failure.

## Building for the replacement

A session that loses its exit usually presents as a sudden logout, an empty basket, or a redirect to a sign-in page. Treat those as a possible address change, not only as an application error. The recovery is to open a new session deliberately and restart the flow, rather than to retry the failed request on an address the site no longer associates with your state.

[The rotation guide](/guides/rotating-vs-sticky-sessions/) covers where each model belongs.

## Frequently asked questions

### How long can a sticky session last?

The provider sets the cap, and it varies widely between plans. Treat the advertised duration as a maximum rather than a guarantee, because the underlying device can leave the network before the timer expires.

### How do I request a sticky session?

Through the credential format or the port, depending on the provider. A session identifier is usually added to the username, and reusing that identifier returns you to the same exit.

### What happens when the exit disappears mid-session?

The provider substitutes another exit, so your address changes without warning. The site sees a session whose address moved, which commonly presents as a logout. Detect it by re-checking the address rather than by retrying blindly.

## Sources

1. [RFC 6265: HTTP state management, the cookies a session depends on](https://www.rfc-editor.org/rfc/rfc6265.html)