Does 511 come from the website I'm trying to reach?

No, and that's the whole point of the code. 511 Network Authentication Required is defined by RFC 6585 §6 to be generated by the network you're connected to — an intercepting proxy or captive portal — not by the origin server you actually asked for. When you open a laptop on hotel or airport Wi-Fi and every request bounces to a sign-in page, the network is holding your traffic hostage until you accept the terms or pay. The origin never sees your request. Before 511 existed, portals faked this by returning `200 OK` with a login page pasted over whatever you requested, which meant a cache might store that login page as if it were the real resource, and a non-browser client (a package manager, a phone app polling an API) would get HTML it couldn't parse and fail in confusing ways. 511 is the machine-readable version of 'you are behind a gate you have to pass first.' The RFC explicitly says origin servers SHOULD NOT generate it.

How is 511 different from 401 and 407?

All three say 'authenticate,' but to three different things, and confusing them sends you to the wrong fix. 401 Unauthorized means the origin resource wants credentials — it comes with a `WWW-Authenticate` header and you answer with `Authorization`. 407 Proxy Authentication Required means a proxy you deliberately configured wants credentials — `Proxy-Authenticate` / `Proxy-Authorization`, a hop you set up yourself. 511 means the network you're attached to is gating access before your traffic reaches anything — a captive portal or transparent proxy you did not configure and probably didn't choose. 401 and 407 are about a specific resource or a known proxy; 511 is about the road, not the destination. If you see 511, no amount of fixing the site or your app credentials helps — you have to satisfy the network's login first.

Why did my phone or OS pop a 'Sign in to network' screen on its own?

Because operating systems probe for captive portals on every new network, and the probe is what tripped. Apple devices fetch `captive.apple.com` expecting a tiny fixed 'Success' page; Android and ChromeOS hit `connectivitycheck.gstatic.com/generate_204` expecting an empty HTTP 204; Windows requests `www.msftconnecttest.com/connecttest.txt`; Firefox uses `detectportal.firefox.com/success.txt`. When a captive portal intercepts one of those and returns anything other than the expected response — a redirect, a login page, or a proper 511 — the OS concludes 'there's a gate here' and pops the sign-in sheet so you can get through. That sheet is a stripped-down browser pointed at the portal's login URL. Note that some clients still don't handle a literal 511 cleanly and detect the portal only via the redirect or the wrong-body heuristic (Firefox tracked this as bug 1808975), which is one reason portals usually 302 you to a login page instead of returning 511 by the book.

Views: 37

511 Network Authentication Required: Captive Portals

511 Network Authentication Required means a captive portal, not the site, is blocking you. Isolate it in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Every site you open redirects to the same “Accept the terms” or “Sign in to continue” page, or a non-browser client — apt, git, a mobile app — hangs or fails with garbage it can’t parse. Somewhere a response carries 511 Network Authentication Required. The site you asked for never answered. The network you’re sitting on answered for it.

Symptoms

You just joined hotel, airport, café, or conference Wi-Fi, and the first request of any kind gets diverted to a portal.
A command-line tool or app fails oddly — it received an HTML login page where it expected JSON, an image, or a 204.
The browser shows a “Sign in to network” sheet, or a page that isn’t the one you typed.
The same URL works fine from your phone on cellular, or from any network without a portal.
Rarely: an API or origin you control is itself emitting 511, and clients are treating it as an auth failure.

What This Error Actually Means

511 Network Authentication Required (RFC 6585 §6) says the client must authenticate to gain network access — not to the resource, to the network. It’s designed to be generated by an intercepting proxy — the captive portal on the Wi-Fi you just joined — and the RFC is explicit that origin servers SHOULD NOT generate it. The request you made never reached its destination; something on the path answered in its place and told you to log in first.

