How to whitelist your server ip for a mobile proxy (no-password auth)

You bought a mobile proxy and the provider sent you a host, a port, a username, and a password. Then somewhere in the dashboard there is a second option called ip allowlisting, and nobody explains when you would use it instead of the password. This is the part that fills that gap.

I run a hardware proxy farm in Singapore, real phones on real SIM cards from Singtel, M1, and StarHub, so I set up these connections every day. Ip allowlisting looks fiddly until you see the shape of it. Once you do, you will reach for it on every server you own.

The two ways to authenticate

There are two ways to prove a proxy connection is yours, and allowlisting only makes sense next to the other one.

The first is a username and password. You paste both into your tool along with the host and port, and the gateway checks them on every connection. 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 keeps changing.

The second is ip allowlisting, which some people call whitelisting. Instead of proving who you are with a secret, you prove it with where you connect from. You register your server’s public address once, and after that the server connects with no user and no pass at all, because the gateway already trusts the source ip.

Why allowlist at all

The honest reason allowlisting wins is that credentials are the thing that leaks. A username and password sitting in a config file, hardcoded in a script, or pushed to a git repo by accident is a secret you have to protect forever. With allowlisting there is nothing in your code to leak in the first place. The auth lives in the provider’s dashboard, not in your source.

That is why it fits servers and automation so well. A scraper on a fixed box does not move around, so it does not need portable credentials. It needs to be clean. No secret in the environment, no secret in the repo, nothing to rotate when someone leaves. The box connects, the gateway recognises the address, and the traffic flows.

How it works end to end

The flow is short:

find your server’s real outbound ip
paste that ip into the allowlist in your provider dashboard and save
on the server, connect with just the host and port, no user or pass in the connection string

The gateway sees the request arrive from an address it already trusts and lets the traffic straight through.

Finding your server’s real outbound ip

The address you want is not the one your server shows on its own network card. It is the public address the rest of the internet sees when your server reaches out. The clean way to find it is to ask a neutral endpoint from the server itself.

# run this ON the server that will use the proxy
curl -s https://api.ipify.org

Run it from the exact machine that will use the proxy, not from your laptop, because they almost certainly have different outbound addresses. If your server sits behind a nat gateway, which is normal in cloud setups, the address you get back is the gateway’s address, and that is the correct one to allowlist. Every box behind that gateway shares it.

The big gotcha: dynamic ips

Allowlisting only works if your server’s outbound ip is stable. If that address is dynamic, it will change on its own schedule, your old entry stops matching, and access dies. The failure is nasty because nothing in your code changed. The proxy just looks broken and your requests start getting refused.

So allowlisting works best on a static ip, or a vps where the public address is fixed and yours for the life of the box. On a home connection or a cheap dynamic plan, expect the address to rotate and expect the allowlist to break with it. That is not a bug, it is just what a dynamic ip does.

Two related caveats. Behind nat, a whole office or cloud subnet can share one outbound address, so everything behind it shares the same allowlist entry. And on budget hosting you sometimes share a public ip with other customers, and you cannot safely allowlist an address you do not control alone.

You can mix methods

You do not have to choose one method forever. Most providers, mine included, let you run both. Allowlist your production servers so they run clean with no credentials, and keep a username and password for your laptop so you can still test from anywhere. The two coexist on one account. Use the address where the address is stable, and the password where it is not.

The security tradeoff

Allowlisting is not free of risk. When you trust an ip, you trust everything connecting from that ip. If anyone else is on the same address, through a shared box, a shared nat, or a server you did not lock down, they can use your proxy too, and the gateway will let them, because as far as it knows they are you.

So lock the box down. Treat an allowlisted server as a key. Keep it patched, firewall it, and keep it off limits to anyone who does not need it.

Verify it works

Never assume auth works. From the allowlisted server, run one curl through the proxy to a neutral endpoint:

# no user:pass, the allowlist is doing the auth
curl -x http://gw.singaporemobileproxy.com:8000 https://ipinfo.io

If it comes back with a Singapore address on Singtel, M1, or StarHub, your allowlist is live and the box is trusted. If it comes back refused, your outbound ip is not the one you registered, and nine times out of ten that is the dynamic ip gotcha biting you. Check the real outbound address again and compare.

The whole thing in one line

Two ways to authenticate: password or allowlist. Allowlisting trades a portable secret for a trusted address, which keeps credentials out of your code and is cleaner for servers and automation. Find your server’s real outbound ip from the box itself, register it, then connect with just host and port. It works best on a static ip or a vps, watch for nat and shared addresses, you can mix methods, and you must lock the box down because the ip is the key.

If you want to run this on a real Singapore connection, there is a free trial of Singapore Mobile Proxy, real SG mobile ips, sticky sessions, and dns that routes through the tunnel, all from my own farm. Use code YT30 for a discount on your first month.

Get new guides and videos first — join the Telegram channel.