Proxy Authentication Methods: Username/Password vs IP Whitelisting

Why proxies need authentication

A paid proxy is a metered resource. The provider needs to know which customer is sending traffic so it can bill you, enforce your plan limits, apply your targeting settings and stop strangers from using your bandwidth. There are two standard ways to identify yourself: credentials (username and password) and IP whitelisting (also called IP allowlisting or IP authorisation).

Method 1: Username and password

With credential authentication, every connection to the proxy includes your username and password. For HTTP proxies they're sent in the Proxy-Authorization header using Basic auth (base64-encoded, not encrypted). For SOCKS5 they're sent in the handshake.

The common formats you'll see:

http://username:password@host:port
host:port:username:password
username:password@host:port

The second format (ip:port:user:pass) is the standard for sneaker bots and many desktop tools. The first (URL format) is standard for code.

Credentials as configuration

Most rotating providers use the username as a configuration string. For example:

customer-acme-country-gb-city-london-session-x7k2-sesstime-15

This tells the gateway to use a UK IP in London, held as sticky session x7k2 for 15 minutes. Changing the session ID gives you a new IP. Every provider's syntax differs, so check their docs or use their proxy-list generator. See sticky vs rotating sessions.

Pros

• Works from anywhere, including laptops on changing networks and cloud functions with dynamic IPs.
• Lets you encode targeting and session settings per connection.
• Supports multiple sub-users with separate limits.

Cons

• Credentials can leak in logs, screenshots and code repositories.
• Some clients don't support proxy auth properly. Notably, Chrome ignores credentials in the --proxy-server flag and doesn't support SOCKS5 auth at all.
• Special characters in passwords must be URL-encoded (@ becomes %40, : becomes %3A).

Method 2: IP whitelisting

With IP whitelisting, you register your server's or home's public IP address in the provider's dashboard. Any connection from that IP is accepted without credentials.

Pros

• No credentials to leak or manage.
• Works with any client, including those that can't do proxy auth (such as Chrome with SOCKS5).
• Slightly less overhead per connection.

Cons

• Only works from fixed IPs. Home connections with dynamic IPs need updating whenever the IP changes.
• Targeting and sessions are usually controlled by port numbers or dashboard settings instead of the username.
• Limited number of whitelist slots on many plans.
• Anyone else on the same public IP (a shared office or a NAT'd cloud environment) can use your proxies.

Which should you use?

Using credentials in common tools

curl:

curl -x http://USER:PASS@gate.example.com:7777 https://httpbin.org/ip
# or
curl -x http://gate.example.com:7777 -U USER:PASS https://httpbin.org/ip

Python requests:

from urllib.parse import quote
user, pw = "customer-acme", quote("p@ss:word", safe="")
proxy = f"http://{user}:{pw}@gate.example.com:7777"

Puppeteer: launch with --proxy-server and call page.authenticate(). See Puppeteer proxy authentication.

Playwright: pass { server, username, password } in the proxy option. See Playwright proxies.

Fixing "407 Proxy Authentication Required"

1. Check username and password for typos and stray spaces.
2. URL-encode special characters in the password.
3. Confirm your plan is active and has traffic left.
4. If using whitelisting, check your current public IP (curl https://api.ipify.org) matches the whitelisted one.
5. Make sure the tool actually sends proxy credentials (Chrome's flag doesn't).
6. Check you're using the correct port for authenticated vs whitelisted access; some providers separate them.

More in common proxy errors.

Security tips

• Store credentials in environment variables or a secrets manager, never in source code.
• Use sub-users with traffic limits for each project or teammate.
• Rotate passwords if a credential might have leaked.
• Prefer TLS connections to the proxy on untrusted networks. See HTTP vs HTTPS proxies.

Authentication in sneaker bots and desktop tools

Most sneaker bots and desktop tools accept host:port:user:pass lines. A few tips:

• Watch for hidden characters when copying lists from emails or web pages (trailing spaces, Windows line endings).
• Colons in passwords break the colon-separated format. Avoid them or ask the provider for a different password.
• Whitelisting with bots means each line is just host:port. Make sure your bot server's IP is whitelisted, not your home IP.

See sneaker proxy setup guide.

Managing credentials across a team

Many providers expose sub-user management through an API, which you can wire into deployment scripts so each environment gets its own credentials.

Authentication and rotation together

With rotating residential providers, the username often carries the session ID, so each new session is effectively a new "credential". That has two implications:

1. Tools that cache proxy auth (notably Chrome) may keep using an old session until the connection closes. Use a new browser context or connection for each session. See Puppeteer proxy authentication.
2. Logs can fill with unique usernames. Mask credentials in logs.

Reading a 407 response properly

When authentication fails, the proxy's response tells you more than the status code alone. Run curl with -v and look for lines like these:

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="proxy"

• Proxy-Authenticate: Basic means the proxy wants a username and password. Your credentials were missing, wrong or badly encoded.
• No 407 at all, just a closed connection or a 403, often means you're on a whitelist-only port, or your current IP isn't on the allowlist.
• A 407 that only appears after many successful requests can mean your plan has run out of traffic or hit a limit. Providers signal this in different ways, so read the response body and check your dashboard.
• Proxy-Authenticate: NTLM or Negotiate almost never comes from a commercial proxy provider. It usually means your traffic is hitting an office or corporate proxy before it reaches the one you bought. See forward vs reverse proxy on corporate gateways.

For the formal definition of the exchange, see MDN's page on the 407 status code and the authentication sections of RFC 9110. For other status codes and what they mean, see common proxy errors, and if you suspect the wrong port, proxy ports explained.

Choosing quickly

• Fixed servers you control: whitelisting.
• Everything else: username/password, stored securely.
• Chrome with SOCKS5: whitelisting or a local forwarder.