The platform supports two ways to authenticate proxy connections: username/password credentials, or an IP whitelist that lets up to three of your machines connect to <proxy-host>:80 with no credentials at all. This guide covers how each method works, the cases where whitelisting is genuinely better, and the caveats you should weigh first — your egress IP must be static, anyone on a whitelisted IP can spend your data, and targeting parameters require a username.
Credential auth is the default and the more flexible option: it works from any IP, over HTTP, HTTPS (CONNECT) and SOCKS5, and the username doubles as the carrier for geo targeting and sticky sessions. Whitelisting exists for the situations where credentials are impractical — hardware or software that cannot send proxy authentication, or setups where you do not want a username and password sitting in a config file.
Both methods use the same endpoint and draw from the same data balance. Nothing about the network changes — only how the gateway decides the traffic is yours.
01 Two ways to prove identity
When a client connects to <proxy-host>:80, the gateway has to attribute the connection to an account before it forwards anything. There are exactly two mechanisms for that.
- Credential auth — your client sends a proxy username and password with the connection. Works from any IP, on any of the three supported protocols.
- IP whitelist — you register up to 3 exact IP addresses in the dashboard. Connections arriving from those addresses are attributed to your account automatically, with no username or password sent.
The rest of this article walks through each in turn, then the trade-offs between them.
02 Credential auth recap
The proxy generator produces credential lines in whatever format your tool expects — user:pass@host:port, host:port:user:pass, full http:// or socks5:// URLs, or a custom template. A typical request looks like this.
curl -x "http://user123:pass456@<proxy-host>:80" https://example.comThe username is more than a login. It carries targeting parameters as suffixes: -cc-US for country, -ct-Dallas for city, -asn-13335 for a specific network, -s-abc123 for a sticky session, -ttl-600 for session lifetime.
user123-cc-US-s-mysession-ttl-600Because everything rides in the username, credential auth works anywhere a tool accepts proxy authentication — and every connection can carry different targeting without touching your account settings.
03 How IP whitelisting works
The whitelist holds up to 3 entries, and each entry is one exact IP address — CIDR ranges are not accepted, so you cannot whitelist a subnet. Once an address is on the list, anything it sends to <proxy-host>:80 is treated as yours.
- 01Find the public egress IP of the machine that will use the proxy — the address the internet sees, not the machine's LAN address.
- 02Add that IP to the whitelist in the dashboard.
- 03Point your tool at
<proxy-host>:80with the username and password fields left empty. - 04Send a test request to confirm the connection is accepted.
curl -x "http://<proxy-host>:80" https://example.comNote
The built-in proxy checker tests your own credentials, not whitelist entries. The quickest whitelist test is a plain request from the whitelisted machine, as above.
04 When whitelisting is better
For most workloads, credentials are the right default. Whitelisting earns its place in two situations.
- Tools and devices without proxy-auth support. Some routers, embedded devices, appliances, and older software let you set a proxy host and port but have no field for a username and password. A whitelisted IP is the only way to route them through the network.
- Keeping credentials out of configs. Scripts, dotfiles, CI pipelines, and shared config files have a way of ending up in repositories, screenshots, and log output. With whitelist auth there is no secret in the config to leak — the file only contains a hostname and a port.
A dedicated server with a fixed IP is the ideal whitelist client: the address never changes, and you control everything that runs on it.
05 Requirements and caveats
Your egress IP must be static. Whitelist entries are exact matches, and most home connections get a new address from the ISP periodically — sometimes after every modem restart. When that happens, whitelisted connections simply stop working. If your IP is dynamic, stick with credential auth or expect to update the list regularly.
Warning
Anyone who can send traffic from a whitelisted IP can consume your data, and the usage is billed to your account. Never whitelist a shared address — an office NAT, a VPN exit node, a cloud NAT gateway shared across tenants, or any machine other people control.
Targeting requires the username. Country, continent, city, ASN, sticky sessions, and TTL are all username suffixes, so controlling any of them means authenticating with credentials. A connection that sends no username gets the default behavior: a rotating IP with a new address per request. Plan whitelist-only setups around that default, and use credential auth for any traffic that needs geo or sticky control.
06 Managing the whitelist
Whitelist entries are added and removed in the dashboard. A few habits keep the list from becoming a liability.
- Verify the machine's current public IP immediately before adding it — a stale address wastes one of your three slots.
- Remove entries for machines you have decommissioned or no longer control. An old entry is standing access to your data balance.
- Treat the list like a credential. Review it whenever you review the rest of your account security — sessions, 2FA, and backup codes.
Note
If whitelisted connections suddenly start failing, check your current public IP first — ISP reassignment is the most common cause. The troubleshooting guide covers the rest of the diagnosis order.
There is no need to commit to one method permanently. Use credentials where targeting and portability matter, and reserve the three whitelist slots for the fixed machines that genuinely cannot send them.