Sticky Sessions and Network Targeting: Pin One UK Mobile IP and One Network

Rotation is the default behaviour of most mobile proxy pools, and for good reason: a fresh IP per request spreads your footprint across the widest possible range of mobile devices. But a surprising amount of real work breaks the moment the exit IP changes. Logging in, keeping a shopping cart, managing an account, checking localised search results for one city: these are session-shaped workflows. They need one identity that stays stable for minutes or hours, not maximum diversity.

This guide covers the two controls that solve that on UK mobile proxies, with every output below captured from real runs through a live UK 4G/5G pool:

1. Sticky sessions: keep the same exit IP for a window you choose, from 5 minutes to 12 hours.
2. Network targeting: pin the exit to one UK mobile network: EE, O2, Vodafone or Three.

They compose: you can pin one IP and one network at the same time.

What rotation actually looks like

With plain credentials, every request is load-balanced across the pool. Three requests, three exits:

curl -x https://USER:PASS@proxy.simplyproxies.com:6889 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

{"query":"92.40.168.116","country":"United Kingdom","as":"AS206067 Hutchison 3G UK Limited","mobile":true}
{"query":"31.94.14.223","country":"United Kingdom","as":"AS2856 British Telecommunications Limited","mobile":true}
{"query":"31.94.37.54","country":"United Kingdom","as":"AS2856 British Telecommunications Limited","mobile":true}

First request landed on Three, the next two on EE. All three are genuine mobile registrations (mobile:true), which is what makes the pool useful; the IP itself just keeps changing. For scraping at scale that is exactly what you want. For anything with a login screen it is exactly what you do not.

Sticky sessions: same IP, window you choose

Append -session-<id> to the username and every connection carrying the same id exits through the same device, so the same IP:

curl -x https://USER-session-myapp1:PASS@proxy.simplyproxies.com:6889 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

Three separate curl processes, seconds apart, same session id:

{"query":"85.255.232.139","country":"United Kingdom","as":"AS25135 Vodafone Limited","mobile":true}
{"query":"85.255.232.139","country":"United Kingdom","as":"AS25135 Vodafone Limited","mobile":true}
{"query":"85.255.232.139","country":"United Kingdom","as":"AS25135 Vodafone Limited","mobile":true}

One Vodafone exit, held. The id is any label you pick. Behind the scenes the pin is more than routing: the pool's IP rotation is suppressed for the held device while your session is live, so the phone is not cycling its public IP underneath you. That is what makes the IP genuinely stable, not just the device.

The same syntax works over SOCKS5:

curl -x socks5h://USER-session-myapp1:PASS@proxy.simplyproxies.com:6890 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

{"query":"31.94.18.250","country":"United Kingdom","as":"AS2856 British Telecommunications Limited","mobile":true}
{"query":"31.94.18.250","country":"United Kingdom","as":"AS2856 British Telecommunications Limited","mobile":true}

Choosing a window

On SOCKS5 you set the window explicitly with -session-<id>-<minutes>, clamped between 5 minutes and 12 hours; without a suffix you get the 2-hour default. A 4-hour window:

curl -x socks5h://USER-session-myapp1-240:PASS@proxy.simplyproxies.com:6890 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

The window is sliding: every new connection carrying the same session id refreshes it. A worker that reconnects every minute keeps its IP indefinitely, even past the nominal window. An idle session releases its pin when the window lapses.

We verified the clamp and the expiry live. A 2-minute request (-session-demo-2) is clamped to the 5-minute minimum and still held its IP at the 2-minute mark, exactly as documented. A genuine 5-minute window behaved as expected:

Time	Exit IP	Network
0:00	82.132.217.228	O2 (AS35228)
1:00	82.132.217.228	O2 (AS35228)
6:30, window expired	31.94.18.250	EE (AS2856)
6:32	31.94.18.250	EE (AS2856)

The pin lapsed, the next connection re-bound to a different device (a different network, as it happened), and re-pinned there. Two details worth knowing:

