Access to a paid proxy service is opened in one of two ways: either you send a username and password with every request, or you register your public IP address in the provider's dashboard and create a whitelist (allow list). Both solve the same problem — "does this connection really belong to the subscriber?" — but they produce very different results in daily use.
In this article we cover how the two methods work at the protocol level, which one is right in which scenario and the error codes you will encounter.
Method 1: Username and Password
In this method the credentials are sent to the proxy on every connection. The format changes depending on the protocol:
- HTTP proxy:
Proxy-Authorization: Basic <base64(username:password)>header is added. - SOCKS5: the username/password sub-negotiation defined in RFC 1929 is performed; the username and password are sent in binary form.
On the HTTP side the flow is as follows: the client sends a request without credentials, the proxy responds with 407 Proxy Authentication Required , and the client adds the credentials and repeats the request.
Most clients perform these two round trips automatically. curl and browsers add the credentials and repeat the request when they see a 407; simple HTTP libraries, on the other hand, sometimes do not retry and return an error straight away.
Basic method does not encryptthe credentials, it only encodes them with Base64. Base64 is a reversible encoding. That is why the confidentiality of the credentials depends on the connection to the proxy itself being secure.
Method 2: IP Whitelist
In the whitelist model there is no password. You add your own public IP address in the provider's dashboard; the proxy only accepts connections coming from that address. Since no credentials are carried, the client side becomes very simple: curl -x http://proxy.example.com:8080 https://example.com is enough.
The crucial question for this model is this: is your public IP address static? On most home internet connections the IP is dynamic and changes when the modem restarts. When it changes, the whitelist becomes invalid and all connections are refused.
The choice largely comes down to the question "do you have a static IP?". A whitelist is more suitable for automation running on a server, and a username/password for roaming use.
Which One in Which Scenario?
A scraper or bot running on a server
Your VPS's IP is static; choose a whitelist. Credentials are not embedded in the code or in environment variables, and the leak surface shrinks. For automation scenarios this is the default we recommend.
Manual use from a laptop
If you move between the office, home and a café, your IP changes constantly. Use a username/password; it works without problems from any network.
Shared use within a team
If you need to answer the question of who used how much traffic, create a separate user per person. With a whitelist the whole team appears under a single identity.
Multiple profiles with an antidetect browser
If each profile is to be assigned a different exit IP, a username/password is mandatory, because session selection is usually encoded inside the username (for example user-session-a1).
Embedding Session Information in the Username
There is a common pattern in residential pools: the username is not only an identity, it also carries a command . For example:
The separator character and the parameter names vary from provider to provider. Go by the documentation in your dashboard; the format here is only meant to show the structure.
The advantage of this design is that no API call is needed on the client side: you change country or session simply by changing the username. The disadvantage is that the credentials get longer and typos lead to silent changes in behaviour. Rotating proxy logic is explained in our article, where we cover in detail how this model affects session management.
Common Errors
The difference between 407 and 403 is critical: 407 says "show me your identity", while 403 means "I have seen your identity, you are not authorised".
The Special Character Trap
When you write credentials in URL form, some characters in the password get mixed up with the separators. http://user:p@ss@ip:8080 in this expression, the second @ is taken for the separator and the connection cannot be established. The solution is percent encoding:
| Character | Encoded form | Character | Encoded form |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
A more robust approach is to give the credentials in the client's separate fields instead of embedding them in the URL. Python requests, Node undici and curl's --proxy-user option support this.
Reading the credentials from an environment variable instead of embedding them in the code both prevents them from leaking into version control and makes rotation easier.
What Changes from a Security Perspective?
The two methods carry different risks. In the username/password model the secret can be stolen: a command line that ends up in a log file, a configuration file that slips into version control or a screenshot is enough. In the whitelist model there is no secret, but there is a risk of IP sharing : everyone on the same office network can use your proxy without even realising it.
The most robust configuration is to combine the two: narrow the source with a whitelist and add a username/password on top. Most corporate providers support this hybrid model. On the privacy side, if you are wondering what the proxy sees, our is a proxy safe article offers a comprehensive framework; for leak tests DNS leak and WebRTC leak tools.
Practical Rules for Credential Management
- Use environment variables, do not write them inside the code.
- Create separate credentials for each environment : development, test and production should not share the same password.
- Define quotas and limits; a leaked credential should not be able to consume unlimited traffic.
- Rotate them regularly; always change them after someone leaves the team.
- Mask them in the logs; debug output should not print the password in plain text.
Summary
An IP whitelist is the cleanest solution with the lowest leak risk on servers with a static IP. A username and password, on the other hand, are indispensable for roaming use and scenarios that require multiple sessions. To decide, it is enough to answer the questions "is my IP static", "how many people will use it" and "do I need to send a session parameter". To test your configuration you can use proxy checker tool , and you can verify your exit IP with My IP Address .