Prompt and applicable context
HTTP 511 means that a client must authenticate before gaining network access. It normally comes from an intercepting proxy or captive portal, not the target origin. A backend engineer must establish whether the request reached the origin instead of misdiagnosing an entry-network problem as an application-authentication failure.
What the interviewer evaluates
- Explaining that an intercepting proxy generates 511.
- Separating network authentication, origin authentication, and proxy authentication.
- Knowing that 511 responses must not be cached and should not disguise a login UI as the origin page.
- Designing safe handling for non-browser clients instead of blindly following redirects.
- Proving the failure location with proxy, DNS, TLS, and request logs.
Clarifying questions before answering
- Is the caller a browser, mobile app, or headless service client? Their ability to handle a portal differs.
- Does 511 come from an enterprise proxy, public Wi-Fi portal, or application gateway? The sender defines the boundary.
- Is the request HTTP or HTTPS? Intercepted TLS may fail with a certificate error first.
- Can the client open the login resource and retain the network session? If not, it can only ask the user to change networks.
- Are we diagnosing an intermittent proxy fault or integrating a captive portal? Integration needs a session protocol too.
30-second answer framework
“511 is network-entry authentication, not an origin user login. RFC 6585 recommends that an intercepting proxy generate it, provide a login-resource link, and avoid caching the response. I record the final response IP, proxy markers, and TLS state to verify whether the origin saw the request; a browser can guide the user to the portal, while a service client must not treat 511 as 401 or submit business credentials to an unknown intermediary. Then I distinguish 401 origin authentication from 407 proxy authentication and choose a network, proxy, or client fix.”
Step-by-step deep dive
Step 1: Locate the response producer. Compare the target DNS address, TCP peer, Via or proxy headers, origin access logs, and gateway trace. If the origin has no matching request, an intermediary likely produced 511.
Step 2: Interpret the protocol semantics. 511 tells the client that the network is not yet open. The representation may link to credentials or terms, but it should not present the portal form as content from the originally requested origin.
Step 3: Separate neighboring codes. 401 is an origin asking for resource authentication and commonly uses WWW-Authenticate; 407 is a forward proxy asking for proxy credentials and uses Proxy-Authenticate; 511 concerns access to the network itself.
Step 4: Define client behavior. A browser can show a network-login prompt. An API client should report a clear network-unavailable state, record the portal URL, and wait for the user or network administrator. It must not silently submit business credentials to an unknown intermediary.
Step 5: Handle HTTPS and caching. Intercepting HTTPS can produce a certificate mismatch; disabling certificate verification is not a fix. A 511 response must not be cached, or a temporary network gate can leak to clients that already authenticated.
Step 6: Build diagnostic evidence. On the same network, compare an HTTP probe with the business request and record time, proxy, DNS, certificate chain, status, and origin logs. Microsoft Learn also lists 511 as a possible result in proxy connectivity checks.
Step 7: State alternatives and boundaries. Enterprise APIs should fix proxy allowlists, service-account egress, or network authentication rather than implement a 511 login inside the business API. Public networks need a user-completable portal flow and a timeout message.
Model answer
“I first classify 511 as a network-entry response: an intercepting proxy says the client must authenticate the network, and the origin usually never saw the request. It differs from 401 resource authentication and 407 proxy-credential authentication. I compare DNS, TCP peer, proxy headers, TLS certificate, origin logs, and traces to find the producer. A browser can open the portal link; a headless API client must not retry it as 401 or send business credentials to an unknown proxy. The response must not be cached, and a certificate error caused by HTTPS interception cannot be solved by skipping verification.”
Common mistakes
- Treating 511 as 401 → refreshing an origin token cannot make the request leave the network → find the response producer first.
- Treating 511 as 407 → configuring proxy credentials while ignoring a portal session → separate network entry from forward-proxy authentication.
- Following an unknown login link automatically → credentials may leak to a phishing portal → show provenance and let the user confirm.
- Caching 511 → authenticated clients keep seeing an old gate → prohibit caching and inspect intermediaries.
- Disabling TLS verification → the man-in-the-middle risk increases → repair network authentication or trust configuration.
Follow-up questions and responses
Follow-up 1: The origin has no request, but the client gets 511. What next?
Capture the connection peer, proxy chain, and response headers, then query a known HTTP probe on the same network. If several destinations show the same response, inspect the egress proxy or captive portal.
Follow-up 2: Why not return the portal HTML as API JSON?
Non-browser clients may parse HTML as a business response and fail; worse, they may mistake portal content for origin content. Use an explicit error class and a verifiable login entry point.
Follow-up 3: Why do HTTPS requests often show a certificate error instead of 511?
When an intermediary cannot safely replace the origin TLS certificate, the handshake fails before an HTTP status exists. Clients cannot assume every network gate can be expressed as 511.
Follow-up 4: Can a client retry after receiving 511?
Retry the original request only after network authentication and session establishment are confirmed. Blind retries amplify traffic, and business writes must not be replayed automatically.
Follow-up 5: How do you distinguish a proxy false positive from a real portal?
Compare networks, domains, proxy settings, origin logs, and portal sessions. If only one enterprise egress path returns 511, inspect its policy and allowlist first.
Follow-up 6: What if a mobile app has no browser login UI?
Return a readable network-unavailable state and direct the user to the system network-login page or another network. Reconnect after authentication; do not silently submit unknown network credentials in an embedded page.
Follow-up 7: Why must 511 not be cached?
Network authentication is temporary and client-specific. Caching can make another client see the same gate and can keep an already-authorized user blocked.