Skip to content
Authentication

HTTP proxy authentication and the 407 response

A 407 response means the client must authenticate to the proxy. It resembles 401 but belongs to a different participant and uses separate headers. Correctly distinguishing the two improves support and prevents proxy credentials from being treated as destination credentials.

2 min readReviewed and updated: August 6, 2026

Key points in one minute

  • 407 is produced by a proxy while 401 belongs to the destination.
  • Proxy-Authenticate carries the proxy's challenge.
  • Proxy-Authorization carries the client's response.
  • Credentials should go only to a trusted proxy over a protected channel.

The challenge-response model

A proxy that lacks acceptable credentials returns 407 with one or more schemes. The client selects a supported scheme and can repeat the request with Proxy-Authorization. Any repeat must still be safe for the original operation.

Basic is not encryption

Basic combines username and password and encodes them with Base64. That representation is reversible. HTTPS to the destination protects data inside a CONNECT tunnel, but does not by itself encrypt credentials on the client-to-plain-HTTP-proxy hop. Protect that hop with an HTTPS proxy, VPN, or another trusted secure channel. Proxy passwords should not be reused for other services.

Why 401 and 407 need separate labels

After proxy authentication succeeds, the destination can still request its own credentials with 401. A UI should identify the response source so the user does not change a valid proxy password when the application account is the actual issue.

Operational logging

Record time, proxy endpoint, scheme, status, and operation ID, but never the password or full authorization header. Repeated 407 responses can indicate bad credentials, an unsupported scheme, a wrong port, or a client that dropped the header.

Practical checklist

  1. 1Confirm that 407 came from the expected proxy.
  2. 2Check the supported authentication scheme.
  3. 3Never store Proxy-Authorization in logs.
  4. 4Distinguish proxy 407 from destination 401.
  5. 5Revoke a compromised password instead of hiding the issue.

Sources and documentation

This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.

  1. 1.RFC Editor / IETF: HTTP Semantics
  2. 2.RFC Editor / IETF: The Basic HTTP Authentication Scheme
  3. 3.MDN Web Docs / Mozilla: HTTP headers

Continue reading

More articles on related topics

Routing boundaries

Why some traffic can bypass a proxy: PAC, DIRECT, and WebRTC

Read

SOCKS5 access

Username and password in SOCKS5: how access is verified

Read

Access control

Password or allowed IP: choosing proxy access control

Read