Excellent 5-star rating on Trustpilot

TorchProxies Blogs

Here you can find valuable information about topics surrounding proxies, data scraping and other use cases

How to Tell If a Proxy Provider Is Ethical | TorchProxiesProxy Guides

How to Tell If a Proxy Provider Is Ethical | TorchProxies

How to Tell If a Proxy Provider Is Ethical | TorchProxies Home › Blog › How to Tell If a Proxy Provider Is Ethical Buyer’s Guide How to Tell If a ProxyProvider Is Ethical Two of the residential proxy industry’s largest networks, IPIDEA and NetNut, were both dismantled in 2026 after researchers tied their IP pools to non-consensual device enrollment. Here’s the checklist that would have flagged both before you ever signed up, plus what actually happened in each case. Amasha Vidumini | August 19, 2026 | 15 min read TL;DR An ethically sourced proxy provider can show you, not just tell you, how its IP pool was acquired: documented consent from device owners or a direct ISP lease, a self-serve way to test before you buy, independent benchmark data instead of only self-reported numbers, and clear ownership of whatever brand you’re actually signing up with. Two of the industry’s largest networks failed that test in 2026. Google disrupted IPIDEA, which turned out to be 13 outwardly separate brands run from shared infrastructure, on January 29, 2026. The FBI and IRS Criminal Investigation seized NetNut’s domains on July 2, 2026, after researchers tied its infrastructure to a botnet called “Popa,” and NetNut had itself absorbed a wave of customers displaced by the IPIDEA takedown months earlier. Both failures trace back to the same root cause: IP pools built from devices enrolled without meaningful disclosure. Check how the IP pool is sourced, not just whether the provider says “ethical.” Ask for documentation of device-owner consent or a direct ISP lease agreement, not just marketing copy. Check who actually owns the brand. Google identified IPIDEA as controlling 13 ostensibly independent proxy brands from shared Hong Kong-registered infrastructure (Google Cloud Blog, Jan 29, 2026). Check for self-serve access and independent benchmarks. A provider that requires a sales call before you can test anything is harder to audit and harder to walk away from quickly. Treat this as an ongoing check, not a one-time decision. NetNut passed enough of a basic trust bar to absorb IPIDEA’s displaced customers, then failed the same underlying test five months later. “Ethically sourced” appears on nearly every residential proxy provider’s homepage. It’s rarely backed by anything a buyer can actually verify. That gap matters more after 2026 than it used to: two networks that used the phrase, or something close to it, in their own marketing were dismantled within six months of each other, both for the same underlying reason. This is a working checklist for telling the difference between a provider that can substantiate its sourcing claims and one that can’t, built directly from what investigators and independent researchers found wrong with IPIDEA and NetNut. The checklist comes first. The two case studies that produced it follow, along with what to do if you had an active subscription with either network. The Checklist: Six Signals of an Ethically Sourced Proxy Provider A provider is worth trusting with your traffic if it can show verifiable consent for how it acquired its IPs, let you test that pool before committing money, and stand behind its numbers with data it didn’t generate itself. Everything below breaks that down into checks you can actually run. What to Check Why It Matters How the IP pool is sourced Ask directly whether IPs come from consenting device owners or partner ISPs, and whether that’s documented anywhere public, not just asserted in marketing copy. Whether the “brand” is actually independent IPIDEA operated as 13 outwardly separate brands from shared infrastructure. A cheap or unfamiliar name isn’t automatically suspect, but check who actually operates it before assuming it’s unrelated to a known bad actor. Self-serve dashboard and API access A provider you can sign up for, test, and cancel yourself, without a mandatory sales call, is easier to audit and exit quickly if something changes. Independent benchmark data Look for third-party testing (Proxyway and similar) rather than relying only on a vendor’s self-reported success rate and latency numbers. Free trial before commitment Test the actual pool against your real target sites before paying for volume, rather than trusting a sales pitch. Billing transparency Clear per-GB or per-IP pricing you can see without a quote request is easier to budget and easier to walk away from. Red Flags That Show Up Before the Takedown Neither IPIDEA nor NetNut collapsed without warning signs a careful buyer could have caught. Enrollment disclosure buried inside an app’s terms rather than a clear opt-in prompt, “ethically sourced” claims with no linked policy or documentation behind them, and a pool size that only ever gets described in cumulative “nodes since [year]” terms rather than a concurrently active figure are all patterns that showed up in the reporting on both networks. Provider Trust Criteria: Illustrative Comparison Provider Trust Criteria Scorecard Sourcing Transparency Self-Serve Access Billing Transparency Independent Benchmarks TorchProxies NetNut (pre-shutdown) Editorial synthesis based on sourced facts below, not a separately measured index Verdict A provider that lets you sign up, test with a free trial, and see published pricing without a sales call is easier to verify and easier to leave quickly if you ever need to. That’s a lower bar than “prove your sourcing is perfect,” but it’s the bar NetNut’s self-serve tiers cleared while its underlying sourcing model apparently did not. TorchProxies Residential & ISP Proxies Ethically Sourced, Self-Serve, No Sales Call Required. TorchProxies runs a self-serve dashboard and full API today, with a free 1GB trial and no credit card required, so you can test against your own target sites before committing to volume. ✓ Free trial, no card required✓ Self-serve dashboard✓ 195+ countries Start Your Free Trial ✓ Instant self-serve signup Why This Checklist Exists: Two 2026 Case Studies The timeline runs faster than most infrastructure stories, and it doesn’t start with NetNut. Google disrupted IPIDEA, a network controlling 13 ostensibly independent proxy brands, on January 29, 2026. NetNut absorbed a meaningful share of the customers displaced by that takedown. Five months later, NetNut was seized

