HTTP 407 vs 401: Which Login Is Failing?
Distinguish proxy authentication from website authentication, inspect the right headers, and avoid sending credentials to the wrong hop.
A 407 asks you to authenticate to the proxy. A 401 asks you to authenticate to the target resource. A request can encounter both, so find out who is asking before supplying a password.
Compare the status and challenge headers
| Response | Challenge header | Credential header | Party involved |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | An intermediary proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | The origin resource's authentication flow |
The status is an essential first clue, but inspect the whole exchange. A page displaying the number 407 in its text is not equivalent to an actual HTTP 407 response. Likewise, a custom web login page can return status 200 and still require a user to authenticate at the application layer.
Why HTTPS requests can fail with 407 before reaching the website
When an ordinary HTTP proxy carries an HTTPS request, the client commonly asks it to establish a CONNECT tunnel first. The proxy can challenge that CONNECT request. If authentication is not completed, the destination's TLS session has not yet been established through the tunnel, so changing a website API token is unlikely to repair that stage.
Use a verbose request to see where the challenge appears:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Replace the local listener with yours and read the first challenge in the log. A 407 during CONNECT comes before destination TLS; a later 401 can follow a successfully established tunnel.
Provide proxy credentials through the proxy interface
For an endpoint and account supplied by an administrator you trust, curl can negotiate the proxy authentication scheme and prompt for a missing password:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Replace the example endpoint and username with your authorized service details. Specifying only a username avoids placing the password directly in the command shown above. Authentication methods supported by a particular curl build and proxy can vary; check the actual challenge and build capabilities when negotiation fails.
The proxy authentication option is separate from curl's origin-user authentication option. Do not add an origin Authorization header as a substitute for a proxy challenge. Also avoid manually forwarding proxy credential headers to unrelated requests or saving them in reusable application-wide headers.
If the proxy keeps returning 407
- Confirm that you are using the intended proxy host and port.
- Check the proxy's advertised authentication schemes rather than assuming Basic authentication.
- Confirm account status and whether the service expects a specific username format.
- Check how special characters are passed if credentials are embedded in a URL.
- Determine whether a browser-integrated enterprise authentication setup needs runtime or platform support.
- Ask the administrator for a sanitized request identifier or server log entry when the client-side evidence is insufficient.
A 403 or denied CONNECT can be an access-policy decision even after login succeeded. More password retries will not grant access to a forbidden destination.
The destination's HTTPS does not protect every proxy credential exchange
Proxy authentication can occur before destination TLS is established. If the connection to the proxy itself is cleartext and the method exposes reusable credentials on that link, an HTTPS target does not retroactively protect that exchange. Select a transport and authentication arrangement suitable for the service, and do not send private accounts to an unknown public proxy.
Review verbose logs before sharing them. Even when a tool masks common credential fields, logs can still contain usernames, internal endpoint names, cookies, or other identifying data.