Proxy Authentication: Methods and Best Practices
Username and password or IP allowlisting, how credentials travel, and how to tell a proxy authentication failure from a target-side block or a bad address.
- proxy-management
- security
Proxy authentication answers a simple question: who is allowed to send traffic through this endpoint. Getting it wrong produces two of the most misdiagnosed errors in proxy work, a 407 that gets mistaken for a target block and a leak in which requests quietly bypass the proxy.
The two methods
Username and password. You send credentials with each request or connection. The proxy validates them and, in many providers, uses parts of the username to encode routing instructions such as country or session.
IP allowlisting. You register the source IPs that may use the proxy, and the proxy identifies you by where the connection comes from. No credentials are sent.
Some providers support both, and some require credentials for one protocol and allowlisting for another.
| Aspect | Username and password | IP allowlisting |
|---|---|---|
| Works from changing IPs | Yes | No |
| Credentials in transit | Yes, unless tunnelled | None |
| Setup effort | Low | Requires knowing your egress IPs first |
| Risk if leaked | Anyone can use your traffic | Tied to specific addresses |
| Typical use | Scripts, CI, cloud workers | Fixed office or server addresses |
Where credentials go
With HTTP, credentials are sent in the Proxy-Authorization header, or embedded in the proxy URL as user:pass@host:port. The header applies to the connection to the proxy, not to the destination, so it does not conflict with the site's own authentication.
With SOCKS5, credentials are exchanged during the protocol handshake. Support varies: some clients handle SOCKS5 authentication cleanly, and others do not expose a field for it at all, which is a common reason a SOCKS5 setup fails where HTTP works.
A practical detail: if you are already using HTTPS to the destination, the tunnel to the proxy for the CONNECT exchange is not itself encrypted in the plain-HTTP proxy case, so credentials should be treated as reusable secrets rather than as well-protected values. That is one of several reasons not to use an untrusted open proxy.
Encoding routing in the username
Many providers let you put routing parameters in the credential. A typical pattern is a base username, then a country or region selector, then a session identifier.
That is how targeting and stickiness are expressed on a single endpoint rather than needing a different host per country. We describe the targeting side in Country, State, and City Targeting and the session side in Understanding Proxy Session IDs.
Handling credentials safely
Treat proxy credentials like any other secret.
- Keep them in environment variables or a secrets manager, never in committed source.
- Do not log them. Proxy URLs printed to logs leak the password, and proxy-aware log scrubbing is easy to forget.
- Use separate sub-users per application. If one application is compromised or needs revoking, the blast radius is limited.
- Rotate on exposure. If a credential reaches a shared channel, rotate it rather than hoping.
- Scope by IP where possible. Allowlisting adds a second factor that a leaked password alone cannot defeat.
Our subuser model exists for exactly this reason: each identity gets its own credentials, so one can be disabled without disturbing the others.
Diagnosing authentication failures
The distinction between a 407 and a 403 saves a lot of time.
- 407 Proxy Authentication Required. The proxy rejected you. Credentials are wrong, missing or malformed, or the source IP is not allowlisted. This is a proxy problem.
- 403 Forbidden. The destination rejected the request. The proxy accepted you fine, and the target objected to the request, the IP or the behaviour. This is a target problem.
Retrying a 407 will never help. Retrying a 403 with a fresh IP sometimes does.
A third failure mode is silent: requests that bypass the proxy entirely and go direct, because a client did not pick up the configuration. Always confirm the exit IP rather than assuming the proxy was used. The proxy checker reports the exit IP a request actually came from, and IP lookup confirms its location.
A sensible default
For anything running from infrastructure with stable addresses, allowlisting plus credentials is the strongest option. For workers with dynamic addresses, credentials are the only workable choice, and they should be issued per application and stored as secrets.
LightningBytes issues credentials per sub-user, supports targeting and session parameters in the username, and applies sticky sessions automatically. The details are on the residential and mobile pages, and the FAQ covers connection problems.