Mobile Proxy Setup Guides

Setup Guides by Topic

Four groups, ordered the way a setup actually goes: connect first, then configure the machine, then the code, then everything that keeps it running.

The grouping matters more than it looks. Getting a proxy talking to one browser tab and getting it into a Python scraper or a Docker container are different problems that share only the four credential fields — everything past that point depends on which layer is making the outbound request. A guide on Windows proxy settings will not help a requests.Session() that ignores the operating system entirely, and a Node.js SOCKS5 agent will not fix a curl command run from the same machine's shell. Pick the group that matches where your request actually originates, not the tool you happen to be most comfortable with.

Each guide below is self-contained: credentials, the exact syntax for that language or platform, and a verification step. You do not need to read them in order, but if this is your first mobile proxy, start with the connecting-and-authenticating group before jumping to a specific language — the syntax differs everywhere, but the four values it consumes (host, port, username, password) do not.

Where Should You Start?

Setup problems are rarely about the proxy. They are about which layer you configured — the operating system, the runtime, or the individual application — and whether that layer is the one making the request.

Reading the error instead of guessing

A proxy failure almost always tells you which layer is wrong, if you read past the first line.

• 407 Proxy Authentication Required — The request reached the proxy but the credentials on it were missing, malformed, or sent to the wrong port. Check the protocol first: HTTP credentials sent to the SOCKS5 port return exactly this error.
• Connection refused or timed out — The request never reached the proxy at all. This is almost always a firewall, a typo in the host or port, or a corporate network blocking outbound connections on that port entirely.
• Works in a browser, fails in code — The browser extension or system setting you tested with is not the same configuration your script is reading. Environment variables, library-level proxy arguments, and OS settings are three separate places and only one of them is wired into your code.
• Connects, but returns the wrong IP — Traffic is bypassing the proxy for at least part of the request — commonly DNS resolution happening locally instead of through the tunnel. See the SOCKS5 note below.

Test the proxy before you touch your application

Curl is the fastest way to isolate the proxy from everything else you are building, because it has no application logic of its own to blame. A single request against an IP-echo endpoint, with the host, port, username and password passed directly on the command line, either returns the proxy's IP or it does not — there is no middle layer to misconfigure. If that request fails, the problem is in the credentials or the network path, not in your scraper, and you have saved yourself from debugging two systems simultaneously. PXM2's free proxy checker runs the same kind of check from a browser, without a terminal.

What Every Setup Has in Common

Whatever you are configuring, the same four things decide whether the connection works.

• Four values and no software — Host, port, username and password. A mobile proxy is a standard HTTP or SOCKS5 endpoint, so there is no client to install and no SDK to integrate.
• The format has to match the tool — The same credentials get written as host:port:user:pass, as a http://user:pass@host:port URL, or as four separate fields. Pasting one shape where another is expected is the most common cause of a rejected login.
• HTTP and SOCKS5 are separate ports — On PXM2 each protocol has its own port and its own credential pair. A perfectly valid HTTP login sent to the SOCKS5 port fails, and the error it returns looks identical to a wrong password.
• Verify before you build — One request that echoes your exit IP tells you whether the proxy is carrying traffic at all. Skipping it means debugging your application and the proxy at the same time.

New to mobile proxies entirely? Read what a mobile proxy is and how mobile proxies work first — the configuration below makes considerably more sense afterwards.

Username and password, not IP whitelisting

Datacenter and residential proxies commonly offer a choice between username/password authentication and IP whitelisting, where the proxy accepts any traffic arriving from a pre-approved static IP. Mobile proxies default to username and password for a structural reason: the whole point of a carrier connection is that the outbound IP changes on rotation, so there is no static address to whitelist against. If a guide you find elsewhere assumes IP whitelisting is available, it was written for a different kind of proxy.

socks5:// vs socks5h:// — the difference that breaks scrapers

Most SOCKS5 libraries accept two URL schemes that look interchangeable and are not. socks5:// resolves the hostname on your own machine first and only sends the resulting IP through the proxy — so DNS queries, and anything that can be inferred from them, never touch the mobile network. socks5h:// sends the hostname itself through the proxy and lets it resolve DNS on the carrier side. For scraping and geo-testing this is not a minor detail: resolving DNS locally can return a CDN edge for your real location instead of the proxy's, silently defeating the reason you added a mobile proxy in the first place. Default to socks5h:// unless a specific tool documents otherwise.

Rotation is a setting, not a step

Nothing about connecting to a mobile proxy requires touching rotation at all — a fresh session on a sticky port keeps the same carrier IP until you tell it otherwise. Rotation is configured separately, either on a timer or through a rotation endpoint your account exposes, and it applies on top of a connection that already authenticates correctly. Debug the credentials first with rotation left at its default; adding a second variable before the first one is confirmed working just doubles the number of possible causes for a failure.

Related Mobile Proxy Guides