Every proxy needs a way to know that a request comes from its owner. There are two common methods: a username and password sent with each connection, or a proxy IP whitelist that lets in traffic from addresses you list in advance. Both keep strangers off your proxy. They differ in where they work, what breaks them and how you recover when something leaks. This guide explains both, then walks through a few real setups and how to choose.
How username and password authentication works
With password authentication, the proxy accepts a connection from any IP address, then asks for credentials. Your client answers with a username and password, and the proxy either relays your traffic or refuses.
- HTTP proxies use the
Proxy-Authorizationheader. When a client connects without it, the proxy replies with status407 Proxy Authentication Required, and the client retries with credentials. - SOCKS5 proxies have their own username and password step during the connection handshake.
In practice you usually write the credentials into a proxy URL:
curl -x http://USERNAME:PASSWORD@HOST:PORT https://example.com
curl -x socks5h://USERNAME:PASSWORD@HOST:PORT https://example.comThe strength of this method is portability. You can use the proxy from a laptop on hotel Wi-Fi, a phone on mobile data and a server, with no setup beyond the credentials. The weakness is that the credentials travel inside configuration files, scripts and tool settings, and anyone who copies them can use your proxy from anywhere.
How a proxy IP whitelist works
With an IP whitelist (also called an allowlist), the proxy checks the source IP of each connection. If it is on your list, the traffic goes through with no username or password. If it is not, the connection is refused.
Your client then needs only the host and port:
curl -x http://HOST:PORT https://example.comThe strength is that there is nothing secret to leak: knowing the host and port is useless unless the request also comes from an allowed address. It also solves a practical problem. Many apps and operating system settings either cannot send proxy credentials at all, or handle them badly for SOCKS5. Chrome does not accept a username and password for SOCKS5 proxies, and the system proxy settings on Windows and macOS are unreliable with authenticated SOCKS5. With a whitelist, those apps simply connect.
The weakness is that your source IP must be stable and must be yours alone.
Proxy IP whitelist vs password: the trade-offs
| Username and password | IP whitelist | |
|---|---|---|
| Where you can connect from | Anywhere | Only listed IPs |
| What can leak | The credentials | Nothing secret; the risk is an allowed IP shared with others |
| App support | Needs an app that can send credentials | Works with any app that accepts host and port |
| SOCKS5 in browsers and OS settings | Often unsupported or unreliable | Works |
| Changing networks | No change needed | Update the list |
| Recovery after a leak | Rotate the password | Remove the IP from the list |
The hidden risk of whitelisting the wrong IP
A whitelist trusts everyone who shares the allowed address. That is fine when the address is a server you control. It is a problem when it is not:
- Home connections often get a public IP that changes after a router restart or a few days, so the whitelist silently stops matching.
- Mobile networks and some home ISPs put many customers behind one shared public IP (carrier-grade NAT). Whitelisting that IP opens the proxy to strangers on the same network.
- Office and coworking networks share one IP among everyone in the building.
Before you add an address, check what your public IP is from the machine that will use the proxy, and ask whether it belongs only to you. A cloud server with its own public IP is the cleanest source: the address does not change while the server exists, and nobody else sends traffic from it.
Common setups
A scraper or bot on a VPS
Whitelist the server's public IP and drop credentials from your code. Your scripts and environment files no longer contain anything worth stealing. This pairs well with the patterns in Python scraping with proxies.
A browser or OS setting that needs SOCKS5
Use the whitelist. Browser and system settings are where password authentication for SOCKS5 most often fails. The Chrome and Firefox setup guide and the Windows 11 and macOS guide cover the steps.
A team working from changing locations
Keep password authentication. Give each person only the proxies they need, and rotate the password when someone leaves.
An antidetect browser or automation tool
Most of these tools accept full credentials per profile, so passwords work well. Use the whitelist only if every profile runs from one fixed machine.
How it works on Cloudj
Cloudj proxies use username and password authentication by default. You can switch to an IP whitelist of up to 20 addresses instead; the whitelist replaces password access, so connections from listed IPs work without credentials and others are refused.
Credentials (host, port, username and password) are shown in the Cloudj console. Each time they are viewed, the view is logged and you get a notice, so an unexpected view is a signal to act. You can rotate the password from the console at any time; the old password stops working, which cuts off anyone who copied it. If you use the whitelist, review the list when a server is deleted or an office changes provider.
This applies to both proxy types: dedicated IPv4 proxies, which use ISP-registered static IPs, and the static residential proxies offered in the United States and Vietnam. For the wider picture, read the dedicated proxy guide and dedicated vs shared proxy, and see SOCKS5 vs HTTP proxy for how authentication differs by protocol.
A short checklist
- List every place the proxy will run: servers, laptops, phones, tools.
- If all of them have fixed IPs that belong only to you, use the whitelist.
- If any of them moves between networks, use passwords for those, or put a small VPS in the path.
- Never whitelist a shared office, mobile or carrier-grade NAT address.
- Rotate passwords after staff changes, after sharing a config, and whenever you get a credential view notice you did not expect.
FAQ
Can I use a whitelist and a password at the same time?
On Cloudj the whitelist replaces password access, so pick the method that fits where the proxy will be used.
How many IPs can I whitelist?
Up to 20 addresses on Cloudj.
What happens to my tools when I rotate the password?
The old password stops working, so update every tool that used it. Plan rotations for a quiet moment.
Why does Chrome keep failing with my SOCKS5 proxy?
Chrome does not support a username and password for SOCKS5. Whitelist your IP, or use an HTTP proxy, which Chrome can authenticate.
Choosing your method
If your proxies run from servers with fixed IPs, the whitelist is simpler and leaves no secrets in your code. If people connect from changing networks, keep passwords and rotate them on a schedule. You can switch methods and rotate credentials in the Cloudj console, and live per-IP prices are on the pricing page.