The code exists to fix a specific mess. Captive portals used to intercept your request and return 200 OK with a login page substituted for the content. That’s a lie at the protocol level, and it had two nasty consequences. A cache in the path could store that login page under the URL of the real resource, so you’d keep getting the login page even after authenticating. And any client that wasn’t a human staring at a browser — a package manager, an app syncing in the background, a monitoring check — would receive HTML it never asked for and fail in ways that pointed nowhere near the actual cause. 511 replaces the lie with an honest, machine-readable signal: you are behind a network gate, go through it first. For the same reason, RFC 6585 requires that responses with 511 MUST NOT be stored by a cache.

The thing to internalize: 511 is almost never about the website in the address bar. It’s about the road between you and that website. Which is exactly why the fix is never on the site’s side and rarely in your application — it’s the network asking you to pay the toll.

Top 3 Causes

You’re behind a captive portal and haven’t authenticated. Hotel, airport, café, train, or conference Wi-Fi that requires you to accept terms, enter a room number, or watch an ad before it forwards your traffic. This is the overwhelming majority of real 511s. Until you complete the portal’s login, every request — including your OS’s silent captive-portal probes to captive.apple.com, connectivitycheck.gstatic.com/generate_204, and friends — gets intercepted.
A transparent or corporate proxy is gating access. On some managed networks a proxy sits inline and requires authentication to the network layer before letting traffic out. Unlike a proxy you configured yourself (which would return 407), this one you didn’t choose, so it speaks 511. Common on guest VLANs, education networks, and locked-down corporate segments.
An origin is misusing 511 as if it were 401. Rare, but it happens: a framework lets a developer return any status code, someone reaches for “authentication required” and grabs 511 instead of 401, and now legitimate clients behind no portal at all are getting a network-gate signal from a plain application endpoint. The RFC says origins SHOULD NOT do this precisely because it breaks captive-portal detection everywhere downstream.

Diagnose with DechoNet

HTTP Check fetches the URL from our servers, which are not behind your captive portal. If the site returns a normal 200 (or its real status) from us but your browser gets diverted to a login page, the gate is your local network, not the destination — stop debugging the site and go find the portal login.
The same check shows the actual status code and headers the origin sends. If our fetch also comes back 511, that’s the rare case where the origin itself is emitting the code — a real misconfiguration to fix at the server, not a portal to log into.
Run it against a couple of unrelated hostnames. If every external site returns normally from our servers while everything fails in your browser, that uniformity is the signature of a captive portal intercepting your whole connection, not a per-site problem.

Resolution Checklist

Open any plain HTTP site in a browser to trigger the portal. Many portals only inject their login on an unencrypted request; navigating to a known HTTP endpoint (or letting your OS’s captive-portal detection run) forces the “Sign in to network” page to appear so you can authenticate.
Complete the network login, then retry. Accept terms, enter the room/access code, or pay. Once the portal releases your MAC address, traffic flows normally and the 511s stop.
Confirm it’s the network, not the site. Run an external HTTP Check. Normal response from outside + failure in your browser = local captive portal. Same 511 from outside = origin misconfiguration.
If it’s your own origin returning 511, change it to 401. An application endpoint that wants credentials should send 401 Unauthorized with a WWW-Authenticate header, not 511. Reserve 511 for actual network gates; emitting it from an origin poisons captive-portal detection for your clients.
For non-browser clients stuck behind a portal, authenticate in a browser first. A package manager or app can’t fill in a login form. Get past the portal in a browser on the same machine, then re-run the tool — it inherits the now-open network path.
Don’t let the 511 response get cached. If you operate a portal, make sure the 511 carries no-store semantics per the RFC; a cached network-gate page served to an already-authenticated user is its own support ticket.

When to Escalate

If you’re on a managed network and can’t reach the portal login at all, escalate to whoever runs the Wi-Fi — the portal’s own web server may be down, or DNS interception may be misdirecting the probe URLs the login flow depends on.
If an origin you don’t control is returning 511 with no portal in sight, report it to the operator as a status-code bug: it’s breaking captive-portal detection and confusing every non-browser client that touches the endpoint.