Username–Password Proxy Authentication: How to Connect and Avoid Errors

With username–password authentication, your application sends the proxy the credentials issued by the provider. The proxy checks them and allows you to use the service. This method is useful when working from different devices and networks: if the service does not also require IP authorization, moving a script to another server does not require changing an allowed IP address.

A working connection needs more than a username and password. You also need the correct proxy address, port, and protocol. Your application must support the required authentication method. An authentication error therefore does not necessarily mean the password is wrong.

For a comparison of access methods and help choosing one, see Proxy Authentication. This article covers connecting with a username and password, from entering the settings to diagnosing problems in a working script.

What username–password authentication means

The username identifies an account or access to a particular service, while the password confirms your right to use it. Once the check succeeds, the proxy handles the connection within the granted permissions: the available address list, purchased allowance, and applicable limits.

Proxy credentials should not be confused with your dashboard password. The details used by an application may differ from those used to sign in to the provider's website. An API key is for requests to the service API, while a destination website's password is for signing in to that website. Use either as a proxy password only if the provider explicitly specifies that connection method.

Successful proxy authentication does not sign you in to the destination website. If the website requires its own account, cookies, or token, the application still needs to provide those separately.

When this method is useful

Username and password access can serve applications in several locations, whether those locations stay fixed or change. With no IP restriction, each application needs the credentials and proxy connection settings, without a separate allowlist entry for its network.

For example, a team works from two offices and home, each with a different public IP. The applications can use the same proxy credentials if the service permits those applications to share credentials without IP binding. Each application keeps its own connection settings; the proxy checks the credentials sent by each of them.

This method also works for several permanent servers. However, the number of devices, simultaneous connections, and available resources depends on the plan. A single password does not grant unlimited access.

How an application sends proxy credentials

The general sequence is simple: the application contacts the proxy, passes the access check, and uses it to reach the requested resource. The details depend on the protocol.

An HTTP proxy may first return 407 Proxy Authentication Required and indicate the authentication method it accepts. The application sends authentication information in the Proxy-Authorization header. Some clients send it immediately, so the initial challenge may not appear in the log.

When opening an HTTPS website through a regular HTTP proxy, authentication can take place during the CONNECT request that establishes a tunnel. The application then establishes a secure connection to the website. Further website requests through that established tunnel do not repeat the proxy login used to open it.

With SOCKS5, the username and password are checked at the beginning of the connection, before the request to connect to the destination. If the check fails, the application does not obtain the requested connection through the proxy. A native SOCKS5 authentication failure is not an HTTP 407 response.

Select the protocol and authentication method supported by the service. SOCKS4 has a user-ID field, but it does not define the SOCKS5 username–password exchange. Filling in that field cannot make a SOCKS4 client perform SOCKS5 password authentication.

Which settings to enter in your application

Start with the connection details for your particular service. If the application has separate fields, enter each value in its own field:

Some applications accept a single string in the format protocol://username:password@host:port. For example, in http://client01:River%[email protected]:8080, the username is client01, the password is River@2026, the host is proxy.example, and the port is 8080. The @ inside the password is represented as %40 so it is not confused with the separator before the host.

curl, for example, supports this interpretation of a proxy URL. A separate password field generally expects the password itself, without URL encoding. Do not copy an encoded value from a URL into a separate field without checking the format: the application may treat it as a different password. For strings containing %, colons, or other special characters, follow the client's own format requirements.

Encode the necessary characters within the credentials once; encoding the entire string would damage its separators. Quoting a command argument does not replace URL encoding. The authentication method can have restrictions of its own: HTTP Basic, for example, allows a colon in the password but not in the username.

Import formats also differ. host:port:username:password and username:password@host:port are not interchangeable. Correct values in the wrong order will not work if the importer expects a different arrangement.

The http:// prefix in a proxy URL describes how the client connects to the proxy itself. It does not prevent access to HTTPS websites: the client can establish a tunnel for them. Simply changing the prefix to https:// does not add secure proxy connection support to the server.

Some services include a country, exit group, or session parameter in the username. Copy the entire string. These parameters control routing according to the provider's rules; do not invent their syntax or borrow it from another service.

Why you should check authentication support in the application

Proxy support and proxy authentication support are separate capabilities. Fields for a host and port do not necessarily mean the client can send a username and password.

Check the exact combination of proxy protocol, authentication method, and application. For example, Chrome's built-in SOCKS5 implementation does not support SOCKS5 proxy authentication. Correct credentials alone cannot fix that limitation. An extension for selecting proxies does not necessarily add the missing authentication method either.

In scripts, support can depend on the library, its optional components, and how settings are supplied. An application does not necessarily use the system proxy settings or the settings of a browser where the connection already works.

