How does proxy authentication work?

9 November 2026

Proxy authentication is how a proxy checks that you are allowed to use it. The two usual methods are a username and password sent by your program, or a list of IP addresses the proxy accepts without a password. With ordinary HTTP and SOCKS5 proxies, the password travels unencrypted.

Why proxies require authentication

Anyone can use an open proxy. It can end up carrying spam and attacks, its address gets blocked, and its owner pays for traffic they never asked for. Authentication ties every connection to an account, so usage can be counted and anyone without a right to it kept out.

Authentication with an HTTP proxy

It uses HTTP's challenge and response mechanism, with two headers reserved for proxies. In order:

1. The program sends its request, such as CONNECT, without credentials.
2. The proxy answers 407 Proxy Authentication Required with a Proxy-Authenticate header naming the authentication scheme it wants.
3. The program repeats the same request with a Proxy-Authorization header carrying the credentials.
4. If they are valid, the proxy carries out the request. If not, it answers 407 again.

RFC 9110, section 15.5.8 defines status 407 and requires the proxy to send a Proxy-Authenticate header with it. It is the proxy's counterpart of 401, which a website itself sends when it wants credentials, together with the WWW-Authenticate and Authorization headers.

The simplest scheme is Basic, described in RFC 7617. The program joins the username and password with a colon and encodes the result in Base64. For the username user and password pass, the exchange looks like this:

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

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz

Base64 is an encoding, not encryption. Anyone who captures that line recovers user:pass in a second, and the standard itself warns that the scheme is not secure without TLS. Companies sometimes use other schemes, such as Digest and Negotiate, which avoid sending the password itself.

Where the credentials stop

The Proxy-Authorization header is addressed to the proxy, not the website. RFC 9110, section 11.7.2 says that in a chain of proxies it is consumed by the first proxy that expects credentials. That proxy may relay it to the next one if the proxies cooperate on authentication.

So the site you visit never sees your proxy password. Anyone between you and the proxy does, unless that stretch is encrypted.

How often it is sent depends on the request. For https sites it goes once, in the CONNECT request, per tunnel. For http:// sites every request carries it, so it crosses the network far more often.

Authentication with SOCKS5

In SOCKS5 the client lists the authentication methods it supports in its first message, and the server picks one. Username/password is method 02 in RFC 1928, and its details are in RFC 1929:

1. The client sends the subnegotiation version (01), then the username's length and the username, then the password's length and the password. Each is 1 to 255 bytes.
2. The server answers with a one-byte status. 00 means success.
3. Any other value means failure, and the server must then close the connection.

Username and password travel exactly as typed, with no encoding and no encryption. The standard itself advises against the method wherever traffic can be sniffed.

Chrome supports no SOCKS5 authentication method at all, so it needs an extension or a local helper. The two protocols are compared in full in SOCKS5 vs HTTP proxy.

IP allowlists

The second method needs no password. You add your public IP address to a list in your account, and the proxy accepts any connection that comes from it. It works with programs that cannot authenticate, and leaves no secret written in configuration files.

Its limits are clear, though. Anyone who shares your public address can use the proxy as you: colleagues in the office, people in the same café, or other subscribers behind a mobile carrier's NAT, as What is CGNAT explains.

If your address changes, as it can on home and mobile connections, the proxy stops working until you update the list.

The methods compared

Putting credentials into programs

Most programs accept credentials inside the proxy URL, as scheme://user:pass@host:port. If the password contains characters that mean something in a URL, such as @, : or /, percent-encode them: @ becomes %40 and : becomes %3A. Or pass them separately, as curl allows:

curl -x http://user:p%40ss@proxy.example.com:8080 https://example.com/
curl -x http://proxy.example.com:8080 --proxy-user 'user:p@ss' https://example.com/

Both lines are equivalent, and the password in each is p@ss. Bear in mind that any command you type with a password lands in your shell history. In scripts, read credentials from an environment variable or a file outside the repository, and never commit them to version control.

How to test authentication

Run curl with -v and deliberately wrong credentials. An HTTP proxy should answer 407, and a SOCKS5 server should close the connection.

If the proxy works with wrong credentials, it is either not checking them or your address is on an allowlist. Then repeat with the right credentials and confirm the exit address.

How to protect your credentials

• On a network you do not trust, use an HTTPS proxy so the password is encrypted on the way. See CONNECT and HTTPS proxies.
• Give the proxy service a password you use nowhere else, since it crosses the network more often than most.
• Change it at once if it appears in a shared script or a screenshot, or if you see usage you do not recognise.
• Do not combine an IP allowlist with a shared network, such as an office or a mobile connection.

At syriaproxy

Our SOCKS5 and HTTP proxies require a username and password, and carry them unencrypted like any proxy of those types. The HTTPS proxy encrypts the whole path between your device and our server, credentials included. Step-by-step setup is in Proxy setup.

FAQ

Test your proxy with your credentials using the free proxy checker: whether it accepts them, its response time, and its exit address.