The essential points from this guide -- each one is explained in detail below.
HTTP proxies use the 407 Proxy Authentication Required status code to challenge unauthenticated clients.
The Proxy-Authorization header carries Base64-encoded credentials, separate from the standard Authorization header used for target servers.
SOCKS5 authentication follows RFC 1929 with a binary username/password sub-negotiation during the handshake.
IP allowlisting skips credential exchange entirely -- the proxy trusts requests from pre-registered source IPs.
Targeting parameters (country, city, session) are commonly encoded in the username field alongside credentials.
When a client sends a request to an HTTP proxy without credentials, the proxy responds with 407 Proxy Authentication Required and a Proxy-Authenticate header specifying the authentication scheme (usually Basic). The client retransmits the request with a Proxy-Authorization: Basic <base64(username:password)> header. The proxy validates the credentials and, if accepted, forwards the request to the destination.
This is distinct from the 401 Unauthorized / Authorization header pair used for authenticating with the destination server itself. A client can carry both headers simultaneously -- Proxy-Authorization for the proxy and Authorization for the target -- without conflict. For HTTPS requests tunneled via CONNECT, the Proxy-Authorization header is sent with the initial CONNECT request, and all subsequent traffic flows through the encrypted tunnel without the proxy seeing it.
SOCKS5 (RFC 1928) separates authentication from request forwarding into distinct phases. The client first sends a greeting listing its supported authentication methods (0x00 for no auth, 0x02 for username/password). The server responds with the chosen method. If 0x02 is selected, the client sends a username/password sub-negotiation packet per RFC 1929: a version byte (0x01), username length, username bytes, password length, and password bytes. The server responds with a status byte: 0x00 for success, anything else for failure.
Only after successful authentication does the client send the actual CONNECT request specifying the destination address and port. This binary handshake is more efficient than HTTP's text-based challenge-response -- there is no round-trip for the 407 challenge because the client always sends credentials proactively in the greeting phase. This makes SOCKS5 slightly faster for high-volume connections.
IP allowlisting (also called IP whitelisting) authenticates clients by their source IP address rather than credentials. You register your server's IP addresses in the proxy provider's dashboard, and the proxy accepts any connection from those IPs without requiring a username or password. This simplifies integration because your code does not need to manage credentials or handle 407 challenges.
The tradeoff is flexibility. IP allowlisting only works when your source IPs are static and known in advance. If you run scraping jobs from dynamic cloud instances (spot instances, serverless functions), your source IP changes with each deployment, making allowlisting impractical. In those environments, username-password authentication is the standard approach. KnoxProxy supports both methods and allows them to be used simultaneously on the same account.
Commercial proxy providers use the username field to carry more than just identity. KnoxProxy's username format embeds targeting and session parameters: user-country-us-city-newyork-session-abc123. The gateway parses these parameters during authentication and uses them to select the appropriate exit IP from the pool.
This design avoids the need for a separate control API or configuration endpoint. Every request is self-describing: the username contains the full routing specification. Different requests from the same account can target different countries simply by changing the username string. The password remains constant for the account. This pattern is an industry standard -- Bright Data, Oxylabs, and other providers use similar username-encoded targeting.
Ready to put this into practice? Browse all proxy types
KnoxProxy Research Team · Technical Content
Network engineers and proxy infrastructure specialists with 10+ years in anti-bot systems, web scraping, and IP routing.
90.4M+ ethically sourced residential IPs across 195 countries. Start free -- no credit card required.