Every request through a proxy gateway either gets a fresh exit IP or reuses one you've pinned. Both are useful — the question is which one matches what you're actually doing.
Rotating: a new IP by default
Rotating is the default behavior on OneForProxy: unless you add a session id to the username, each new connection can land on a different exit IP. That's the right shape when requests are independent of each other — pulling many pages of a catalog, sampling prices across listings, or any job where spreading load across IPs matters more than any one request being tied to the last.
curl -x "http://ofp_0123abcd-country-de:$PASS@proxy.oneforproxy.com:8080" https://api.ipify.orgRun that twice in a row and you may see two different IPs — there's no session id in the username, so nothing pins one.
Sticky: the same IP for a stretch of requests
Sticky sessions matter whenever the target site expects to keep talking to the same address across more than one request — a login followed by authenticated pages, a multi-step checkout, or pagination through results that a site associates with the IP that started the session. If the exit IP changes partway through, the site sees what looks like a different visitor showing up mid-flow.
Add -session-<id> to the username to pin the IP, and -life-<minutes> to
control how long the pin holds (1–1440 minutes, so anywhere from a minute to
a full day):
# same IP for 10 minutes under session id "job42"
curl -x "http://ofp_0123abcd-country-us-session-job42-life-10:$PASS@proxy.oneforproxy.com:8080" https://api.ipify.org
curl -x "http://ofp_0123abcd-country-us-session-job42-life-10:$PASS@proxy.oneforproxy.com:8080" https://api.ipify.org # → same IPBoth calls use the same job42 id and the same 10-minute life, so they land
on the same exit IP. Let the -life- window pass, or use a different id,
and you'll get a new one.
Running several sticky sessions at once
The session id is just a string you choose, so parallel jobs each get their
own pinned IP by using a distinct id per job or per thread — job1,
job2, and so on, or anything unique your code already generates. There's
nothing shared between ids beyond the login itself; two different session
ids on the same credential behave as two independent sticky IPs.
Combining sticky with targeting
Session ids stack with the rest of the username options, so a sticky session can still be scoped to a country, state or city — the id just pins the IP within whatever pool that targeting already narrows it to:
curl -x "http://ofp_0123abcd-country-us-city-new_york-session-job42-life-30:$PASS@proxy.oneforproxy.com:8080" https://api.ipify.orgThat's a sticky IP out of New York, held for up to 30 minutes under
job42. Nothing about combining options changes how either one behaves on
its own — order matters (country, then state, then city, then ASN, then
session, then life), but each option still does exactly what it does in
isolation.
Mixing both in the same job
There's no rule that a whole job has to be one mode or the other. It's common to rotate for a broad discovery pass — finding which pages or listings exist — and then switch to sticky, with a session id scoped to each item, for the follow-up requests that need to look consistent, like logging in or stepping through a multi-page form. Since both modes go through the same credential and gateway, switching is just a change to the username on the next request, not a different setup.
Choosing between them
A practical way to decide: does the target site need to recognize this request as a continuation of the last one? If yes — anything behind a login, a cart, or a session cookie tied to the connecting IP — use sticky with a session id scoped to that flow. If each request stands on its own, rotating is simpler and spreads traffic across more exit IPs by default, which is usually what you want for broad, independent fetching.
Both modes use the same gateway and the same per-GB billing — see Pricing — so switching between them for different parts of the same job is just a matter of changing the username, not reconfiguring anything else.
Related reading
- Sticky sessions in the knowledge base goes deeper
on parallel sessions and picking a
-life-value. - Targeting covers the full username DSL, including how
-session-combines with country/state/city/ASN options. - The Docs page has the canonical sticky-session reference.
- Residential vs. datacenter proxies covers the other axis of choosing a proxy setup: which kind of IP to use.