Reference guide · http-status · Published 2026-08-16 · 4 min read
HTTP 511 Network Authentication Required explained
HTTP 511 Network Authentication Required explained: who returns it, how captive portals work, and how clients should respond.
- ·What 511 means
- ·How to handle it as a client
- ·511 vs other codes
What the 511 status code means
HTTP 511 Network Authentication Required means the client must authenticate before it is allowed to use the network at all. It is not an application error and the shown service is not at fault. The response is generated by an intercepting proxy, not the origin server, so a browser or script does not receive the page it asked for.
The most common location you meet 511 is a captive portal, for example the login or terms-of-service page on hotel, airport and coffee-shop Wi-Fi. Internet providers use tag-based access control and identify a device by its Media Access Control (MAC) address; until the device has logged in, the network blocks nearly all traffic and the gatekeeper returns 511.
The status is described in RFC 6585 along with 508 and 509, and it appeared in later HTTP registries. Browsers usually render the 511 body directly, and the operator places a META refresh or a link in that body pointing at the login server. Non-browser clients do not follow that automatically, so they must detect 511 and act on it.
How a captive portal returns it
A typical flow:
- The device connects to the Wi-Fi and requests any HTTP page.
- The captive portal intercepts the request before it leaves the network and answers with
511 Network Authentication Required. - The response body is a small HTML page with a link or a
METArefresh to the portal login URL. - The visitor completes the login or accepts the terms on the portal.
- The device is then allowed out to the network and can retry the original request.
HTTP/1.1 511 Network Authentication Required
Content-Type: text/html
<html>
<head>
<meta http-equiv="refresh" content="0; url=https://login.example.net/">
</head>
<body>
<p>You need to <a href="https://login.example.net/">authenticate with
the local network</a> to get online.</p>
</body>
</html>The redirect target is not the origin you requested, so do not treat the 511 URL as the real site.
How to handle it as a client
A native application, scraper or mobile app should treat 511 as a distinct condition:
- Detect it separately from 5xx. A 511 does not mean the server is broken, so rate-limiting retries as if the network is down hides the real cause.
- Parse the body for the login URL. Read the
METArefresh or the first link and surface it to the user, or open it so the portal can be completed. - Retry only after access is granted. Reattempting while the portal is still locked repeats the same 511; wait until the user confirms the login.
- Do not cache the response. RFC 6585 says a 511 response must not be stored by any cache, because caching the portal page for the requested URL would confuse later requests.
| Code | Who returns it | What it asks for |
|---|---|---|
| 401 Unauthorized | The origin server | Credentials for the resource |
| 403 Forbidden | The origin server | Access denied even with credentials |
| 407 Proxy Authentication Required | A proxy in the path | Credentials for the proxy |
| 511 Network Authentication Required | An intercepting network proxy | Network access itself |
Why your site does not control it
Origin servers should not produce 511, and a 511 on the visitor's screen is almost never something you can change in the site's own code. If users report it, the fix belongs to the network operator or, for a public Wi-Fi network, to the hotel or venue. On a secure connection the captive portal can cause a certificate error because the TLS handshake is also intercepted, which is why many portals keep the login on an ordinary HTTP page.
The related HTTP errors in your site's own logs are a different matter, and a status family breakdown helps you tell a network problem from an origin problem.