Username–Password Authentication

Username–password authentication lets an application use a proxy by supplying valid proxy credentials. The proxy checks those credentials and the permissions attached to them before allowing the requested connection or request. An application can keep using the same credentials after changing networks, provided the service also permits access from the new location.

For a comparison with access based on a permitted source IP, see Proxy Authentication. This article explains how to enter proxy credentials, protect them, and manage access across applications and machines.

What proxy credentials let you do

The username and password issued for a proxy identify an account or access record within that service. They may differ from the email and password used to open its dashboard. A website you visit through the proxy has its own login requirements as well: being accepted by the proxy does not sign you into that website.

This method is useful when the application moves between home internet, mobile connections and a VPN, or when jobs run on several servers. With access controlled only by credentials, a new source IP does not need its own allowlist entry. For example, a home PC and a VPS can use the same purchased proxy set concurrently if the service permits that use and both clients support its authentication method.

Some home internet connections receive a new public IP when the router reconnects. The interruption ends active connections, but after internet access returns, the application can reconnect to the proxy with the same username and password. The same applies when you move from home to an office network, provided the proxy service does not also restrict source IPs.

Access still has boundaries. The credentials can belong to a particular package, have an expiry date, or be subject to source restrictions and connection limits. Distributing one password to more machines does not create extra capacity or override the service's sharing rules.

Credentials also do not determine whether the proxy's exit IP stays fixed. The same authentication method can be used with a static proxy list or a rotating service.

Where HTTP and SOCKS5 send the credentials

For ordinary HTTP forwarding, the client can supply credentials in the Proxy-Authorization header. With HTTP Basic, the username and password are represented using Base64. Other HTTP authentication methods exist, so the client must support the method requested by the proxy.

When an HTTP proxy carries an HTTPS connection through a CONNECT tunnel, authentication can happen while that tunnel is being established. After the tunnel opens, the website's encrypted requests travel inside it. They do not each need another proxy authentication header inside the tunnel. Opening a new tunnel may require authentication again.

SOCKS5 uses a different exchange. Client and proxy first select an authentication method; if they choose username/password, the client sends those values before making the SOCKS connection request. This is not an HTTP header exchange. SOCKS4's USERID field is not equivalent to a SOCKS5 username/password pair.

These differences matter when choosing software. A SOCKS5 address field does not prove that the application supports SOCKS5 password authentication. Chrome's built-in SOCKS5 support, for example, does not implement proxy authentication. The protocol and the authentication method must both be supported by the client you actually use.

A proxy's reply can also reveal what service is listening. An HTTP 407 Proxy Authentication Required response with Proxy-Authenticate gives an active external checker a recognizable proxy response, even if that checker has no valid password. This is about the endpoint's response to a connection attempt; it does not depend on a person manually typing credentials. Whether the service exposes that response depends on its access configuration.

Enter the address, username and password

When an application offers separate fields, use them. They make it easier to distinguish the endpoint from the credentials and avoid mistakes caused by packing everything into one string.

Some tools instead accept a proxy URL such as https://username:password@proxy.example:8443. The scheme describes the connection to the proxy, not the website being visited. A list exported as IP:PORT:USER:PASS is another input format; it is not automatically interchangeable with a URL.

Characters that have a structural meaning in a URL need suitable representation inside its username or password component. For a client that accepts percent-encoded credentials, the fictional password a@b:9/% can be represented as a%40b%3A9%2F%25:

https://proxy-user:a%40b%3A9%2F%25@proxy.example:8443

In a separate password field, enter the original a@b:9/%. Pasting the encoded version there can send a different password. Encode the credential component once, using the format the client expects; encoding the whole URL would also change its separators. Quotes around a shell argument solve a separate problem and do not perform URL encoding.

Protocol restrictions still apply. HTTP Basic permits a colon in the password but not in the username, because the first colon separates the two. Percent encoding cannot remove that restriction. Correct the representation before considering a password change merely to avoid special characters.

Test a connection with a password prompt

The following example is for an HTTPS proxy that accepts HTTP Basic authentication. Replace the proxy endpoint and username with your own. Both hostnames are examples; port 8443 is a placeholder, not a universal service port.

curl --proxy "https://proxy.example:8443" \
  --proxy-user "proxy-user" \
  --noproxy "" \
  --output /dev/null \
  --write-out "HTTP status: %{http_code}\n" \
  "https://example.com/"

