Mobile Residential Proxies: How to Target Phones, TVs, or Other Devices by Type

Mobile residential proxies route your requests through mobile devices, such as phones and tablets, that belong to real people on a residential network. On Massive's network you choose the device type per request by adding type-mobile, type-tv, or type-common (any non-mobile device) to your proxy username (Massive docs, device-type targeting). Add a carrier's network number, its ASN, and the request is served by a mobile device on that carrier's network.

This feature update covers how device-type targeting works, how it differs from what most providers sell as "mobile proxies," how to combine it with location, carrier, and sticky sessions, and a tested Python helper that builds the username and checks which IP and country you got. Device-type targeting is a capability spotlight from the live docs, not a new launch.

Key Takeaways

• type accepts mobile, common, and tv, or a comma-separated list such as mobile,tv to match any of them. An unrecognized value returns HTTP 400.
• It "can be used in combination with all other options": country, subdivision, city, ASN, and sticky sessions.
• The docs don't say whether a mobile device is on Wi-Fi or cellular at a given moment. To ask for a carrier network, pair type-mobile with the carrier's asn.
• Only one parameter may hold a list per request. Our helper enforces that rule, and its 9 tests pass offline.
• If no device matches your filters, the network returns 471 No Route Match. Relax the targeting rather than retrying.

Mobile vs residential proxies: what's the difference?

The terms overlap, which is why "mobile vs residential proxies" is a common search. Our glossary entry on what a mobile proxy is covers the general definition. In short:

The distinction that matters is the network, not the hardware. Our reading: a phone at home on Wi-Fi would exit through the household's internet provider, and the same phone on the street through its carrier. Massive's docs describe type-mobile as executing the request "on mobile devices," and don't say which network the device is on at that moment. Massive's own network data (2026) shows that a single device can produce anywhere from 1 to 15 IP addresses a day, depending on its type and how it is used. That is why the carrier ASN matters when the network is the point.

How device-type targeting works on Massive

Massive's residential network reads targeting options from the proxy username, joined by hyphens. In the examples below, me stands for your login, the account email, and the password is your API key. The proxy endpoint is network.joinmassive.com:65535.

me-type-mobile-country-US

That asks for a mobile device in the United States. common means any non-mobile device, not strictly a desktop. The docs show the same pattern with a state and a sticky session:

me-type-mobile-country-US
  -subdivision-NY-session-1

(written here on two lines for space; it is one string). The three values:

A comma-separated list matches any of several types, so type-mobile,tv accepts a mobile or a TV node. An unrecognized value returns 400.

Pair mobile with a carrier ASN

An ASN, or autonomous system number, identifies a network such as a carrier's. Massive's asn option serves the request "by a node on any of the listed networks," with up to 5 values (Massive docs, ASN targeting). Combine it with type-mobile to ask for a phone on a specific carrier. We checked these US carrier ASNs against ARIN's registry on November 1, 2026:

So me-type-mobile-country-US-asn-21928 asks for a mobile device on T-Mobile's US network. One rule limits the combinations: "Only one parameter may hold a list per request." You can list several carriers or several device types, not both. The network accepts up to 5 ASNs; the helper below does not check the count. Our post on proxy geo-targeting by city, ZIP code, and ASN covers the location and ASN options in more depth.

Keep the same phone with a sticky session

Add session-<id> to keep requests on the same device. On the residential network, a session lasts 15 minutes by default, and sessionttl raises that up to 1,440 minutes (Massive docs, sticky sessions). Sessions expire at creation time plus the TTL; later requests don't extend them. Three modes control what happens on errors:

• strict (default): any error moves the session to a new node, as does hitting the node's per-minute request limit.
• flex: the session survives up to 15 consecutive errors by default, adjustable with sessionerr.
• norotate: the request fails instead of switching devices, with 472 on tunnel errors or 475 when the node has gone offline. TTL expiry still starts a new session.

Set the mode with sessionmode, as one more option in the username:

me-type-mobile-country-US
  -asn-21928-session-7
  -sessionmode-norotate

(again one string, wrapped here). Two details from the docs matter. sessionmode is re-parsed on every request, so if a later request with the same session ID leaves it out, the session silently falls back to strict. And sessionttl, sessionerr, and finer location options such as subdivision and zipcode apply only when a session is created or rotated, so changing them mid-session has no effect until it moves to a new node.

