Using your proxy

Connect via SOCKS5

Each proxy port speaks one protocol — SOCKS5 or HTTP(S) — chosen when you create it. SOCKS5 (via socks5://) is the right default for most tools; create an HTTP(S) port (http://user:pass@host:PORT) for tools that only speak HTTP — one of each if you need both. Ports on the same device share its carrier exit IP and rotate together. Anything that speaks either protocol can use them — browsers, scrapers, antidetect browsers, curl.

Where DNS gets resolved

With socks5:// your own machine resolves the hostname before connecting. To resolve it on the phone’s carrier network instead — so a geo-aware DNS answers for the exit rather than for you — use socks5h:// with the same host, port and credentials, or tick your client’s “proxy DNS” option.

curl

curl -x socks5://USERNAME:PASSWORD@GATEWAY:PORT \
     https://api.ipify.org?format=json

HTTP(S) instead of SOCKS5

Prefer an HTTP proxy? Create a proxy port with protocol: http — it gets its own port and credentials. It carries HTTPS via CONNECT, so your traffic stays end-to-end encrypted. If a tool needs both protocols, create one port of each — they share the device's exit IP and rotate together.

curl -x http://USERNAME:PASSWORD@GATEWAY:PORT \
     https://api.ipify.org?format=json

Python (requests)

Install the SOCKS extra: pip install "requests[socks]".

import requests

proxy = "socks5://USERNAME:PASSWORD@GATEWAY:PORT"
r = requests.get(
    "https://httpbin.org/ip",
    proxies={"http": proxy, "https": proxy},
    timeout=30,
)
print(r.json())

Node.js

Install node-fetch and socks-proxy-agent; Node's global fetch ignores the non-standard agent option.

import fetch from "node-fetch";
import { SocksProxyAgent } from "socks-proxy-agent";

const agent = new SocksProxyAgent(
  "socks5://USERNAME:PASSWORD@GATEWAY:PORT"
);
const res = await fetch("https://api.ipify.org?format=json", { agent });
console.log(await res.json());

UDP (QUIC/HTTP3, DNS)

SOCKS5 ports also carry UDP, using the standard UDP ASSOCIATE command from RFC 1928 — QUIC/HTTP3 and DNS egress your carrier IP just like TCP does. HTTP(S) ports cannot carry UDP; that is a limit of the HTTP proxy protocol, not of your device.

Your client has to ask for it. Tools that only issue CONNECT — curl, most HTTP libraries — stay on TCP no matter which URL scheme you use, so socks5:// alone does not turn UDP on. Use a QUIC/HTTP3 client that speaks SOCKS5 UDP, or a tunneller (Clash, sing-box, tun2socks) that routes a whole app's UDP through the proxy.

Browsers are the common disappointment here: Chrome and Firefox generally disable QUIC and refuse to send WebRTC media through a configured SOCKS5 proxy, so they fall back to TCP. That is browser behaviour — route them through a tunneller if you need their UDP on the carrier IP.

Antidetect browsers & other tools

Most multi-account and antidetect browsers (and scraping frameworks) have a proxy field. Choose SOCKS5, then fill in the host, port, username, and password from your proxy — or paste the whole socks5://user:pass@host:port URL where a single "proxy URL" is accepted.

Pick a mobile profile — Android, or iOS — rather than a desktop one. Your traffic leaves from a real Android phone on a carrier network, so the TCP/IP characteristics a site can observe are those of a mobile device. A profile claiming Windows or macOS over a mobile carrier IP is a mismatch you are creating yourself; matching the profile to the exit keeps the whole story consistent without anything having to be faked.

One phone, many tools

Mint a separate credential for each tool or customer so you can watch and revoke each independently — see Managing credentials. They all share the phone's single carrier IP.

What's blocked

Private and link-local ranges (SSRF protection) and known-abusive destinations are filtered at the gateway before they reach your phone. Legitimate target blocked by mistake? Tell us — our filters are auditable.