Aug 19, 2026
read more
How Many Accounts Per Mobile Proxy? Real Limits by Platform | TorchProxiesProxy Guides

How Many Accounts Per Mobile Proxy? Real Limits by Platform | TorchProxies

How Many Accounts Per Mobile Proxy? Real Limits by Platform | TorchProxies Home › Blog › How Many Accounts Per Mobile Proxy Multi-Account Management How Many Accounts Per Mobile Proxy?Real Limits by Platform Most of the “accounts per proxy” numbers people quote don’t come from the platforms at all. Here’s what’s actually published policy, what’s just a device switcher’s UI ceiling, and what a shared mobile IP changes about the real risk. Amasha Vidumini | August 18, 2026 | 13 min read TL;DR There is no universal “accounts per mobile proxy” number, because most platforms don’t regulate proxy usage directly, they regulate account ownership and behavior. What looks like a proxy limit is usually one of three different things: a device switcher’s UI ceiling (Instagram’s 5-account switcher), an account-ownership policy with no proxy angle at all (Facebook and LinkedIn’s one-real-identity rule), or a number nobody has actually published (TikTok, Discord, X, and Snapchat’s device limits are all secondary-sourced, not official). Meanwhile, the mobile IP itself is already shared by hundreds to thousands of real subscribers before you add a single account to it. Instagram is the only platform with a clearly documented device-switcher number: up to 5 accounts, addable and switchable from the app (Instagram Help Center). Facebook and LinkedIn cap accounts by policy, not by device: one real-identity account per person, full stop, regardless of proxy or device (Meta Terms of Service; LinkedIn User Agreement). TikTok, Discord, X, and Snapchat have no independently verifiable, officially published device-switcher number. The “3,” “5,” and “10” figures circulating online trace back to proxy-vendor and anti-detect-browser blogs, not platform documentation. The “1 account, 1 dedicated proxy” rule practitioners repeat is industry consensus, not platform policy, a reasonable inference from how detection works, but not a number any platform has confirmed. Detection vendors are shifting budget toward account-level fraud detection rather than IP-level blocking, which matters more to your risk than any accounts-per-IP ratio (Kasada, Feb 2026; DataDome, Sep 2025). Search “how many accounts per mobile proxy” and you’ll find a number almost everywhere: 1, 2, 3, sometimes 5. What you won’t find, in almost every case, is a link back to the platform actually saying so. Most of what circulates as an “accounts per proxy” limit is proxy-vendor content repeating itself, not something Instagram, TikTok, or Discord ever published. That distinction matters because it changes what you’re actually managing. If a platform has a real, documented device-switcher ceiling, going past it just breaks the app’s UI. If a platform has no published number at all, the real constraint isn’t a count, it’s behavior, device fingerprinting, and how a shared mobile IP looks to a detection system that’s watching hundreds of other real subscribers on that same address. We covered the mechanics of that shared-IP exposure in detail in why mobile proxy IPs get burned; this guide is the platform-by-platform companion to that piece, sorting what’s actually policy from what’s folklore, and pointing to the deeper platform-specific guides where they exist. The Honest Answer: There Isn’t One Universal Number Every platform in this guide falls into one of three buckets, and conflating them is where most of the confusion about “accounts per proxy” comes from. 📡 Three Different Kinds of “Limit” Policy limit: the platform’s terms of service state a hard cap on accounts per person, independent of device or proxy (Facebook, LinkedIn). UI/switcher limit: the app’s built-in account switcher has a technical ceiling on how many logins it displays at once, which is a software constraint, not a rule against owning more (Instagram’s documented 5). No published limit: the platform regulates behavior, not account count, and any specific number you see online is a third party’s estimate (TikTok, Discord, X, Snapchat). None of the three buckets say anything about proxies specifically. A policy limit applies whether you’re on your home Wi-Fi or a mobile proxy. A UI switcher limit is about the app, not your IP. And where no limit is published, a proxy doesn’t change that absence, it just changes how each account you do run gets scored for risk. Verdict “How many accounts per mobile proxy” is the wrong question for most platforms. The right one is “does this platform cap accounts at all, and if not, what actually gets flagged.” Platform-by-Platform: What’s Actually Published This table separates confirmed platform policy from widely-repeated but unverified secondary claims. Where a number is marked unverified, treat it as informed estimate, not confirmed fact. Platform Stated Limit Type Source and Notes Instagram 5 accounts UI switcher “Add up to 5 Instagram accounts and quickly switch between them” (Instagram Help Center). This is a device-switcher ceiling, not a rule against owning more accounts elsewhere. Facebook 1 account Policy “Only create one account (your own) and use it for personal purposes,” with real-name requirements (Meta Terms of Service, §3.1). Since September 2023, up to 4 additional profiles are allowed under that one account. WhatsApp 2 accounts Device feature Two accounts logged in simultaneously on one phone, each requiring its own phone number and SIM or eSIM (WhatsApp official blog, Jun 1, 2026). LinkedIn 1 account Policy “You will only have one LinkedIn account, which must be in your real name” (LinkedIn User Agreement, §2.1). No device or proxy exception. TikTok ~3 (unverified) UI switcher (claimed) No official TikTok page states an exact switcher number. Community Guidelines target “spam, fake engagement, and coordinated inauthentic behavior,” not account ownership. The commonly cited figure comes from third-party proxy and browser-automation blogs, not TikTok itself. Discord No cap (unverified switcher #) Behavior-based Terms restrict operating multiple accounts to evade enforcement, but ownership itself isn’t capped. The “5 in the switcher” figure circulating online is secondary-sourced, not confirmed against Discord’s own documentation. See our dedicated Discord multi-account guide for the platform-specific playbook. X (Twitter) ~10 owned / ~5 logged in (unverified) Policy (claimed) X’s authenticity policy distinguishes owning multiple accounts (generally allowed) from coordinating engagement between them (a suspension risk). The specific “10” and “5” figures are consistently repeated across

Aug 18, 2026
read more
Multi-Account Management in 2026 Proxies, Browsers, and Behavior  TorchProxiesProxy Guides

Multi-Account Management in 2026 Proxies, Browsers, and Behavior TorchProxies

Multi-Account Management in 2026: Proxies, Browsers, and Behavior | TorchProxies Home › Blog › Multi-Account Management in 2026: Proxies, Browsers, and Behavior Multi-Account Management Multi-Account Managementin 2026: Proxies,Browsers, and Behavior Running more than one account per platform means passing three independent checks, not one. Here’s how the network, browser, and behavioral layers fit together, and where to go deeper on each. Hirusha Sasanka | Junior Developer | August 17, 2026 | 13 min read Key Takeaways Multi-account bans rarely trace back to one mistake. Platforms now score three independent layers, network, device, and behavior, and a strong two layers won’t cover for a weak third. Bots and automated traffic made up 53% of global web traffic in 2026, up from 51% in 2024, and platforms increasingly reuse the same composite-scoring infrastructure to catch linked accounts, not only automation (Thales/Imperva 2026 Bad Bot Report). Proxy architecture still decides the network layer. One dedicated IP per account, permanently, is the rule that holds across platforms; sticky-rotating and datacenter IPs fail it in different ways. Antidetect browsers have gone mainstream for account isolation. AdsPower alone reports serving over 9 million users worldwide as of April 2026 (AdsPower). Behavioral realism is the layer most platforms now weight heaviest, and the one a clean proxy and a stealth browser profile can’t fix on their own. Running a handful of Discord servers, a dozen TikTok accounts, or a client roster of Instagram profiles used to come down to one question: do you have enough proxies. That question still matters, but it stopped being the only one a while ago. Platforms now build a session score out of three layers that operate independently of each other: the network connection, the browser executing the page, and the behavior happening inside it. A session can pass two of the three cleanly and still get flagged on the third. This guide is the starting point for multi-account management in 2026. It covers what each layer actually checks, where operators most often get the architecture wrong, and which of our deeper technical guides to read next depending on which layer is giving you trouble. If you want the full mechanics of the composite scoring model itself, our complete anti-detection stack guide goes further into the code-level detail than fits here. Why Multi-Account Management Got Harder in 2026 Detection used to run almost entirely on IP reputation: one flagged IP meant one banned account, you’d buy a new proxy, and move on. That model broke down as platforms folded multi-account detection into the same bot-defense infrastructure built to fight automated traffic at scale. Bots accounted for 53% of global web traffic in 2026, up from 51% in 2024, while AI-driven bot attacks grew 12.5-fold year over year (Thales/Imperva 2026 Bad Bot Report). Every major bot-management vendor responded by combining network, device, and behavioral signals into one composite score rather than checking any single one in isolation, and multi-account detection piggybacks on that same architecture. The practical effect for anyone running more than one account per platform: your proxy is no longer the whole defense. It’s one input into a score that also weighs your browser’s fingerprint and how you actually behave once you’re logged in. Our companion piece on how platforms build that composite score breaks down each signal layer in detail; the summary here is the version you need to plan a multi-account setup, not build a bot. 2026 Global Web Traffic: Bot vs. Human Bots accounted for 53% of global web traffic in 2026, up from 51% in 2024, while human traffic fell to 47%. Source: Thales/Imperva 2026 Bad Bot Report. 2026 Global Web Traffic Composition Bot traffic 53% Human traffic 47% Up from 51% bot traffic in 2024, alongside a 12.5x year-over-year increase in AI-driven bot attacks. Source: Thales/Imperva 2026 Bad Bot Report Source: Thales/Imperva 2026 Bad Bot Report. Layer One, the Proxy: Getting Your Network Identity Right The network layer is still the foundation, and it still fails predictably. The rule that holds across LinkedIn, Instagram, TikTok, Telegram, and most other platforms is one dedicated IP per account, permanently, not shared and not rotating. Sticky residential sessions fail that rule because the IP eventually expires and reassigns, creating IP inconsistency the platform reads as suspicious. Datacenter proxies fail it differently: hosting-provider ASNs are an easy signal to flag regardless of how the session behaves otherwise. Our full breakdown of that one rule walks through the platform-by-platform mechanics; this section is the short version. 🔐 One-IP-Per-Account Rule Each account gets its own dedicated IP address, assigned once and never changed, rather than sharing an IP with other accounts or rotating through a shared pool. Static ISP proxies satisfy this natively; rotating residential and datacenter proxies generally don’t. Which proxy type fits depends on whether the account is meant to last. For accounts you’re building a real history on, ISP static proxies are the natural fit: a fixed IP registered to a consumer ISP, starting at $2.30 per IP per month at volume, with unlimited data and no rotation by design. For tasks that need volume across many accounts in a fixed window, like batch signups or sneaker drops, a hybrid rotating pool such as Plan X blends residential, ISP, and mobile sources to reduce subnet-level flagging when one range gets identified. Neither replaces the other; they cover different stages of an account’s life. Our hybrid proxies decision guide goes deeper into exactly when the hybrid pool earns its cost over a straight ISP setup. Real Signal From Our Support Queue Buyers setting up multi-account operations consistently ask to verify fraud scores on scamalytics.com and ip2location.com before committing to an IP block, and a meaningful share of ISP Proxies orders pair the product with Standard Residential in the same request, one for account persistence, one for general scraping or research tasks. The two products are doing different jobs even inside a single operator’s stack. Layer Two, the Browser: Fingerprints, Profiles, and Isolation A clean IP doesn’t help if every

Aug 17, 2026
read more
Behavioral Bot Detection: How Platforms Score Your Sessions | TorchProxiesProxy Guides

Behavioral Bot Detection: How Platforms Score Your Sessions | TorchProxies

Home › Blog › Clean IP, Still Blocked Bot Detection Behavioral Bot Detection: How Platforms Score Your Session When the IP Is Clean (2026) A clean IP is the credential that gets you through the door. What happens inside the session is a completely separate evaluation. May 2026 · 12 min read · Sachin Supunthaka · Senior Software Engineer TL;DR A clean IP passes the first check. The behavioral layer runs after that, separately, and it’s where most sessions actually fail. IP reputation is the entry gate. A clean residential IP passes the initial check provisionally. Session behavior is then scored as a separate, continuous evaluation. Pre-session signals run before your first header. JA4/TLS fingerprint and HTTP/2 frame ordering are evaluated at the connection layer before any request content is read. Behavioral scoring measures mouse trajectory entropy, scroll velocity, click accuracy, request timing, and navigation sequence. Each is a distinct signal weighted differently per platform. Each platform scores differently. Cloudflare uses a 1-99 bot score from its ML engine. DataDome collects 35+ signals per session and retrains continuously. Akamai re-evaluates the session mid-stream via its _abck cookie. Session scores are live, not static. A behavioral change mid-session can drop the score and trigger a challenge on a session that started clean. Coherence checks catch contradictory signals even when each individual signal passes its own check. An iPhone user-agent with a Linux Canvas fingerprint fails even with a clean IP. Clean residential IP. Low fraud score. ASN registers as a consumer ISP. The target site still returns a 403, or silently serves empty results that look like success until you check the data. Most proxy guides stop at the IP. Get a residential address, confirm it’s not on any blacklist, route through the right geography. That’s the IP problem, and solving it is genuinely necessary. But it doesn’t mean you’ve solved detection. Modern anti-bot platforms treat IP reputation and behavioral analysis as two separate layers. A clean IP gets you admitted to the session. What you do inside it is evaluated independently, continuously, and by a completely different set of signals. I want to be precise about what behavioral bot detection actually measures, how each major platform implements it, and what the practical implications are for anyone running proxies against protected targets. IP Reputation Is the Entry Gate, Not the Full Evaluation The IP reputation check is the first thing that runs, and it runs fast. Cloudflare, DataDome, Akamai, and every serious anti-bot system maintain or query databases of IP behavior history. A datacenter IP from an AWS range gets flagged before a single request header is read. A known proxy exit node gets challenged. A residential IP with a clean history gets provisionally admitted. Provisionally. That word matters. Cloudflare maintains what it calls a Threat Score for IP addresses, running from 0 to 100. Scores above 15 typically trigger security challenges, according to Cloudflare’s published documentation. A score of 0 is perfectly clean. A score of 100 is a confirmed malicious source. This is entirely IP-level, historical, and reputation-based. It tells the system who is knocking on the door. Once you’re inside the session, the analysis switches. The system stops asking “who is this IP?” and starts asking “how is this session behaving?” Those are different questions answered by different engines, and one does not substitute for the other. The Core Distinction IP reputation determines whether your session gets started. Behavioral analysis determines whether it stays alive. They run on different signal sets, with different timing, evaluated by different ML models. What Gets Scored Before Your First Header Before behavioral analysis even starts, two signals get evaluated at the connection layer. Both run before a single HTTP header is read. This is where a lot of people who have already solved the IP problem run into trouble, and it took me longer than it should have to work out why. S Sachin Supunthaka — Senior Software Engineer I spent most of an afternoon debugging a pipeline that was passing IP checks and returning 403s on a DataDome-protected target. I’d confirmed the residential IPs were clean. Headers looked correct. User-agent was right. The block was happening at the TLS layer, before any of that mattered. I didn’t know DataDome was reading the JA4 fingerprint at the connection level before even touching the request payload. Changing the HTTP library to one that could impersonate a real Chrome TLS signature fixed it immediately. The IP was never the problem. JA4 / TLS Fingerprint When your client establishes an HTTPS connection, it sends a TLS ClientHello message before any application data flows. This message contains the cipher suite ordering, supported extensions, elliptic curves, and signature algorithms your client supports. JA4 hashes these into a single identifier that uniquely identifies the TLS implementation doing the handshaking. 🔑 JA4 TLS Fingerprint A hash of the TLS ClientHello message that identifies which client library is making the connection. JA4 is the 2025-2026 standard, replacing the older JA3. Cloudflare, DataDome, and Akamai all read JA4 at the connection layer before inspecting any HTTP content. Python’s requests module, curl, and virtually every standard scraping library carry a distinctive, recognizable JA4 hash. The consequence is direct. Python’s requests module has a known JA4 signature. So does httpx, curl, and every standard scraping library. According to Scrapfly’s DataDome bypass documentation, DataDome scores the TLS ClientHello before any payload is read, and a non-Chrome JA4 hash alone is enough to escalate the session to a slider CAPTCHA. The block happens before your user-agent, your headers, or your cookies are even examined. Akamai introduced JA4 as its commercial TLS fingerprinting standard in 2026, catching automation libraries that had previously learned to spoof the older JA3 hash format, according to PROXIES.SX’s 2026 anti-bot guide. Cloudflare’s Enterprise Bot Management also integrates JA4 deeply into its WAF rule engine. HTTP/2 Frame Fingerprint The second connection-layer signal is HTTP/2 frame ordering. HTTP/2 sends frames in sequences that differ between browser implementations. Chrome, Firefox, Safari, and curl

Aug 13, 2026
read more
How Mobile Proxy IP Rotation Actually Works on Carrier Networks | TorchProxiesProxy Guides

How Mobile Proxy IP Rotation Actually Works on Carrier Networks | TorchProxies

How Mobile Proxy IP Rotation Actually Works on Carrier Networks | TorchProxies Home › Blog › How Mobile Proxy IP Rotation Works on Carrier Networks Proxy Fundamentals How Mobile Proxy IPRotation Actually Workson Carrier Networks “Rotate” looks like a button. Underneath it is a real network procedure: a carrier tearing down and rebuilding a session, a gateway deciding when to release an address, and a shared IP pool that was never exclusively yours. Here’s how mobile IP rotation actually works, layer by layer. Amasha Vidumini | August 12, 2026 | 14 min read Key Takeaways Mobile IP rotation isn’t proxy-provider magic; it rides on real carrier engineering. A new IP usually means a device went through a fresh PDP context (4G) or PDU session (5G) setup, per 3GPP standards TS 23.401 and TS 23.502. Quick reconnects often don’t change your IP. Carrier gateways use address hold timers, documented as short as 120 seconds in Cisco’s P-GW configuration guides, so a subscriber who reconnects fast gets the same address back. CGNAT is why a carrier IP was never really “yours” alone. Per IETF RFC 6888, carriers share one public IPv4 address across many subscribers; NFWare’s deployment guidance caps this around 128 subscribers per IP, while Cloudflare has observed real-world sharing reach into the hundreds or thousands. “Rotate” buttons trigger provider-side session routing, not carrier commands. SOAX, Oxylabs, and IPRoyal documentation all describe rotation as choosing among IPs already available in a managed pool, layered on top of the carrier’s own churn. Proxyway’s 2026 market research puts advertised mobile proxy pool sizes anywhere from 5 million to 33 million IPs across major providers, with a median around 16 million, and notes that only 9 to 10 of the 13 providers it benchmarks even offer a mobile product at all; Bright Data discontinued its mobile proxy line entirely in April 2026 (Proxyway, “Proxy Market Research 2026”, published Mar-Apr 2026). Mobile proxies are a shrinking-provider, premium niche, even as the underlying thing that makes them valuable, a constantly churning pool of carrier-assigned IPs, hasn’t changed at all. That’s the gap this guide fills. Most explainers describe mobile IP rotation from the buyer’s side: click a button, set a session duration, get a new IP. Almost none explain what’s actually happening underneath that button, on the carrier’s own network. This piece walks through the real mechanism: how a phone gets an IP address in the first place, why that address changes when it does, why it sometimes doesn’t change even when you ask it to, and where a proxy provider’s “rotate” command actually sits in that chain. If you already know the difference between a rotating, sticky, and dedicated mobile session and just need to pick one, our comparison of rotating, sticky, and dedicated mobile proxies covers that buyer’s-guide ground; this piece is about the network layer underneath it. Advertised Mobile Proxy IP Pool Sizes (2026) Advertised Mobile Proxy IP Pool Sizes by Provider (2026) Proxyway’s 2026 market research found advertised mobile proxy IP pool sizes ranging from 5 million to 33 million across major providers, with SOAX leading at 33 million and a median around 16 million. Only 9 to 10 of the 13 benchmarked providers offer mobile proxies at all. Source: Proxyway, Proxy Market Research 2026. Millions of IPs, by provider SOAX 33M Market median ~16M Market low end 5M Providers offering mobile 9-10 of 13 benchmarked Source: Proxyway, “Proxy Market Research 2026.” What “Rotation” Actually Means at the Network Layer 🔄 Mobile Proxy IP Rotation The process by which a mobile device’s public-facing IP address changes, either because the underlying carrier network assigns it a new address as part of normal network operation, or because a proxy provider’s routing layer switches which device or session in its managed pool is currently handling your traffic. Those are two different events happening at two different layers, and conflating them is where most confusion starts. The carrier-side event is a real network procedure: a device disconnects from and reattaches to the mobile core, and as part of that reattachment, the network allocates it an address. The provider-side event is a routing decision made entirely inside the proxy provider’s own infrastructure: pick a different already-connected device or session ID to route your next request through. A “rotate” button can trigger either, or both, but they are not the same mechanism, and understanding the difference explains a lot of behavior that otherwise looks arbitrary, like why a rotation request sometimes hands you back an IP you just had. The Carrier Side: How a Phone Gets (and Loses) Its IP On 4G/LTE networks, a device’s IP address is tied to its PDN connection, formally an EPS bearer established during the network Attach procedure. When a device attaches, the Mobility Management Entity selects a Packet Data Network Gateway, and that P-GW allocates the PDN address, either statically from data the carrier already holds about the subscriber, or dynamically from an address pool, then delivers it to the device inside the Attach Accept message (3GPP TS 23.401, the governing 3GPP standard for LTE/EPS network procedures). A fresh Attach, triggered by something like toggling airplane mode, a full radio deregistration, or an explicit PDN connection release, restarts this allocation cycle and can hand the device a different address than it had before. 5G networks use the equivalent PDU Session instead of a PDP context, but the mechanism is structurally the same: the device sends a PDU Session Establishment Request through the base station and Access and Mobility Management Function to the Session Management Function, which selects a User Plane Function and allocates the session’s IP address or prefix, sometimes at establishment and sometimes deferred to a follow-up DHCPv4 exchange once the session is already up (3GPP TS 23.502, the 3GPP standard for 5G system procedures, ETSI mirror V18.5.0). The important distinction for rotation purposes: a handover, where an active session moves from one cell tower to another, is specifically designed to preserve the existing session and its address, while establishing

Aug 12, 2026
read more
Rotating vs Sticky vs Dedicated Mobile Proxies Explained | TorchProxiesProxy Guides

Rotating vs Sticky vs Dedicated Mobile Proxies Explained | TorchProxies

Rotating vs Sticky vs Dedicated Mobile Proxies Explained | TorchProxies Home › Blog › Rotating vs Sticky vs Dedicated Mobile Proxies Proxy Fundamentals Rotating vs Sticky vsDedicated Mobile Proxies Explained Rotating, sticky, and “dedicated” aren’t three different mobile proxy products, they’re three session-duration settings on the same carrier IP pool. Here’s how long a sticky session actually lasts across real providers, how session binding works, and why a truly permanent mobile IP doesn’t really exist. Amasha Vidumini | August 11, 2026 | 15 min read TL;DR Rotating mobile proxies assign a new carrier IP on every request or on a short timer. Sticky sessions hold one IP for a set window, 10 minutes by default on most providers, up to 24 hours or longer on some. “Dedicated” mobile proxies don’t really exist as a permanent IP the way dedicated ISP proxies do; the ceiling is just a very long sticky session, or a physical dongle rented per device. Choose rotating for high-volume, identity-per-attempt scraping. Choose sticky for anything that needs one identity to survive a multi-step flow like login or checkout. Choose the longest sticky window (or a dedicated device) for account warm-up, and know going in that it’s not a permanent IP. Sticky session duration varies widely by provider. Decodo defaults to 10 minutes with a custom range up to 1,440 minutes (24 hours); Oxylabs caps at 24 hours; Byteful extends to 7 days; DataImpulse and Evomi cap around 120 minutes. No mainstream provider sells a truly permanent mobile IP. The practical “dedicated” ceiling is the longest sticky session on offer, or a physically rented device where the IP can still change with the carrier. Ban resistance works the same across all three modes, since it comes from CGNAT sharing (a single carrier IP can represent anywhere from roughly 128 to thousands of real subscribers), not from the session length you pick. Rotating and sticky are usually billed at the same per-GB rate. Oxylabs’ published pricing runs from $7.50/GB at the entry tier to $3.50/GB at the top corporate tier, regardless of session mode. At least 56 new proxy providers entered the market between 2025 and March 2026, and nearly as many of them sold mobile IP access as sold residential proxies, according to Proxyway’s 2026 market research; the same report notes at least one provider, Rayobyte, cut mobile proxy prices by as much as 98% over the period (Proxyway, “Proxy Market Research 2026”, published Mar-Apr 2026). Mobile proxies have gone from a niche, expensive category to a crowded one, and pricing pressure is pulling more buyers in who don’t yet know the difference between a rotating session, a sticky session, and a “dedicated” one. That confusion is the actual problem this guide solves. Unlike a residential-vs-ISP comparison, rotating, sticky, and dedicated aren’t three different proxy products; they’re three different session modes you can usually pick between on the same mobile IP pool. Picking the wrong one doesn’t just cost you speed, it can break the exact workflow you’re trying to run, like a checkout flow that silently switches IP mid-transaction. This guide covers what each mode actually does, how long a sticky session really lasts across real providers, why “dedicated” is a looser term for mobile than it is for ISP or datacenter proxies, and which mode fits which job. Quick Comparison Category Rotating Sticky Session “Dedicated” IP behavior New carrier IP per request, or per short timer Same carrier IP held for a set duration Same IP for the longest window offered, or a rented physical device Typical duration Per request, or as short as 10 seconds 1-60 min presets, default 10 min, up to 24h+ Up to 24h-7 days (still session-based) Real provider ceiling Per-request (SOAX, Oxylabs) 24h (Decodo, Oxylabs); 7 days (Byteful) No permanent IP guaranteed by any mainstream provider Billing sensitivity Data-heavy: connection overhead per short session Balanced: one session covers a full user flow Most conservative on data, least available at scale Best for High-volume, identity-per-attempt scraping Multi-step flows: login, checkout, forms Account warm-up, long-lived continuity What Is a Rotating Mobile Proxy? 🔄 Rotating Mobile Proxy A mobile proxy configured to assign a new carrier-network IP address either on every outbound request or automatically after a short, fixed interval, so no single request shares an identity with the next one. Rotation is the default mode for most mobile proxy pools because it maps naturally onto how the underlying network already behaves: a real phone reconnecting to a cell tower gets reassigned an IP from the carrier’s pool anyway. Providers just expose that natural churn as a feature. SOAX’s developer documentation describes a rotate-requests_N parameter that rotates after a set number of requests (configurable up to 1,000,000) and a rotate-timed_N parameter that rotates on a timer, alongside the default behavior of rotating on every new connection (SOAX Developer Docs, “Core Concepts”). Proxyway’s 2026 provider comparison confirms the same per-request-or-timer pattern across Oxylabs, Decodo, Byteful, DataImpulse, and Evomi, each exposing rotation as the opposite end of a dial from a long sticky session (Proxyway, “Best 5G/4G/3G/LTE Mobile Proxy Providers of 2026”, updated Aug 6, 2026). Verdict Rotating is the right default for anything where each request is independent and a fresh identity per attempt matters more than continuity, like scraping product listings across thousands of pages where no single page depends on the last one’s session state. What Is a Sticky Session Mobile Proxy? 📌 Sticky Session Mobile Proxy A mobile proxy configured to hold the same carrier IP address for a defined window of time, so a sequence of requests, like a login followed by a page load followed by a form submission, all appear to originate from the same device and connection instead of a new one on every hop. This is the mode most people actually mean when they ask for a “sticky sessions mobile proxy,” and the concrete duration numbers vary more than most buyers expect. Decodo’s own documentation for mobile proxy custom sticky sessions states a default sticky duration

Aug 11, 2026
read more