curl Proxy Authentication: Syntax, Examples, and 407 Fixes
Updated October 20, 2026
curl Proxy Authentication: Syntax, Examples, and 407 Fixes
For connections through IP9's residential and mobile proxies, the endpoint, port, and credential format should match the provider's setup instructions. The commands here use placeholders, not provider-specific connection settings.
Configure curl proxy authentication
The basic command keeps the proxy address, proxy credentials, and destination URL separate:
curl --proxy 'http://PROXY_HOST:PROXY_PORT' \
--proxy-user 'PROXY_USERNAME:PROXY_PASSWORD' \
'https://example.com/'Each uppercase value represents a setting that must be replaced before execution. These examples use POSIX-style shell quoting and line continuation. A username containing provider-specific routing parameters must follow the provider's documented format; additional parameters shouldn't be guessed.
The shorter equivalent of --proxy-user is -U.
For interactive use, supplying only the username lets curl prompt for the proxy password:
curl --proxy 'http://PROXY_HOST:PROXY_PORT' \
--proxy-user 'PROXY_USERNAME' \
'https://example.com/'A failure before any HTTP response needs connection-stage diagnosis rather than password changes. The residential proxy timeout guide helps separate name resolution, connection, and later-stage failures.
Separate proxy credentials from server credentials
The distinction behind curl proxy vs server authentication is which system receives the credentials. For an HTTP proxy, curl proxy authentication uses the Proxy-Authorization header; destination authentication uses Authorization. Passing proxy credentials through --user targets the wrong authentication flow.
| Purpose | curl option | Behavior |
|---|---|---|
| Proxy Basic authentication | --proxy-basic | Explicitly selects Basic, the default HTTP proxy authentication method. |
| Proxy method negotiation | --proxy-anyauth | Uses a proxy challenge to select an available supported method; may require an extra exchange. |
| Destination-server authentication | --user | Supplies credentials for the destination, not the proxy. |
When both systems require credentials, their options remain separate:
curl --proxy 'http://PROXY_HOST:PROXY_PORT' \
--proxy-user 'PROXY_USERNAME:PROXY_PASSWORD' \
--user 'SERVER_USERNAME:SERVER_PASSWORD' \
'https://example.com/'HTTP 407 is a proxy authentication challenge. HTTP 401 is a destination-server authentication challenge.
Once authentication succeeds, response speed becomes a separate diagnostic question. The residential proxy performance guide provides a framework for evaluating successful requests rather than treating a successful login as proof of acceptable performance.
Protect credentials and distinguish HTTPS connections
Authentication isn't encryption.
With --proxy 'http://...', the connection to the proxy isn't protected by TLS. An HTTPS destination normally uses a CONNECT tunnel followed by TLS to the destination, but that destination TLS doesn't protect the preceding proxy authentication exchange. Basic credentials are encoded, not encrypted.
An https:// proxy URL requests TLS between curl and the proxy, provided both the endpoint and curl build support it. This is separate from whether the destination URL uses HTTPS. Certificate verification should remain enabled; disabling it isn't a credential fix.
Credential exposure can also happen locally:
- Shell history: a command containing a literal password may be saved.
- Process arguments: expanded credentials may be visible to local inspection tools, depending on operating-system permissions. Shell variables don't inherently prevent this.
- Diagnostic logs: verbose output and traces may expose usernames, headers, URLs, or other sensitive data. Redaction is required before sharing.
Interactive prompting avoids putting the password directly in the command line. For unattended execution, a restricted-access configuration file or an approved secret-handling workflow can reduce exposure, but stored credentials still need access controls.
Before adapting these single-request examples into automation, the proposed workflow must be checked against the full Acceptable Use Policy, including its permitted-use, prohibited-use, and responsible-automation requirements.
Fix curl proxy authentication failures
A useful curl proxy authentication checklist begins with the actual response, not repeated password changes. A challenge can be part of negotiation, so the final outcome matters more than an isolated 407 in diagnostic output.
Check the endpoint and credential parsing
- Confirm the proxy scheme, hostname, and port against the connection settings.
- Check that
--proxy-user, rather than--user, contains the proxy credentials. - Look for copied whitespace, expired credentials, or shell-expanded characters. POSIX single quotes preserve most literal characters, but an embedded single quote needs separate escaping.
- Keep credentials out of the proxy URL to avoid unnecessary URL-encoding ambiguity.
Inspect the challenge and supported method
A Proxy-Authenticate response header advertises authentication methods. If the proxy requires negotiation, a controlled test can use:
curl --proxy 'http://PROXY_HOST:PROXY_PORT' \
--proxy-user 'PROXY_USERNAME' \
--proxy-anyauth \
'https://example.com/'The option doesn't repair invalid credentials or add authentication methods missing from the installed curl build. A curl 407 error during CONNECT also occurs before the destination TLS session begins.
Separate recurring disconnects from rejected credentials
If authentication succeeds and the connection later drops, the mobile proxy disconnection guide helps isolate recurring failures without assuming every interruption requires a new password.
FAQ
Does curl proxy authentication require credentials in the URL?
No. Separate --proxy and --proxy-user options make parsing clearer and keep endpoint configuration distinct from credentials.
Why can a correct password still produce HTTP 407?
The username format, endpoint, authentication method, or shell parsing may be wrong. The proxy's challenge and provider settings should guide the next check.
Does an HTTPS destination protect the proxy password?
Not necessarily. Destination TLS and proxy-connection TLS protect different connection segments.
Reliable curl proxy authentication starts with the correct endpoint, credential option, and supported method. The essential caveat remains: authenticating to a proxy doesn't encrypt the connection, and an HTTPS destination alone doesn't protect credentials sent to an HTTP proxy.