Network Authentication Required
ActiveHTTP 511 Network Authentication Required indicates the client needs to authenticate to gain network access. Defined in RFC 6585 §6. Returned by captive portals (hotel WiFi, airports, coffee shops) — not by origin servers. The response must contain a link to the network login page.
Description
The 511 Network Authentication Required status code indicates that the client needs to authenticate to gain network access. This is NOT about authenticating with the origin server (that would be 401 Unauthorized) — this is about the network itself requiring login before it will forward traffic to the open internet.
Captive portals — the login pages you encounter on hotel WiFi, airport networks, corporate guest networks, and coffee shop hotspots — intercept HTTP requests and return 511 to signal the browser's built-in captive portal detection mechanism. The response SHOULD contain a link to the resource that allows the user to submit credentials to gain network access. That link MUST NOT appear to be from the origin server, because the captive portal has no authority over the requested domain.
This status code is fundamentally different from both 401 (origin server authentication) and 407 (proxy authentication). 401 means 'identify yourself to me, the server you asked for.' 407 means 'identify yourself to the proxy sitting between us.' 511 means 'you haven't logged into the network itself yet — none of your traffic is going anywhere until you do.'
The 511 response MUST NOT be returned by origin servers — it is exclusively for captive network portals that intercept traffic. Modern browsers have dedicated captive portal detection systems that look for 511 responses (among other signals like probing known URLs) and trigger a special captive portal login flow separate from normal browsing.
Because the 511 response is generated by an intercepting network device rather than the actual destination server, it creates cache poisoning risks. The response MUST NOT be cached, and intermediaries must be careful not to store it as if it were the legitimate response from the origin. The response body typically contains an HTML page with a login form or a redirect to the portal's login URL.
Examples
GET /api/data HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer user-token-abcHTTP/1.1 511 Network Authentication Required
Content-Type: text/html
Cache-Control: no-store
Connection: close
<html>
<head><title>Network Login Required</title></head>
<body>
<h1>Welcome to Airport WiFi</h1>
<p>You must log in to access the internet.</p>
<a href="https://portal.airportwifi.example/login?redirect=http%3A%2F%2Fapi.example.com%2Fapi%2Fdata">Click here to log in</a>
</body>
</html>HTTP/1.1 511 Network Authentication Required
Content-Type: text/html
Cache-Control: no-store
Location: https://portal.hotel-network.example/authenticate
<html>
<body>
<p>Network authentication required. If not redirected automatically,
<a href="https://portal.hotel-network.example/authenticate">click here</a>.</p>
</body>
</html>GET /hotspot-detect.html HTTP/1.1
Host: captive.apple.com
Connection: closeHTTP/1.1 511 Network Authentication Required
Content-Type: text/html
Cache-Control: no-store
<html>
<head><meta http-equiv="refresh" content="0;url=https://guestnet.corp.example/portal"></head>
<body>
<p>Please <a href="https://guestnet.corp.example/portal">authenticate</a> to access the network.</p>
</body>
</html>$ curl -v http://example.com/
* Connected to example.com (93.184.216.34) port 80
> GET / HTTP/1.1
> Host: example.com
>
< HTTP/1.1 511 Network Authentication Required
< Content-Type: text/html
< Cache-Control: no-store
<
<html><body><p>Please log in at <a href="https://wifi.coffeeshop.example/login">https://wifi.coffeeshop.example/login</a></p></body></html>Edge Cases
- •511 MUST NOT be returned by origin servers — only captive network portals that intercept traffic. If an origin server returns 511, it is violating the spec and clients may behave unpredictably.
- •The response MUST NOT be cached. Because it comes from an intercepting device, caching it would poison the cache with content that doesn't belong to the origin server.
- •HTTPS requests cannot be properly intercepted with a 511 — the portal can't forge a valid TLS certificate for the destination. Captive portals typically block HTTPS and only intercept plain HTTP, or they redirect DNS queries to the portal.
- •The response body MUST include a way to reach the login page — either an HTML link, a meta refresh redirect, or both. A bare 511 with no body is non-compliant.
- •Browsers have built-in captive portal detection (Apple probes captive.apple.com, Android probes connectivitycheck.gstatic.com, Windows probes msftconnecttest.com). These probes use HTTP, not HTTPS, specifically to be interceptable.
- •APIs and non-browser clients won't trigger captive portal flows — they'll just see the 511 and may confuse it with a server error. Client libraries should detect 511 and surface it distinctly from 5xx server errors.
- •Some broken captive portals return 302 redirects or even 200 with injected HTML instead of the proper 511. The 511 code was created specifically to replace these ambiguous behaviors.
When You'll See This
- →Connecting to hotel WiFi — device auto-detects captive portal and shows login sheet
- →Airport free WiFi requiring email registration before granting internet access
- →Corporate guest network requiring sponsor approval before connectivity
- →Coffee shop WiFi with terms-of-service acceptance page
- →Conference venue WiFi with access code entry
- →Mobile hotspot provider requiring plan activation or payment
- →University campus network requiring student credentials for guest devices
Implementation References
| Language | Constant |
|---|---|
| Go | http.StatusNetworkAuthenticationRequired |
| Rust | http::StatusCode::NETWORK_AUTHENTICATION_REQUIRED |
| Python | http.HTTPStatus.NETWORK_AUTHENTICATION_REQUIRED |
| Node.js | http.STATUS_CODES[511] |
| .NET | HttpStatusCode.NetworkAuthenticationRequired |
| Java | 511 (no built-in constant; use raw int) |
| PHP | Response::HTTP_NETWORK_AUTHENTICATION_REQUIRED (Symfony) |
| Ruby | :network_authentication_required (Rack) |
History
Introduced in RFC 6585 (April 2012) alongside 428, 429, and 431 as part of a batch of 'Additional HTTP Status Codes' to address common situations that lacked dedicated status codes. Before 511 existed, captive portals used various ad-hoc techniques: 302 redirects to login pages (confusing for non-browsers), 200 responses with injected HTML (cache poisoning risk), or simply blocking traffic silently. The IETF recognized that a dedicated status code would allow browsers to implement proper captive portal detection UX — showing a login sheet rather than a confusing error page. Modern operating systems now have dedicated captive portal detection systems that probe known URLs and look for 511 (or unexpected responses) to trigger the portal login flow automatically.
Related Status Codes
Related Headers
FAQ
What is the difference between 511 Network Authentication Required and 401 Unauthorized?
401 means the origin server (the server you actually requested) requires you to authenticate — provide credentials, an API key, or a bearer token. 511 means the network between you and the server requires authentication before it will let your traffic through at all. You'll encounter 511 on captive portals (hotel WiFi, airport networks) where the network itself demands login before forwarding any requests to the internet. The key distinction: 401 is 'the destination wants your credentials', 511 is 'the road itself is gated.'
Why can't captive portals intercept HTTPS traffic with a 511 response?
HTTPS establishes an encrypted TLS connection directly between the client and the origin server. The captive portal cannot forge a valid TLS certificate for arbitrary domains (that would require a compromised Certificate Authority or the client trusting the portal's CA). So the portal cannot inject a 511 response into an HTTPS stream without causing a certificate error. This is why captive portals work by intercepting plain HTTP requests, redirecting DNS, or blocking all traffic until the user authenticates through the portal's own HTTPS login page. Browsers handle this by using HTTP (not HTTPS) probe URLs specifically designed to be interceptable.
How do browsers detect captive portals automatically?
Each major platform probes a known HTTP URL on network connection: Apple checks captive.apple.com/hotspot-detect.html, Android checks connectivitycheck.gstatic.com/generate_204, Windows checks msftconnecttest.com/connecttest.txt, and Firefox checks detectportal.firefox.com. These probes expect a specific response (a 200 with known content, or a 204). If the response is instead a 511 (or any unexpected response like a redirect or different content), the OS/browser knows a captive portal is present and opens a special login sheet. This avoids the user seeing a confusing error page — the system presents the portal login UI directly.