country and city are different: they are part of the session's identity, so a new value starts a separate session even with the same ID. For mobile work, norotate is useful when you would rather fail than silently land on a different phone. Our post on sticky vs rotating proxies covers when to use a session at all.

Build and check a mobile request in Python

The helper below builds the username from keyword options, URL-encodes the login (an email contains @), and requests Cloudflare's trace page through the proxy. That page answers with plain key=value lines, including the exit ip and its country as loc, which tells you what the target site sees. Set your API key as MASSIVE_API_KEY.

import os
import urllib.parse as up
import requests
HOST = ("network.joinmassive"
        ".com:65535")
TRACE = ("https://cloudflare"
         ".com/cdn-cgi/trace")
def login(user, **opts):
    lists = [
        v for v in opts.values()
        if isinstance(v, list)]
    if len(lists) > 1:
        raise ValueError(
            "one list only")
    parts = [user]
    for k, v in opts.items():
        if isinstance(v, list):
            v = ",".join(
                map(str, v))
        parts += [k, str(v)]
    return "-".join(parts)

login() follows the docs' examples exactly, and raises an error if you pass two lists. login("me@example.com", type="mobile", country="US", asn=21928) returns me@example.com-type-mobile-country-US-asn-21928.

def proxy_url(name, key):
    u = up.quote(name, safe="")
    k = up.quote(key, safe="")
    return ("https://"
            f"{u}:{k}@{HOST}")
def parse_trace(text):
    return dict(
        line.split("=", 1)
        for line in
        text.splitlines()
        if "=" in line)
def trace(name):
    key = os.environ[
        "MASSIVE_API_KEY"]
    p = proxy_url(name, key)
    r = requests.get(
        TRACE,
        proxies={"https": p},
        timeout=60)
    r.raise_for_status()
    return parse_trace(r.text)

trace() returns a dict such as {"ip": "...", "loc": "US", ...}. To confirm the carrier, look up the returned IP's ASN in a public registry such as ARIN's RDAP service.

All of this is tested offline. 9 tests check the username against the strings in Massive's docs, the one-list rule, URL encoding of the email and commas, trace parsing, and that the request goes through the proxy (network calls are stubbed). On November 1, 2026, we also sent requests with a placeholder login: every variant, including one with type-banana, returned 407 Proxy Authentication Required. The network appears to check credentials before it reads targeting options, so a 400 for a bad type only shows up once your login works.

What errors to expect

Massive's error docs separate network errors from the target site's own errors: codes 452 to 454 and 470 to 477 come from Massive and carry an X-Reason header, while 400, 407, and 429 keep their standard meanings. Apart from those, any other code, "including a plain 500, 502, or 503," came from the site (Massive docs, error types). Our 407 probe had no X-Reason header. The ones you're most likely to see with device targeting:

For errors that come from the target site rather than the network, see our guide to common proxy errors.

When to use mobile residential proxies

Device-type targeting is worth it when the network matters to the answer:

1. Carrier-specific checks. If a site shows different pricing, promotions, or content on a carrier's network, check it with type-mobile plus the carrier's ASN.
2. Mobile ad and landing page verification. See the page a phone on a given network receives, together with a mobile user agent.
3. Comparing device classes. Run the same request through mobile, common, and tv and compare the responses.

Device type changes where the request exits, not what your client says about itself. If you want the mobile version of a page, send a mobile User-Agent header too. For general collection that doesn't depend on the device, plain residential targeting is simpler and matches more nodes.

The bottom line

• Mobile residential proxies on Massive are one option away: type-mobile, type-common, and type-tv choose the device class per request, alone or as a list.
• Pair type-mobile with a carrier ASN when the carrier network matters, and remember only one option can be a list.
• Use sessionmode-norotate when staying on the same phone matters more than finishing every request.

Sources

• Massive docs, Device-type targeting
• Massive docs, ASN identifier targeting
• Massive docs, Sticky sessions
• Massive docs, Error types
• ARIN, RDAP lookup for AS21928, AS20057, AS6167, and AS22394, November 1, 2026
• Massive, placeholder-login requests to the residential network and 9 offline tests of the code above, November 1, 2026 (first-party test)