Before starting a large task, test one request in the application that will run it. Confirm that the application uses the specified proxy and does not continue with a direct connection after a failure. A page loading successfully does not, by itself, confirm the settings are correct.

What happens when your IP changes

With an ADSL connection that uses a dynamic IP, the internet provider may assign a new address after a router restart or reconnection. If the proxy checks only a username and password, the application connects with the same credentials: there is no new IP to add in the dashboard. The same applies when moving from the office to a home network.

However, changing networks can interrupt existing connections. The client will need to reconnect, and an unfinished request may need to be retried. An error immediately after switching from Wi-Fi to mobile internet should not automatically be treated as a password problem.

Some services check both the credentials and the source address. A correct password does not override that network restriction: the new IP must match an allowed address or range. Before moving a script, establish whether the service accepts connections from any network or applies a combined check.

Is the password protected in transit?

Authentication determines who is allowed access. Encryption determines whether someone along the path can read the transmitted data. Having a password does not, by itself, make the connection encrypted.

HTTP Basic encodes the username and password in Base64. This is a reversible representation, not encryption. Without protection on the connection to the proxy, someone observing that network path can obtain the credentials. Standard SOCKS5 username–password authentication does not encrypt their transmission either.

HTTPS on the destination website protects the connection between the application and that website. With an HTTP proxy, authentication during tunnel setup happens earlier; the website's TLS does not protect the proxy credentials already sent. Similarly, an HTTPS request through SOCKS5 does not encrypt the preceding proxy password check.

Protecting that part of the path requires protection between the application and the proxy, such as an HTTPS proxy using TLS, when both the service and client support it. The application must validate the proxy's certificate. In some sales listings, “HTTPS proxy” means only that HTTPS websites can be reached, so check where TLS actually applies.

If a complete connection string with a valid password is exposed, someone else may be able to use the service within its rules, consuming the allowance or occupying connections. This is not equivalent to obtaining the dashboard password when the credentials are separate. The authentication method also does not guarantee that an address cannot be identified as a proxy: an externally accessible authentication challenge can reveal the service.

Can several applications use the same credentials?

Technically, several clients can send the same username and password. The provider determines whether this is allowed and sets the boundaries: sharing terms, active connection limits, purchased allowance, and any additional restrictions.

For example, two scripts may use one account while opening different numbers of connections. One password does not mean one connection. Equally, starting ten processes does not multiply the service's total connection allowance by ten.

The number of credential pairs is also different from the number of exit IPs. One username and password may grant access to a list of static proxies or a gateway backed by an address pool. The IP seen by the website depends on the selected proxy and the service's routing rules.

If the service offers separate credentials for applications or team members, one set can be disabled without changing the others. With a shared password, changing it requires updating every application that uses it. Separate credentials still do not imply separate connection or traffic allowances: check which limits they share.

Why a proxy rejects a username and password

First identify who returned the error. HTTP 407 concerns proxy authentication; 401 from the destination website concerns access to that website. A 403 message or a timeout does not, without further evidence, establish whether the proxy password is correct.

Check the service status and remaining allowance, then test one request with the supplied settings in the actual application. If it fails, use the table to check client support, credential format, and source-IP restrictions, changing one setting at a time. Once the request works consistently, increase the workload and watch for limits that appear only under load.

How to store and change credentials in working scripts

Keep credentials separate from the code, in access-controlled configuration or your environment's secret store. An application can receive them through environment variables, but those are not encryption in themselves. Keep active passwords out of repositories and templates you share with others.

A log generally needs the proxy host and port, the connection result, and the error code. A complete connection string contains the password; redact it before writing the log. With command-line tools, consider that a secret can remain in command history or be visible in process arguments, depending on the application and system.

Before changing a password, find every consumer: local applications, server processes, scheduled tasks, and build systems. After the change, update their settings and establish a new connection to test them. Confirm that long-running processes have also picked up the new value; some need to be restarted.

If the old password should no longer work, test that a new connection using it is rejected. Existing connections follow the service's own rules: changing a password does not always close them immediately. For urgent revocation, use the provider's supported method of disabling access.

Combined authentication: IP and password

With combined authentication, the proxy checks two conditions: the credentials and the address the application connects from. Both must pass. A correct password alone does not override the IP restriction.

For ProxyCompass static packages, the combined mode uses a /24 subnet. If you have several public IPv4 addresses in the same subnet, adding one of them to the allowlist is sufficient. The other addresses in that subnet can connect with the correct username and password, without a separate entry for each address.

In the illustration, the application’s public IP shares the first three numbers with the allowlisted address. It can connect with valid credentials; an address outside that subnet fails the network check, and a wrong password fails even inside it. Other client IPs in the same subnet can use this entry too. This is useful for applications that require username and password fields. The rule concerns your applications’ public IPs, not the purchased proxy exit IPs.