Full reference for SOAX mobile proxies. Covers how mobile routing works, session types, geo-targeting, connection parameters, and limits.
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.
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.
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 behavior is identical to residential proxies. You can use rotating (new IP every request) or ephemeral sessions (same IP across multiple requests).
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.
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.
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 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.
Parameter
Description
onerror-replace
Get a new eligible node. This is the default.
onerror-retry_N
Retry the request up to N times on the same node, then replace. Maximum N is 10.
onerror-fail
Return the error to your client. No retry, no replacement.
Routing preferences affect which node the system picks when it needs to select or replace a node.
Parameter
Description
prefer-lookalike
Prefer a node with similar characteristics to the previous one (same carrier, region, etc.).
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:
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.
Parameter
Description
Values
network
Network type filter
res (residential), mob (mobile), res_mob (both), any (weighted)
