HTTP 511 Network Authentication Required

Quick reference

How captive portals work

A captive portal intercepts all outgoing HTTP requests from a newly connected client and serves a login or terms-of-service page instead of the requested content. Before authentication, every HTTP request you make is silently redirected to the portal's page.

HTTP 511 was introduced to provide a standards-compliant signal for this network-level authentication requirement. Without 511, captive portals return a login HTML page with a 200 OK status — making the response look like a successful answer to the request, which confuses automated clients, health checks, and applications that assume 200 means correct content.

511 responses must not be generated by origin servers. A real application server should never return 511 — only network intermediaries should. If an origin server returns 511, it is misconfigured. The response body should contain a link to the captive portal page where authentication can complete.

Common causes

• Hotel, airport, or coffee shop Wi-Fi: Guest networks require authentication or terms acceptance. Until authenticated, all HTTP requests are intercepted by the captive portal.
• Corporate network authentication gateway: Many organizations require network-level authentication (separate from VPN) before accessing internal or external resources.
• Campus or educational network: University and school networks often use captive portals requiring student or staff login before granting network access.
• Application health checks on restricted networks: Monitoring agents running on network-restricted hosts may receive 511 when the host is behind an unauthenticated captive portal, causing spurious failure alerts.

How to handle HTTP 511

As an end user

1. Open a web browser and navigate to any plain HTTP URL. Browsers detect captive portals and redirect to the login page.
2. On mobile devices, look for a system notification that appeared when you joined the network — it typically prompts you to complete network login.
3. Complete the authentication or accept the terms of service on the captive portal page, then retry the original request.

As a developer

1. Detect 511 separately from 401. A 511 means you cannot reach your intended server at all — not that the server rejected you. Handle it differently in your client logic.
2. Surface the portal URL. The 511 response body contains a link to the captive portal. Extract and present it so the user can authenticate.
3. Implement captive portal detection. Before critical requests, probe a known URL (e.g., Google's connectivitycheck.gstatic.com). If the response is unexpected, assume a captive portal and alert the user.
4. Handle 511 in monitoring. Detect 511 from captive portals and suppress false positives, or ensure your monitoring infrastructure runs on unfiltered network connections.

Example exchange

GET /api/data HTTP/1.1
Host: api.example.com

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<p>You must authenticate before accessing the internet.</p>
<a href="https://portal.network.example/login">Login here</a>

The captive portal intercepts the request to api.example.com, returns 511, and provides a login link. The client was never connected to the intended server.

511 vs 401 vs 407 — authentication at different layers

Related Guides

HTTP 401 Unauthorized · HTTP 407 Proxy Authentication Required · HTTP 403 Forbidden

Comparisons

HTTP 511 vs 401

Standards reference

This definition is derived from the IANA HTTP Status Code Registry and RFC 6585 §6. Human-readable operational guidance by ErrorLookup. · HTTP 511 quick reference →