Proxy Authentication: Username/Password vs IP Whitelisting

Every proxy needs to know you are allowed to use it. There are two mechanisms, they behave very differently in practice, and picking the wrong one causes a specific and confusing class of failure.

Username and password

You send credentials with each request:

curl -x http://USER:PASS@HOST:PORT https://api.ipify.org

Works from anywhere. Laptop, office, a colleague’s machine, a cloud function that gets a new IP on every invocation — the credentials travel with the request, so the source address is irrelevant.

The trade-off: those credentials live somewhere. In an environment variable if you are careful, hardcoded in a script if you are not. Anyone who reads them can use your proxy from anywhere, and it will look exactly like legitimate traffic.

Two operational annoyances worth knowing:

• Special characters break URL parsing. A password containing @, : or / will be misread in the user:pass@host form. URL-encode it — @ becomes %40 — or pass credentials via your client’s dedicated auth option rather than the URL.
• Some tools drop them. A few HTTP clients ignore the userinfo portion of a proxy URL entirely. If you get 407 with credentials that work in curl, this is usually why.

IP whitelisting

You register your public IP address, and the proxy accepts any connection from it without credentials:

curl -x http://HOST:PORT https://api.ipify.org

Nothing secret in your code. No credentials to leak in a repository, a log file, or a screenshot. For a server with a static IP running unattended jobs, this is genuinely simpler and safer.

The trade-off: it breaks the moment your IP changes. Home broadband on a dynamic address, mobile tethering, CI runners, serverless functions — all of these get a new IP regularly, and every one of them will start failing with 407 for no visible reason.

This is the confusing failure. Your code did not change. The proxy did not change. Your ISP simply renewed your lease overnight.

Which to use

Choose IP whitelisting when the proxy is used from a server with a fixed address, you want no secrets in your codebase, and the set of machines is small and stable.

Choose username/password when you work from a laptop, your IP is dynamic, you run in CI or serverless, or several people share the proxy from different locations.

When in doubt, use username and password. It fails in obvious ways and works everywhere. IP whitelisting fails silently the day your address rotates, and the error message points at authentication rather than at the real cause.

A note on isolation

If you buy several proxies, check whether they share one credential pair or have their own. Shared account-wide credentials mean a single leaked password exposes every proxy you own, and there is no way to revoke access to one without breaking all of them.

At froxproxy, each order gets its own generated credentials, so a leak is contained to that purchase rather than your whole inventory.

Switching between them

Both modes are available on every static proxy we sell, set from the service page in your dashboard. Whitelisting an IP takes effect immediately; you can register your current address, and change it whenever you move.

A useful habit if you use IP authentication: check your public address before assuming the proxy is broken.

curl -s https://api.ipify.org

If that does not match what you registered, you have found your 407.

Security worth stating plainly

Neither mechanism encrypts your traffic. Authentication proves who may use the proxy; it does nothing about what travels through it. Use HTTPS for anything sensitive regardless of which you pick, and never send credentials or personal data over plain HTTP through any proxy.

For setup specifics see the FAQ, or get in touch if authentication is failing in a way this does not explain.