Whitelisting or a username and password: two ways in, and which to pick

Before a single byte of your traffic moves, the proxy has to answer one question: is this request allowed? There are two ways to prove it is — an IP whitelist, or a username and password. Both work. What trips people up is that they do not combine, and the moment you set one up, it becomes the only way in. Understanding that one rule prevents most of the access problems people run into in their first week.

The whitelist: your IP address is the key

A whitelist ties access to where you are connecting from. You add one or more public IP addresses in the dashboard, and from then on those addresses are let straight through — no username, no password, nothing to type. Anything coming from an address that is not on the list is refused, even if it sends flawless credentials.

The appeal is convenience. Once your server’s IP is on the list, every tool on that machine just works, with no secrets to paste into config files or leak into a log. For a fixed server with a stable address, this is clean and quiet.

The catch is movement. Whitelisting assumes your IP holds still, and a lot of connections do not. Home broadband, mobile tethering, and many cloud instances hand you a new address on their own schedule. The address you whitelisted last week may not be the one you are on now, and the instant it changes, the door closes — with no warning other than connections that suddenly refuse.

Username and password: the key travels with you

The other method attaches access to a credential pair rather than a location. You send a username and password with each request, and as long as they are correct, the connection is accepted from anywhere. Change networks, move to a new server, work from a laptop on hotel wifi — none of it matters, because you are proving who you are, not where you are.

This is the method that survives a changing IP, which is why it is the calmer choice for any connection that is not nailed to a fixed address. The credentials live in your dashboard; you paste them into your client and they keep working across networks and reboots.

If your connection’s IP can change — and most home and mobile lines change theirs regularly — username and password is the setup that will not surprise you.

Why you cannot run both at once

Here is the rule that catches people: the two methods do not layer. The presence of any whitelist entry switches your account to IP-gated access, full stop. Once a single address is on the list, username and password stop being accepted, and only whitelisted IPs get in.

So a common tangle looks like this: someone adds their office IP to the whitelist to test it, then later tries to connect from a script using their username and password, and it refuses. The credentials are correct. The problem is that the lone whitelist entry quietly turned off password access for everything. The fix is to pick one path and commit to it — either keep the whitelist and make sure every connecting IP is on it, or clear the whitelist entirely and rely on the credentials.

Which one fits your setup

A short way to decide:

• You connect from one or a few servers with fixed IPs. Whitelisting is a good fit. Add those addresses and forget about credentials.
• You connect from a home line, a mobile connection, or anywhere the IP changes. Use username and password. It travels with you and will not lock you out when the address rotates.
• You are handing access to a teammate or a tool on a machine you do not control. Username and password is usually easier — no need to chase down and whitelist their address.
• You want the tightest possible lock and you have stable IPs. Whitelisting is stricter, because even a leaked credential is useless from an address that is not on the list.

There is no wrong answer here, only a wrong mix. Trouble comes from half-configuring both.

Test that your chosen method actually works

You do not have to wonder whether it is set up right. One request from a terminal tells you. Swap in your own details — for username and password:

curl -x "http://user123:[email protected]:10000" https://api.ipify.org

If an IP that is not yours comes back with a 200, the credential path is working. If you get a 407, the username or password is being rejected — re-copy them from the dashboard. If the connection refuses outright, check whether a stray whitelist entry has switched your account to IP-gated mode.

For the whitelist path, run the same request with no credentials from a machine whose IP is on the list. A clean response means the address is recognized. A refusal means the IP you are on is not the one you whitelisted — open https://api.ipify.org from that exact machine to see the address it is actually using, and make sure that is what is on the list.

Changing your mind later

Switching methods is a dashboard change, not a support ticket. Clear the whitelist to fall back to username and password from any IP, or add addresses to move to IP-gated access. Give it a moment to take effect and re-run the terminal test above so you are not debugging a stale state.

The whole thing comes down to one sentence: a whitelist locks access to where you are, credentials lock it to who you are, and the two do not share a lock. Pick the one that matches how your connections behave — fixed address or moving one — and the most common access headache never shows up. If a connection still refuses after you have settled on a method and tested it, send us the product, the endpoint, and the exact error at [email protected] and we will trace it. More on reading those errors in why a proxy connection gets reset.