Proxy Authentication
The method used to verify that a user is authorized to use a proxy endpoint - either username/password credentials or IP address whitelisting.
Proxy authentication prevents unauthorized use of proxy services. Two main methods exist: username/password authentication and IP whitelist authentication.
Username/password authentication requires including credentials in the proxy URL: http://username:password@host:port. The proxy server validates credentials before forwarding the request. This method works from any IP address, making it flexible for distributed systems.
IP whitelist authentication grants access based on your outgoing IP address. You register your IP (or IP range) with the provider, and requests from that IP are allowed without credentials. No username or password needed in the request - simpler to configure.
When to use username/password: applications running on dynamic IPs, distributed systems where workers run on different machines, or when you cannot control the outgoing IP. When to use IP whitelist: servers with static IPs, simpler configuration for trusted environments, and when you prefer not to store credentials in application code.
Some proxy configurations support both methods simultaneously. Username/password is more portable; IP whitelist is simpler for static deployments.
Proving the connection belongs to a customer
A proxy has to decide whether to serve a connection. Two mechanisms are in common use: credentials sent with the connection, or a whitelist of addresses that are trusted without credentials.
With HTTP, credentials travel in a Proxy-Authorization header and a failure returns 407, which is distinct from the 401 a destination would send. With SOCKS5, authentication is part of the protocol handshake, which is why a SOCKS client asks for a username and password before any request is made.
The distinction between 401 and 407 is the single most useful diagnostic in this area. One means the proxy refused you, the other means the destination did, and confusing them sends people to debug the wrong system.
How our products authenticate
Everything uses login and password, and residential can additionally trust your server addresses:
Both mechanisms
Credentials login[_suffixes]:password@proxy.sotaproxy.com:10000
login:password@your-ip:50100 for static
Whitelist register your server address, then connect without
credentials from it (residential lists)
GET/POST /user/residential/whitelist- 407 means we rejected the login. Nine times out of ten a suffix is malformed rather than the password being wrong.
- Some tools cannot send proxy credentials at all. Selenium is the classic case, which is why selenium-wire or a generated extension exists.
- Whitelist servers, not laptops. Home connections change address and the failure looks like a proxy fault.
- Keep credentials working alongside a whitelist so a change of server address does not lock you out entirely.
Authentication confusions
407 is not 401
The first comes from us, the second from the site. They send you to different places to debug.
Credentials in the launch flag rarely work
Chromium-based tools take host and port only. Authentication happens through a separate call.
Whitelisting is not more secure by default
It swaps a secret for a location, which is safer only if the address is exclusively yours.
A password is not per-proxy on residential
One package password serves every session and every suffix combination.
Related terms
See this in practice
Ready to use proxy authentication?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started