Captive portal login help
Use a plain HTTP request to bring up the Wi-Fi sign-in page and confirm access.
Use a plain HTTP request to bring up the Wi-Fi sign-in page and confirm access.
Headers
| Header | Value |
|---|---|
| accept | */* |
| accept-encoding | gzip, br, zstd, deflate |
| cache-control | max-age=259200 |
| connection | close |
| host | nossl.sh |
| user-agent | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) |
| via | 1.1 squid-proxy-5b5d847c96-sqdxt (squid/6.13) |
| x-forwarded-for | 216.73.216.213 |
| x-forwarded-proto | http |
| x-real-ip | 216.73.216.213 |
Captive portals intercept unencrypted HTTP traffic. Join the Wi-Fi network and open http://nossl.sh so the gateway can redirect you.
If the portal does not appear, pause VPNs or private relay features that hide the first request.
Reload this page after you sign in. If you see your IP and headers without a redirect, the portal released you.
Share the request snapshot with support if browsing still fails.
Forget the Wi-Fi network and reconnect, or try the device captive portal checks for Apple and Android.
The gateway might not like HTTPS-first traffic or cached cookies. Reload the HTTP page, clear the browser cache, or reconnect to force a fresh redirect.
Captive portals are commonly delivered over HTTP. Avoid entering sensitive data beyond the login itself and switch to HTTPS sites after you are online.
Reload http://nossl.sh and confirm you see the diagnostics page without being redirected to the portal.
Open the official Apple CNA page to force the captive assistant on iOS and macOS devices.
Open Apple captive portalUse the Android connectivity check URL that devices call before presenting the portal dialog.
Open Android captive portal