# 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](https://docs.joinmassive.com/residential/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](https://www.joinmassive.com/glossary/what-is-a-mobile-proxy) covers the general definition. In short: | Type | Exit IP comes from | Typical use | |---|---|---| | Residential proxy | A home internet connection | Seeing a site as a local household does | | Mobile proxy | A mobile carrier's network (4G or 5G) | Seeing a site as a phone on a carrier does | | Mobile residential proxy (Massive `type-mobile`) | A mobile device on the residential network; carrier IP when paired with a carrier `asn` | Device-specific checks, carrier-specific checks | 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`. ```text 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: ```text me-type-mobile-country-US -subdivision-NY-session-1 ``` (written here on two lines for space; it is one string). The three values: | Value | Matches | |---|---| | `mobile` | Mobile devices | | `common` | Any non-mobile device | | `tv` | TV devices | 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](https://docs.joinmassive.com/residential/asn-type-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: | ASN | Registered name | Organization | |---|---|---| | 21928 | T-MOBILE-AS21928 | T-Mobile USA, Inc. | | 20057 | ATT-MOBILITY-LLC-AS20057 | AT&T Enterprises, LLC | | 6167 | CELLCO-PART | Verizon Business | | 22394 | CELLCO | Verizon Business | 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](https://www.joinmassive.com/blog/proxy-geo-targeting-city-zip-asn) covers the location and ASN options in more depth. ### Keep the same phone with a sticky session Add `session-` 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](https://docs.joinmassive.com/residential/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: ```text 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](https://www.joinmassive.com/blog/sticky-vs-rotating-proxies) covers when to use a session at all. ![Diagram of how one Massive proxy username combines options. The login, then type-mobile for the device type, country-US for location, asn-21928 for the carrier network, and session-7 for a sticky session, joined with hyphens. Notes: type accepts mobile, common, or tv; only one option may hold a comma-separated list; an unknown type returns 400; no matching device returns 471.](assets/mobile-login-anatomy.png "Anatomy of a Massive proxy username with device-type targeting.") ## 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`.
PYTHON
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`.
PYTHON
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](https://docs.joinmassive.com/residential/error-types)). Our `407` probe had no `X-Reason` header. The ones you're most likely to see with device targeting: | Code | Meaning | What to do | |---|---|---| | `400` | Malformed request, such as an unknown `type` | Fix the username | | `407` | Login or API key incorrect | Check credentials | | `471` | No Route Match: no node matched the targeting | Relax the filters, for example drop the city | | `475` | Sticky Node Gone: the session's node went offline | Start a new session | | `477` | Sticky Node At Capacity | Retry the same session after a short delay | For errors that come from the target site rather than the network, see our guide to [common proxy errors](https://www.joinmassive.com/blog/fix-and-troubleshoot-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. ## Frequently Asked Questions ### What are mobile residential proxies? They are proxies that route requests through mobile devices, such as phones, on a residential network of real users. On Massive's network you select them with `type-mobile` in the proxy username. ### What is the difference between mobile and residential proxies? Residential proxies exit through home internet connections. Mobile proxies exit through mobile carrier networks. Massive's `type-mobile` selects mobile devices, and pairing it with a carrier's ASN asks for one on that carrier's network. ### How do I target a specific mobile carrier? Add the carrier's ASN to the username, for example `asn-21928` for T-Mobile USA, alongside `type-mobile`. You can list up to 5 ASNs, but only one option per request may be a list. ### Can I keep the same mobile IP across requests? Within limits. A sticky session keeps requests on the same device, on a best-effort basis, for 15 minutes by default or up to 1,440 minutes with `sessionttl`. It pins the device, not the IP, and in the default strict mode any error moves you to a new device. Use `sessionmode-norotate` to fail instead of switching. ### What happens if no mobile device matches my targeting? The network returns `471 No Route Match`. Retries fail until you relax the targeting, for example by removing the city or the ASN. ## 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](https://docs.joinmassive.com/residential/device-type-targeting) - Massive docs, [ASN identifier targeting](https://docs.joinmassive.com/residential/asn-type-targeting) - Massive docs, [Sticky sessions](https://docs.joinmassive.com/residential/sticky-sessions) - Massive docs, [Error types](https://docs.joinmassive.com/residential/error-types) - ARIN, [RDAP lookup for AS21928](https://rdap.arin.net/registry/autnum/21928), 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)