How to Set Up Mobile Proxies
Your provider gives you four values. This guide covers what each one means, the three formats they get written in and which tools expect which, how to authenticate, and how to prove the proxy is carrying your traffic before you build on it.
- Four values, nothing to install — host, port, username and password go straight into the tool you already use.
- Three ways to write them — the format your tool expects is the single most common reason a correct credential is rejected.
- Two ways to authenticate — credentials travel with the request, or your own IP is whitelisted and no login is sent at all.
- One check that settles it — echo your exit IP and compare it to your real address before building anything on top.
An ordinary HTTP(S) and SOCKS5 endpoint — no vendor client or SDK.
Username and password, or whitelist your own address and send no login.
What Your Provider Gives You, and What Each Field Means
Buying a mobile proxy does not give you an application to install. It gives you four values, and every piece of software that can use a proxy already knows what to do with them. Your browser knows. Your shell knows. Python knows. The work of setting up a proxy is entirely the work of putting four values in the right place, in the right shape.
Those four values are the address of the proxy, the port it listens on, and a username and password that prove the connection is yours rather than someone else’s. Nothing else is required, and any guide that starts by asking you to install a client is describing a convenience layer, not a requirement.
| Field | What it actually is | Where people go wrong |
|---|---|---|
| Host | The address of the proxy server — a hostname or an IP address. This is not the IP your traffic will exit from. | Confusing it with the exit IP, then reporting that the proxy is showing the wrong country. |
| Port | Which service on that host to talk to. HTTP and SOCKS5 are two different ports on the same proxy. | Sending HTTP credentials to the SOCKS5 port. The failure looks exactly like a wrong password. |
| Username | Identifies the connection as belonging to your account. On PXM2 the HTTP and SOCKS5 ports each have their own. | Reusing one protocol’s username on the other port. |
| Password | The secret half of the pair, sent with every request unless you are using IP whitelisting instead. | Special characters that must be escaped when the password is embedded in a URL. |
The separate-ports detail catches more people than any other. A PXM2 proxy exposes an HTTP(S) port and a SOCKS5 port, each with its own username and password. Credentials that are entirely valid on one port are rejected on the other, and the error returned is the generic authentication failure — so it reads as a bad password rather than as a wrong port.
One more distinction matters before you configure anything. The host you connect to stays the same; the IP that websites see changes when the proxy rotates. Those are two different addresses, and mixing them up is why people occasionally conclude that a proxy in one country is reporting another.
The Same Credentials, Written Three Ways
Here is the part that guides tend to skip, and it is the single most common reason a correct set of credentials gets rejected. Those four values are written in three different shapes depending on what is consuming them, and the shapes are not interchangeable. Some tools want one string. Some want a URL. Some want four separate fields and will choke on anything that contains a colon.
1. Colon-delimited string proxy.example.net:8000:user123:s3cret 2. Proxy URL http://user123:[email protected]:8000 3. Separate fields Host: proxy.example.net Port: 8000 User: user123 Pass: s3cret
| Format | Tools that expect it | What happens if you use the wrong one |
|---|---|---|
| Colon-delimited string | Antidetect browsers, proxy managers, bulk import fields, most bots that accept a proxy list | Pasted into a URL field it is treated as a hostname, and the connection fails before authentication is ever attempted. |
| Proxy URL | Environment variables, command-line tools, HTTP client libraries, container runtimes | Pasted into a host field, the whole string becomes the hostname and DNS resolution fails. |
| Separate fields | Operating system network settings, browser proxy dialogs, most graphical applications | A colon-delimited string in the host box, with the port box left empty — a very common paste error. |
When the password contains a character that has a meaning inside a URL — an at-sign, a colon, a slash, a question mark — the URL form needs it percent-encoded, or the URL is parsed in a way you did not intend. An unescaped at-sign is the worst of them, because the parser reads everything before it as the credentials and everything after it as the host, which produces a confident and completely wrong connection attempt. The colon-delimited and separate-field forms have no such problem, since nothing is being parsed.
Password: pa@ss:word Wrong: http://user123:pa@ss:[email protected]:8000 Right: http://user123:pa%40ss%[email protected]:8000 Python: from urllib.parse import quote quote("pa@ss:word", safe="") -> 'pa%40ss%3Aword'
Username and Password, or IP Whitelisting
There are two ways for a proxy to know a connection is yours, and you pick one per situation rather than once for all time. With credential authentication, the username and password travel with every request. With IP whitelisting, you register your own public address with the provider and send no login at all — the proxy recognises where the request came from and lets it through.
Neither method is more secure than the other in any absolute sense. Credentials survive a change of network; whitelisting survives an accidental screenshot. Most people end up using both — whitelisting on servers, credentials on everything that moves.
Verify It Works, and Read the Error When It Does Not
Before you configure anything else, prove that the proxy carries traffic. One request to a service that echoes your public address settles it in a second, and skipping this step means every later problem has two possible causes instead of one.
curl -x http://user123:[email protected]:8000 https://api.ipify.org curl -x socks5h://user123:[email protected]:1080 https://api.ipify.org curl https://api.ipify.org # your real address, for comparison
If the two addresses differ and the proxied one belongs to the carrier and country you bought, you are done — everything after this is configuring individual applications. If they are identical, the proxy is not being used at all, which is far more common than a broken proxy. System-wide proxy settings are quietly ignored by a great many applications, and command-line tools in particular read their own environment variables and nothing else.
Note the socks5h scheme in the second line rather than socks5. The trailing h sends DNS resolution through the proxy as well. Without it your machine resolves hostnames locally, which leaks every domain you visit to your own network even though the traffic itself is proxied.
| What you see | What it means | Where to look |
|---|---|---|
| 407 Proxy Authentication Required | The proxy got the request but no usable login came with it. | Format first, then port. A valid HTTP login on the SOCKS5 port returns this. |
| Tunnel connection failed | The same authentication failure, seen during the CONNECT that sets up an HTTPS tunnel. | Identical causes to a 407 — the client is simply reporting it from a different stage. |
| 403 Forbidden | Authentication succeeded. Something further along refused the request. | The target site, not the proxy. A 403 means you got through. |
| Connection timed out | Nothing answered on that host and port. | A typo in the host, the wrong port, or a local firewall blocking outbound traffic. |
| Your own IP is returned | The request never went through the proxy. | The application is ignoring the proxy setting. Configure it inside the tool instead. |
The general rule for a stubborn 407 is to separate the two things being tested. First prove the endpoint works at all, with the exact host, port and protocol, using a tool you trust. Then prove your application sends the credentials in the shape that tool expected. Debugging both at once is what turns a five-minute problem into an afternoon.
If you would rather not do this from a terminal, the free PXM2 proxy checker runs the same test in a browser and additionally reports the detected proxy type and exit country.
Get a Mobile Proxy to Set Up
Live PXM2 locations — pick the country you need an exit IP in, and you will have the four credentials this guide walks through within minutes:
France
India
Singapore
Frequently Asked Questions
How do I set up a mobile proxy?
Take the host, port, username and password your provider issued and enter them wherever your tool asks for a proxy — system network settings, a browser extension, an environment variable, or a proxy field in code. Then make one request to a service that echoes your public IP and confirm it reports the carrier address rather than your own. Nothing needs to be installed at any point.
What does host:port:username:password mean?
It is one compact way of writing the four values that identify your proxy: the address to connect to, the port to connect on, and the login pair that proves the connection is yours. The colons are only separators. The same four values are equally often written as a single URL, http://username:password@host:port, and many applications instead want them typed into four separate fields.
Why do I get 407 Proxy Authentication Required?
The proxy received your request but no usable credentials came with it. Usually the login was pasted in a format the client does not parse — a bare host:port:user:pass string in a field that wanted a URL, for example — or it was sent to the wrong port. Check the protocol first: HTTP and SOCKS5 are separate ports with separate credential pairs, so a valid HTTP login fails on the SOCKS5 port and returns exactly this error.
Should I use IP whitelisting or username and password?
Use credentials if your own address changes, which it does on any home connection, on mobile data, or from a laptop that moves. Use whitelisting when you are connecting from a server with a fixed address, or from a tool that has nowhere sensible to put a login. Whitelisting also avoids leaking a password into shell history and process listings, which is a real advantage on shared machines.
How do I check which IP my proxy is using?
Send one request through the proxy to any service that returns your public address, and read the answer. If it matches your real IP the proxy is not being used at all, which is far more common than a misconfigured proxy — many system proxy settings are silently ignored by individual applications. The free PXM2 proxy checker performs this test and also reports the detected proxy type and exit country.
Related Mobile Proxy Guides
Once the connection works, the next step depends on what you are configuring — the machine, the runtime, or the way the proxy behaves over time.
Setup guides
Core mobile proxy guides
Set Up a Real Carrier IP in Minutes
Dedicated 4G/5G modems with unlimited bandwidth and unlimited rotations — HTTP(S) and SOCKS5 endpoints, delivered with the four credentials this guide walks through.
Get a Mobile Proxy