• Custom minute windows are a SOCKS5 feature. On HTTPS the -session-<id> pin uses a table-wide window (12 hours) and the -<minutes> suffix is not honoured. If you need a precise 30-minute pin, use the SOCKS5 endpoint.
• Mind the trailing number. -session-myapp1 is an id; -session-myapp1-30 is the same id with a 30-minute window. Never end an id with a dash-number unless you mean the window.

Network targeting: choose the exit network

Some workflows care about more than the IP. Carrier-level checks, per-network price or content tests, and debugging a target that treats one UK network differently from another all want the exit pinned to a specific mobile network. A closed-set token after the base username does that:

curl -x https://USER-o2:PASS@proxy.simplyproxies.com:6889 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

One request per token, all through the same HTTPS endpoint:

Token	Exit IP	Network
-ee	31.94.18.250	EE (AS2856)
-o2	82.132.217.228	Telefonica UK / O2 (AS35228)
-vodafone	85.255.232.139	Vodafone (AS25135)
-three	92.40.168.116	Three (AS206067)

Each token landed on the correct network, first try, verified by the ASN in the response. The token works identically on SOCKS5 (socks5h://USER-three:PASS@... returned a Hutchison 3G exit in our run) and combines with sticky sessions, covered next.

Two rules keep the behaviour predictable:

• Token order matters: the network token comes directly after the base username and before any -session- suffix. The full grammar is USER[-network][-session-id[-minutes]].
• Fail-closed, never silent: if the network you asked for has no capacity at that moment, the request is refused. It is never silently served by a different network.

The combo: one IP, one network

This is the pattern for account workflows that must look like one phone on one carrier: sticky session plus network token in one username.

curl -x https://USER-o2-session-acct1-720:PASS@proxy.simplyproxies.com:6889 \
  "http://ip-api.com/json/?fields=query,country,as,mobile"

Three requests, seconds apart:

{"query":"82.132.216.204","country":"United Kingdom","as":"AS35228 Telefonica UK Limited","mobile":true}
{"query":"82.132.216.204","country":"United Kingdom","as":"AS35228 Telefonica UK Limited","mobile":true}
{"query":"82.132.216.204","country":"United Kingdom","as":"AS35228 Telefonica UK Limited","mobile":true}

One O2 exit, held for a 12-hour window, from a username that reads as: base credential, O2 network, session acct1, 720 minutes. For multi-account work, give each account its own session id (and typically its own network) and each one becomes a stable, distinct phone identity.

Which control when

Workflow	Use	Example username
Wide scraping, maximum diversity	Nothing (rotate)	USER
Login flows, carts, session cookies	Sticky, 30-120 min	USER-session-shop-60
Long account management	Sticky, 2-12 h	USER-session-acct1-720
Network-specific checks	Network token only (IPs rotate within the network)	USER-ee
Multi-account identity simulation	Sticky + network	USER-o2-session-acct1-720

Two practical caveats. Sticky capacity is capped at a third of the pool per design, so the non-sticky majority always keeps full rotation diversity; if you hold many simultaneous sessions, spread them rather than bursting. And stability is per session id: two different ids are two different pins, so naming discipline (acct1, acct2, one id per logical account) is the difference between five stable identities and five pins on one device.

Summary

• Plain credentials rotate every request across the whole UK mobile pool.
• -session-<id> pins one exit IP: 2-hour default, 5-minute minimum, 12-hour maximum, sliding window. Custom -<minutes> windows apply on SOCKS5.
• -ee, -o2, -vodafone, -three pin the exit network by username token, on both protocols, and are refused rather than silently rerouted when capacity is absent.
• The two compose into one stable identity: one device, one network, one window you choose.
• Every command and output in this article was run live through the Simply Proxies pool on 2026-10-07 (curl 8.5.0, geolocation via ip-api.com).

Try it with your own credentials: the full syntax reference, including language-specific snippets and the Connections tab that builds these usernames for you, is in the Simply Proxies docs.

Last verified 2026-10-07