Skip to main content
Mobile proxies route your traffic through real mobile carrier connections on 3G, 4G, and 5G networks. The IPs come from carriers like Verizon, AT&T, Deutsche Telekom, and others worldwide. SOAX’s mobile pool includes over 30 million IPs from carriers across 195+ countries.

​
How mobile proxies are different

Mobile proxies use the same parameter system, session model, and connection format as residential proxies. The difference is where the traffic exits. With residential proxies, your requests go through home WiFi connections. With mobile proxies, they go through cellular carrier connections. This matters because: Mobile IPs are naturally shared. Carriers use NAT (network address translation) to share IP addresses across many subscribers. This means websites can’t easily block a mobile IP without risking blocking thousands of real users. As a result, mobile IPs tend to have lower detection and block rates than residential IPs on heavily protected targets. Some content is mobile-specific. Certain websites and apps serve different content, pricing, or ads to mobile users. Mobile proxies let you see exactly what a mobile visitor would see. Carrier metadata is different. Mobile IPs carry carrier and network type information (3G/4G/5G) rather than home ISP information. This can be relevant for ad verification, app testing, or any workflow where the connection type matters to the target.

​
When to use mobile proxies

Mobile proxies are the right choice when:
  • Your target site aggressively blocks residential IPs but is more lenient with mobile traffic.
  • You need to verify mobile ads, app content, or carrier-specific behavior.
  • You’re working with social media platforms that scrutinize connection types.
  • You need the lowest possible detection rate and are willing to work with a smaller pool.
For general-purpose scraping, residential proxies are a good starting point. If you’re hitting high block rates on specific targets, switching to mobile is worth testing.

​
Session types

Session behavior is identical to residential proxies. You can use rotating (new IP every request) or ephemeral sessions (same IP across multiple requests).

​
Rotating (no session)

Every request gets a new mobile node. No state between requests.

​
Ephemeral sessions (held IP)

Include a session parameter to bind to a node and reuse the same IP across requests.
Session lifetime:
  • Sessions expire after 60 seconds of inactivity (no requests sent).
  • If the bound node becomes unavailable, the system replaces it based on your error handling rules.
Session ID rules:
  • You choose the session ID (any string you want).
  • Allowed characters: letters, digits, and underscores.
  • Maximum length: 32 characters.
  • Rules are locked on the first request for a given session ID. If you send a second request with the same session ID but different rules, the request is rejected with 409 SESSION_PARAMS_MISMATCH. To change rules, use a new session ID.

​
Geo-targeting

Geo-targeting works the same way as residential. You can filter by country, region, city, carrier (using the isp parameter), ASN, or zip code. Use country-any if you want the full global pool without geographic filtering. Example: target T-Mobile subscribers in New York:
The mobile pool is smaller than the residential pool (30M vs 155M). Very specific targeting (small city + specific carrier) may result in fewer available nodes. If you get 502 NODE_NOT_FOUND errors, try broadening your filters.

​
Rotation rules

Rotation rules control when the system replaces the current node during a session. These work identically to residential. Rotation rules require a session. Without a session parameter, every request already gets a new node. Example: rotate mobile IP every 10 minutes:
Timed rotation doesn’t interrupt requests that are already in progress. The current request finishes on the current node. The next request gets a new node.

​
Error handling

Error handling rules define what happens when a node fails during a session. These apply to infrastructure-level failures only (node offline, connection refused, timeout). Target website responses (HTTP status codes) are not visible to the proxy for HTTPS traffic. Example: retry twice, then replace:

​
Routing preferences

Routing preferences affect which node the system picks when it needs to select or replace a node. This is useful when you want IP changes to feel gradual. If your session was using a Verizon IP in Texas and the node goes offline, prefer-lookalike tells the system to look for another Verizon IP in Texas before falling back to any eligible mobile node. In the dashboard, this is the Prefer lookalike toggle in the Quick Connect (proxy generator) panel. Example:

​
Node binding

If you need strict binding to a single node with no automatic replacement, use bind-node. When bind-node is active:
  • The session is locked to the node assigned on the first request.
  • Rotation rules are ignored.
  • If the node fails, you get an error (503 BOUND_NODE_FAILED) instead of a replacement.
  • You can combine it with onerror-retry_N to retry on the same node before failing.
  • Requires a session parameter.
Example:

​
Network type parameter

To request mobile nodes, include network-mob in your connection string. If your proxy package has both residential and mobile enabled and you don’t specify a network type, the default is res (residential). To use mobile, you need to set it explicitly.

​
Full parameter reference

Every parameter available for mobile proxies via Quick Connect: Connection string format:
Rules are separated by hyphens. Multi-word values use underscores. Rules can appear in any order.

​
Example configurations

Basic rotating proxy, US mobile:
Session, German mobile, 10-minute rotation:
Session with retry on error, then replace with lookalike:
Specific carrier and city:
Locked to a single mobile node:

​
Limits

​
Residential vs mobile: quick comparison

​
Next steps

Residential proxies

Full reference for residential proxy configuration.

Authentication

How to authenticate with username/password or IP Auth.

Error codes

Full list of SOAX error codes with causes and fixes.

Python examples

Working Python code for mobile proxies.