Because no password follows the username, curl asks for it in the terminal without displaying the typed characters. Enter the actual password at that prompt. It is then absent from the command you entered and from the shell history entry for that command. --noproxy "" prevents a bypass list from making this particular test connect directly.

The command prints the destination's HTTP status and discards its response body. A successful expected response confirms this connection; an error or an unexpected status needs interpretation rather than an immediate full workload. Keep certificate verification enabled. An HTTP-only or SOCKS5 endpoint will not become an HTTPS proxy simply by changing the URL scheme.

The prompt and request flow were checked on Linux with Bash 5.2.21 and curl 8.5.0 on 26 September 2026, using a local HTTPS proxy and HTTPS test server. This verifies the example's behavior, not a commercial service. Unattended jobs need the application's supported secret input or protected configuration instead of an interactive prompt.

When a username also selects a route

Some services put country, session or exit-group parameters inside the username. The account portion identifies access, while the additional fields request particular routing behavior. The spelling and separators belong to that service; there is no universal username format for these options.

This can make an apparent password failure a parameter problem. A mistyped field, an unavailable location or a feature outside the purchased package may be rejected even when the password is correct. Begin with a minimal connection configuration that is valid for the package, then add the needed options individually. If the service requires those fields, retain them in the baseline.

A plain static proxy list may need no such parameters. Also, selecting a different exit or session does not by itself create an independent credential that can later be revoked separately. Treat routing controls and access records as different settings unless the service explicitly connects them.

Protect credentials in transit and in your files

Base64 does not encrypt a Basic password. SOCKS5's standard username/password exchange also sends the password without encryption of its own. Protection therefore needs a secure transport around that exchange, such as TLS to a supported HTTPS proxy endpoint or another appropriately secured connection to the proxy.

An HTTPS destination alone does not protect a password sent earlier to a plain HTTP or SOCKS5 proxy. The website's TLS session protects a different part of the exchange. For an HTTPS proxy, certificate verification is part of protecting the credentials: otherwise the client may send them to an impostor.

The saved connection details deserve the same attention. Knowing only the proxy address and port does not satisfy a password requirement. A leaked string containing a working username and password can let someone use the service within those credentials' permissions, unless another access restriction stops them. That can consume a request or traffic allowance, occupy available connections, or generate abuse complaints. It does not automatically grant access to your dashboard or payment details.

Keep secrets out of source code, shared screenshots and diagnostic output. Use the application's secret store or a configuration file whose access is restricted to the processes and people that need it. A secret copied into an environment variable is still a secret; environment dumps and job logs can expose it.

Avoid placing passwords directly in shell commands. Depending on the system and program, command arguments may be visible through process inspection as well as saved history. When sharing a connection example with support, remove the credential values and authentication headers from the URL, configuration and logs. If a real credential has escaped, revoke or replace it; deleting the visible message does not invalidate copies already taken.

Give applications separate access where possible

One shared credential is simple to distribute, but it makes withdrawal of access a group operation. If three applications use the same password and you revoke it to stop one application, all three lose the ability to authenticate with that password. The other two need updated credentials.

When a service offers separately revocable users or access records, assign them per application, operator or job group that you may need to disable independently. Revoking one record then leaves the others usable. Separate labels or different session strings are insufficient if they still depend on one shared secret that can only be revoked as a whole.

For a planned replacement, identify every job that uses the old secret, distribute the replacement securely, and test a new connection from each required environment. Where the service allows old and new credentials to overlap, migrate the clients before revoking the old record. Otherwise, arrange the update around the interruption that a shared password change can cause.

A confirmed leak calls for prompt revocation even if some jobs need to be restarted. The change may take time to apply, and existing authenticated tunnels may remain open under the service's connection policy. If existing access must end immediately, use a session termination control where available or have the provider close those sessions; a password change alone should not be assumed to do it.

Credentials can also be combined with source IP restrictions. Establish whether both checks are required or whether either one permits access. The answer determines what happens when an application moves to a new network or when a password is disclosed.

Find the cause of an authentication failure

Start with one connection from the environment that runs the job. Distinguish reaching the proxy, authenticating to it and receiving a reply from the destination. Repeatedly changing a password cannot fix a wrong endpoint or an unsupported authentication method.

If a previously working configuration stops, also check whether its access record was revoked, the package expired, or a usage or connection limit was reached. Providers do not all report these conditions in the same way. Once a small request works, increase the workload and observe whether failures appear only under load.

Username/password access is a practical fit for applications that change networks or run across several machines. Its value depends on supported authentication, safe secret handling and a manageable way to replace or withdraw access as the workload grows.