Backend interview: How do you handle HTTP 407 across a proxy chain?

Prompt and scope

A service client reaches an external API through several explicit proxies. Some requests return 407 and others 401. Explain the boundary between them, hop-by-hop proxy challenges, CONNECT tunnels, credential storage, retries, and observability.

This is a backend networking and security question. Proxy count and failure rate are assumptions for the exercise, not market claims.

What the interviewer is testing

• Whether you separate resource-server authentication from next-hop proxy authentication.
• Whether you explain where Proxy-Authenticate and Proxy-Authorization are consumed.
• Whether you handle multiple hops, CONNECT, connection pools, and credential rotation.
• Whether proxy credentials stay away from the origin and logs.

Clarifying questions to ask

1. Is the client using an explicit or transparent proxy, and is CONNECT involved?
2. Which scheme does each proxy use, and are connections reused?
3. Can the client and gateways preserve the original 401 and 407 headers?
4. Is the request a safe read or does it create, charge, or mutate state?
5. Who rotates credentials, and is a backup egress available?

A 30-second answer

“A 407 is a challenge from the next-hop proxy; a 401 is from the target resource. I record hop and request identifiers, read Proxy-Authenticate, and send the matching Proxy-Authorization only to that proxy. The next inbound proxy consumes it; it must not reach the origin. For CONNECT, authenticate the proxy before creating the tunnel, then handle a tunnel-level 401 as origin authentication. I retry only replay-safe requests and measure 407 by proxy, scheme, and credential version.”

Step-by-step design

1. Separate 401 and 407

WWW-Authenticate in a 401 describes a target-resource challenge, usually answered with Authorization. Proxy-Authenticate in a 407 describes a challenge from the next-hop proxy, answered with Proxy-Authorization. Similar status numbers do not justify shared caches or one error handler.

2. Authenticate one hop at a time

Each proxy receives only the credentials it requested. RFC 9110 defines Proxy-Authorization for the next inbound proxy that demanded it; in a chain, the first proxy expecting credentials consumes the field. The client isolates credentials by proxy or connection and never forwards the proxy header to the origin.

GET https://api.example/report HTTP/1.1
Host: api.example
Proxy-Authorization: Basic <proxy-credential>

3. Handle CONNECT tunnels

For an HTTPS target, the client sends CONNECT to the proxy first. After proxy authentication succeeds and the proxy returns 2xx, the client creates the TLS tunnel. Requests inside it belong to the origin; an origin 401 uses Authorization and is not mistaken for proxy 407. A failed proxy challenge still belongs to the CONNECT hop.

4. Isolate pools and credentials

The pool key includes proxy address, authentication scheme, tenant, and credential version. During rotation, stop reusing old connections or reauthenticate as required by the proxy. Do not put Proxy-Authorization in a cross-request header template or record its value in tracing systems.

5. Bound retries and side effects

After 407, retry only when no irreversible body was sent or the operation is safely replayable. For POST, charging, or resource creation, use a business idempotency key and check whether the server already processed the attempt. Challenge handling, credential refresh, and replay should be observable events, not an unbounded loop.

6. Instrument diagnosis and safety

For each hop record proxy identity, CONNECT phase, scheme, credential version, 407 count, retry result, and final status; keep only redacted summaries. Compare 401, 407, TLS failures, pool reuse, and backup-egress switches to locate target, proxy-policy, or rotation faults. Inject failures to prove an intermediary cannot leak or rewrite the origin authorization header.

Model high-quality answer

“I split the path into proxy and resource layers. The next proxy challenges with 407 and the origin challenges with 401, using Proxy-Authorization and Authorization respectively. Credentials are isolated by proxy identity; the first inbound proxy expecting the proxy field consumes it, and it never reaches the origin. HTTPS authenticates the proxy during CONNECT before tunnel traffic. Pools are separated by proxy and credential version, and rotation retires old connections. Only safe requests are replayed after 407; side effects recover with idempotency and status queries. Hop-level metrics identify the fault.”

Common mistakes

• Treating 407 as 401 → credentials cross the wrong boundary → handle proxy and resource challenges separately.
• Forwarding proxy credentials to the origin → secrets leak → let the next inbound proxy consume and remove them.
• Sending tunnel traffic before CONNECT succeeds → protocol state is wrong → finish proxy auth and receive 2xx CONNECT first.
• Sharing all connection auth state → tenants or credential versions mix → isolate by proxy, tenant, and version.
• Retrying 407 forever → faults and side effects amplify → bound attempts, test replay safety, and query state.

Follow-up questions and responses

Can I send several Proxy-Authorization values for several proxies?

Do not treat the field as a generic credential list. Send what the current inbound proxy expects; after it consumes the field, handle a later challenge according to that hop’s scheme and verify that the implementation permits safe forwarding.

Why not diagnose from the final 407 alone?

Gateways can rewrite or swallow intermediate responses, and connection reuse can attach a challenge to the wrong request. Preserve hop logs, connection identifiers, and the original challenge to identify the actual issuer.

What if proxy authentication succeeds but the tunnel returns 401?

Keep the proxy authentication state and answer the origin’s WWW-Authenticate challenge with Authorization. Do not resubmit proxy credentials or place resource credentials in the proxy-auth cache.