Rotating draws a new exit per connection. Sticky holds one for 1-120 minutes. Which port selects which, how long to hold, and what breaks either way.
· 12 min read · Fundamentals
Every request you send through a proxy lands on some exit address. The only decision worth arguing about is how long you keep it. That decision is the whole of rotating vs sticky proxy sessions: rotating hands you a new address per connection, sticky binds you to one for a fixed window. Pick wrong and you either burn addresses on work that needed continuity, or you hold one address long enough for a target to build a profile of it and shut it down.
This page gives the parameters, not the philosophy. Ports, windows, the tasks that break under each mode, and a loop you can run in 30 seconds to confirm which mode you are actually in.
A rotating session draws a fresh exit address for each new connection to the gateway. Two connections opened a second apart are unlikely to share an address, and nothing guarantees they share a subnet or an ASN either.
A sticky session binds you to a single exit address for the duration of a window. Within that window the address holds. Outside it, you are rotating again.
That is the definition. Every page-one result for this query spends several hundred words on those two paragraphs and then stops, which is precisely the opening they leave. The useful content starts at the parameters: which port selects which behavior, how long the window runs, what the network does when the window expires, and which of your jobs is quietly on the wrong one.
Session mode is not a flag in a request body, a header, or a username suffix.
It is which port on gw.anonedge.com you connect to.
| Port | Protocol | Session behavior | Notes |
|---|---|---|---|
| 823 | HTTP / HTTPS | Rotating | Default for independent requests |
| 824 | SOCKS5 | Rotating | Same behavior, different transport |
| 10000-20000 | HTTP or SOCKS5 | Sticky | One session slot per port number |
Three lines, side by side:
# Rotating, HTTP/HTTPS
curl -x "http://login:[email protected]:823" https://api.ipify.org/
# Rotating, SOCKS5
curl -x "socks5://login:[email protected]:824" https://api.ipify.org/
# Sticky - any port in 10000-20000, HTTP or SOCKS5
curl -x "http://login:[email protected]:10000" https://api.ipify.org/
The consequence most operators miss: each port in the sticky range is its own session slot. Two workers pointed at port 10000 share one exit address. Move the second worker to 10001 and it gets a different one. You allocate concurrency by allocating port numbers, not by passing session tokens.
That has a scheduling implication. If you need 40 simultaneous sticky identities, you need 40 port numbers assigned to 40 workers, and you need to keep a worker on its port for the life of the identity. Round-robin across the range and you have built a slow rotator with extra steps. The full port reference, including which outbound destination ports are open, sits in the sticky port range documentation.
For the protocol side of the same decision, connecting to the gateway is the mechanical reference. Protocol and session mode are independent choices — SOCKS5 does not imply rotating, and sticky does not imply HTTP.
The sticky window runs from 1 to 120 minutes and defaults to 30. You set it alongside the rest of your session configuration; see configuring rotation and session type.
Two properties of that window matter more than the number itself.
Expiry is silent. Nothing errors when a window closes. There is no disconnect, no warning, no status code from the gateway. The next connection simply lands on a different exit address, and the first thing that tells you is the target: a 302 back to the login page, an empty cart, a token mismatch, a paginated cursor that resets to page one. The failure surfaces one hop downstream from where it happened, which is why it eats an afternoon.
Binding is best-effort, not a lease. A residential exit is somebody's actual connection. If the peer goes offline mid-window, the binding ends early regardless of how many minutes remain. Long windows raise the odds of this. A 120-minute window is not a 120-minute guarantee; it is a ceiling on how long the network will try.
Both properties argue the same way: hold the address for the length of the work and not one minute longer.
Set the window to the expected wall-clock duration of the dependent sequence, plus margin for its slowest step. That is the entire rule. Applied:
| Task | Suggested window | Why |
|---|---|---|
| Login, then read | Short — 1 to 5 min | The identity only needs to survive the redirect chain and the first authenticated fetch |
| Cart to checkout | Medium — 15 to 30 min | Server-side cart state is frequently IP-associated, and a human checkout has think time |
| Paginated crawl behind a session | Length of the pagination run | A mid-crawl address change invalidates the cursor and you restart |
| Account warm-up | Longest — up to the 120 min ceiling | Consistency is the entire point of the exercise |
| Single-page fetch | None — rotate | Stickiness costs you address diversity and buys nothing |
Now the part nobody in this SERP does: reconcile the published numbers. ZenRows illustrates sticky sessions with a single 10-minute example. Infatica offers "10 minutes, 30 minutes, or longer" and declines to bound it. Elsewhere in the same result set you will find ranges running to 24 hours. None of those figures is wrong. All of them are answers to a question nobody asked, because duration is not a property of the proxy — it is a property of the task.
Which is what makes a 30-minute default defensible rather than arbitrary. It is long enough to cover a cart-to-checkout sequence with human-scale think time, and short enough that an address you have annoyed gets recycled inside the hour. It is a sensible midpoint, not a recommendation for your specific job. Measure your dependent sequence, then set the window.
Two different things get called rotation, and conflating them is the root of most "my rotating proxy is broken" tickets.
Per-connection rotation assigns a new exit when a new TCP connection is established to the gateway. This is what ports 823 and 824 do. The important word is connection, not request — an HTTP client that keeps one connection open and pipelines 500 requests through it gets 500 requests from one exit address, and the gateway is behaving exactly as designed. That single fact accounts for most rotation complaints; the mechanism and the per-client fixes are covered in why a rotating proxy returns the same IP.
Timed rotation holds an exit for a fixed interval on a rotating endpoint and swaps it when the interval elapses, independent of connection lifecycle. This is functionally a short sticky window wearing a different label.
Do not take either model on faith, and do not take an interval figure from a vendor page either — determine which one you are on empirically, in the environment that will run the job. Open a connection, hold it, and issue requests through it: if the address is stable, rotation is per connection. Close and reopen between requests: if the address changes immediately, rotation is per connection and you have your answer. If it changes only after a consistent delay, you are on a timer, and the delay you measured is the interval that applies to your account.
Each of these fails with a specific symptom. Learn the symptom and you skip the diagnosis.
/login, or a 401 on an
endpoint that worked 200 milliseconds ago.The last one is the expensive failure, because it does not raise. Sticky is not an optimization for these tasks. It is a requirement.
Stickiness has a cost, and it is not subtle.
Rate limits accumulate against one address. Rotating spreads N requests across N addresses; sticky concentrates them on one. A per-IP limit that a rotating job never touches is trivial to hit inside a 30-minute sticky window. Symptom: 429, or a soft equivalent — CAPTCHA interstitials, degraded responses, truncated results.
A block persists for the whole window. Rotating sheds a bad address on the next connection. Sticky keeps it. If the address you were bound to gets flagged at minute 3 of a 120-minute window, you have 117 minutes of failure queued up unless your code detects it and forces a new session by moving ports.
There is a third cost that is easy to overlook: held sessions occupy
threads. A sticky session consumes a concurrent connection slot for as long
as you hold it, so sticky work reaches the ceiling far sooner than the request
volume suggests. The error is 407 THREADS_EXHAUSTED, documented under
concurrent connection limits. Thread limits
are per plan, and raising one means talking to
support. Sizing the pool before you hit the
ceiling is covered in concurrency and IP
footprint.
Most real jobs are not one mode. They are an authenticated leg followed by a high-volume leg, and those legs want opposite things.
Worked example — collect order history for one account, then price-check every SKU it contains:
gw.anonedge.com:10000,
window set to cover login through the last authenticated fetch. Cookies,
CSRF tokens and cart state all stay coherent because the address never moves.gw.anonedge.com:823 and each one draws its own exit. A thousand price
checks spread across a thousand addresses looks nothing like a thousand
checks from one.Step 3 is where this goes wrong in practice. The handoff has to be a new client, not a new base URL. Two ports, two clients, two connection pools.
Do not trust the port number in your config. Trust the addresses.
for i in $(seq 1 5); do
curl -s -x "http://login:[email protected]:823" https://api.ipify.org/
echo
done
Five distinct addresses means rotation is working end to end. Five identical
addresses means one of three things, in order of frequency: your client is
holding one TCP connection open across all five calls; you are connected to a
sticky port and misread the config; or the window on a sticky port has not
elapsed. Run the same loop with curl invoked separately per iteration, as
above, rather than inside a single client session — separate processes cannot
share a connection pool, which removes the most common confound.
One caution about what a stable address proves. It proves the exit did not change. It does not prove the network is broken, and it does not prove your target sees what you see. Test against a plain IP echo, never against the target — targets cache aggressively enough that an unchanged response can survive a changed address for minutes.
If you are configuring this inside a browser extension rather than a script, setting the port in SimpleProxy walks the same choice through the UI.
A sticky session proxy holds one exit IP address for a set window instead of drawing a new one per connection. On AnonEdge the window runs from 1 to 120 minutes and defaults to 30, and you select sticky behavior by connecting to a port in the 10000-20000 range rather than to the rotating ports. Use it whenever a sequence of requests only makes sense as one visitor.
As long as the dependent sequence takes, plus margin for its slowest step. A login-then-read flow needs a few minutes. A cart-to-checkout sequence with human think time needs 15 to 30. An account warm-up wants the longest window available. Anything that does not depend on prior state should not be sticky at all — holding an address you did not need costs you a thread and buys nothing.
No. The binding is best-effort. A residential exit is somebody's live connection, and if that peer drops off the network the binding ends early no matter how many minutes remain on the window. Treat the window as a ceiling on how long the network will try to hold the address, not as a lease. Build your job to detect an address change rather than assume one cannot happen.
Yes. Mode is selected per connection by port, not per account, so one job can open a sticky connection on port 10000 and a rotating connection on port 823 simultaneously. That is the recommended pattern for jobs with an authenticated leg and a high-volume leg. Use a separate client instance per leg so connection pooling cannot carry one leg's connection into the other.
Session type does not change the per-gigabyte rate — billing is by traffic, and
the current per-GB rates are the same either
way. What sticky sessions consume is concurrency: a held session occupies a
thread for its entire window, so sticky-heavy workloads hit 407 THREADS_EXHAUSTED at lower request volumes than rotating ones. Budget threads,
not bandwidth.
Nothing visible from the gateway. There is no error and no disconnect. The next connection lands on a new exit address, and your target reports the consequence instead — a redirect to login, an emptied cart, a reset cursor. Because the failure surfaces downstream, log the exit address alongside each request so an expiry is one grep away rather than an afternoon of guessing.
Does request N depend on state created by request N-1?
If yes, sticky, with the window sized to the sequence. If no, rotating. Everything else — pool type, protocol, geo filters — is an independent choice you can vary without revisiting this one.
Start on rotating ports, log the exit address with every request, and move only the flows that actually fail onto sticky ports. Start routing and set the window to your task.