Mobile proxy setup: HTTP vs SOCKS5, ports, and your first connection

You bought a mobile proxy and the provider sent you one cryptic line: a host, a port, a username, a password, and somewhere a choice between HTTP and SOCKS5. If you have ever stared at that and wondered what actually goes where, this is the part nobody explains before they sell you the proxy.

So here is the whole setup, plainly. What the four fields mean, which protocol to pick, how to prove the connection is yours, and the one curl command that confirms a real Singapore IP before you waste an hour wiring it into a scraper. I run the hardware these IPs come from, real phones on real SIM cards, so I set up these exact connections every day.

The four fields, fast

Every proxy you will ever buy is some arrangement of four fields. Read your credential as these and the rest is easy.

Field	What it is
host	the address you connect to (a stable hostname, not your phone’s IP)
port	selects the line, the protocol, and sometimes sticky vs rotating
username	proves the connection is yours
password	proves the connection is yours

The usual shape is host:port:username:password, for example proxy.singaporemobileproxy.com:5210:user123:pass456. That is the whole thing. Once you can see those four parts, every tool you plug them into works the same way.

The host is not your phone’s IP

The host is the field people misread the most. It is a stable gateway endpoint, a hostname that never changes. The real mobile IP sits behind it and rotates on the carrier schedule, the way every real phone on Singtel, M1, or StarHub gets a new address as the network manages its pool.

This is the part that saves you. You point your tools at the host once and forget it. The address behind it can change a hundred times and your setup never breaks, because you were never talking to the raw IP in the first place. If a guide tells you to hardcode the rotating IP itself, ignore it. Connect to the gateway and let the rotation happen invisibly behind it. (If you are still fuzzy on why mobile IPs rotate at all, the what is a mobile proxy explainer covers it.)

The port is a switch, not a detail

The port is how the provider tells one line apart from another. One modem, one port. If you have three proxies, you have three ports on the same host, and each one is a different phone on a different SIM.

Two things live on the port that trip people up:

your HTTP connection and your SOCKS5 connection usually sit on two different ports
your sticky endpoint and your rotating endpoint can sit on two different ports as well

So the port is not a throwaway number. It decides what protocol you speak and whether your IP holds or rotates. Connect to the wrong one and the proxy works fine while doing the opposite of what you wanted.

HTTP vs SOCKS5: the one protocol choice

Here is the version without the jargon.

	HTTP proxy	SOCKS5 proxy
Level	understands web traffic	lower level, moves raw bytes
Works with	browsers, most scrapers, most tools	anything, including non-web traffic
DNS	resolves normally	use `socks5h` to resolve through the proxy
Pick it for	the default for most jobs	tools that only speak SOCKS, or non-standard traffic

An HTTP proxy speaks the same language as your browser. It works with almost every scraper out of the box and it is the right default for most jobs. A SOCKS5 proxy is lower level. It does not care what kind of traffic you send, it just moves the bytes, which makes it the better pick for anything that is not plain web requests.

Always use socks5h, with the h

If you take one thing from this whole guide, take this. When you use SOCKS5, write socks5h, with the h on the end, not plain socks5. That single letter tells your tool to resolve DNS through the proxy instead of on your own machine.

Without it, your computer quietly looks up the website on your real connection before the proxy is ever involved. That is a DNS leak, and it can give you away even though your traffic looks proxied. The same idea applies when you set SOCKS5 up for messaging apps, which I covered in the MTProto vs SOCKS5 guide.

Two ways to prove the connection is yours

There are two ways to authenticate, and you pick by where you connect from.

Username and password. You paste the credentials into your tool along with the host and port. This works from anywhere, on any network, which is why it is the default. Use it when you move around, connect from a laptop, or your address changes.

IP allowlisting. You tell the provider the address of your own server, and from then on that server connects with no username or password at all. The provider already trusts where it is coming from. Use it when you run from a fixed server and you would rather keep credentials out of your code.

One quiet gotcha: if you set up allowlisting and forget to add your current address, every connection gets refused. It looks like the proxy is broken when it is just doing its job. Add your IP first.

Your first connection: one curl command

Before you wire a proxy into any big tool, test it with one line. Pass the proxy as a flag, hit a neutral endpoint that reports your IP back, and read the result.

# HTTP
curl -x http://user123:pass456@proxy.singaporemobileproxy.com:5210 https://ipinfo.io

# SOCKS5 (note the h, so DNS resolves through the proxy)
curl -x socks5h://user123:pass456@proxy.singaporemobileproxy.com:5211 https://ipinfo.io

If it comes back with a Singapore address on Singtel, M1, or StarHub, you are connected and you are done. If it errors, you have learned something useful before you spent an hour wiring it into a scraper.

When the result comes back, check three things, not one:

the IP is actually Singapore, and not your own
the carrier is a real mobile carrier, not a datacenter name
if you used socks5h, the location lines up, which confirms DNS resolved through the tunnel

The same credential, in every tool

Once curl passes, every other tool is the same idea with a different box to type in.

Browser or antidetect browser: host and port in the proxy settings, username and password in the fields underneath.
python requests: proxies={"http": "http://user:pass@host:port", "https": "http://user:pass@host:port"}
Playwright / Puppeteer: the same host, port, username, and password passed as a proxy option.

There is nothing new to learn per tool. It is always those same four fields plus the protocol you chose.

Sticky or rotating: decide before you start

One setup decision shapes everything after it. A rotating endpoint hands you a fresh IP on the carrier schedule, which is what you want for spreading lots of small requests. A sticky endpoint holds one IP for a set window, so a login or a checkout can finish on a single address. You usually pick between them by connecting to a different port, so decide what the job needs before you start, not halfway through.

The five setup mistakes I see most

Plain socks5 instead of socks5h, which leaks your DNS.
The wrong port, so you connect to the rotating line when you wanted sticky.
A local firewall or VPN sitting in the way and eating the connection.
IP allowlisting set up but your address never added.
A three second timeout left over from datacenter proxies, when mobile latency needs fifteen to thirty.

Every one of these looks like a broken proxy. None of them are.

The whole setup in one breath

Read the credential as four fields: host, port, username, password. Point at the host, because it never changes. Pick your port for the protocol and the rotation you want. Use HTTP for most things, and socks5h when you need remote DNS. Authenticate with a password or an allowlisted server. Then prove it with one curl to a neutral endpoint, and confirm a real Singapore carrier IP before you build anything on top of it.

If you want to run these exact steps on a real Singapore connection, there is a free trial of Singapore Mobile Proxy, real SIMs on Singtel, M1, and StarHub from my own farm. You get the host, the port, both protocols, and your credentials, and you can curl test it in the first minute.