Captive Portal Not Working on Mac: How to Fix the Hotel Wi-Fi Login Page

A captive portal works by intercepting your first unencrypted web request and answering it with a redirect to the network's sign-in page instead of the site you asked for. macOS knows about this behaviour and runs an automatic connectivity check as soon as you join a Wi-Fi network. If that check gets a redirect rather than the expected response, macOS opens a small captive-network assistant window with the portal inside it.

So the login page failing to appear almost always means one of two things: either the connectivity check never got a clean answer, or the redirect it was supposed to receive was blocked, encrypted, or sent somewhere the portal could not reach. The Wi-Fi connection itself is usually fine. The negotiation on top of it is what broke.

The usual causes, roughly in order of how often they turn out to be the problem: the portal cannot intercept an HTTPS request, so anything you open in the browser fails with an error instead of redirecting; a custom or encrypted DNS setting, such as DNS-over-HTTPS, a third-party resolver, a Pi-hole or NextDNS, prevents the redirect from ever reaching you; an active VPN wraps your traffic before the network can touch it; the captive-network assistant window was dismissed early and does not come back on its own; cached DNS from a previous network points your Mac at addresses that no longer apply; a private, randomised Wi-Fi address confuses the portal's session tracking; or a content filter or firewall quietly blocks the portal's request.

One thing worth noticing about that list: almost every item on it is something protecting your privacy or security doing exactly its job. Captive portals rely on being able to intercept traffic. Modern macOS, modern browsers and modern security tooling are built to prevent exactly that. The conflict is structural, not a bug on either side.

Forget the network and rejoin it. This is the highest-yield fix and it takes about fifteen seconds. Open the Wi-Fi settings, remove the network from the list of known networks, then join it again from scratch. Rejoining forces macOS to run its connectivity check fresh, which is usually enough to bring the captive-network assistant back.

Open a plain http:// address in a browser. If the assistant window does not appear, you can trigger the redirect manually, but only with an unencrypted request. Typing a normal site name will not work: browsers default to HTTPS now, and an HTTPS request cannot be redirected by the portal, so you get a connection error or a certificate warning instead of a login page. Type the address with http:// in front of it explicitly, and pick something unlikely to force an upgrade. Two addresses commonly used for this are http://neverssl.com and http://captive.apple.com. If the portal is working at all, one of them should bounce you straight to the sign-in page.

Disconnect your VPN. If a VPN is connected, or set to connect automatically, the portal cannot intercept anything, because your traffic is already encrypted and tunnelled elsewhere. Turn it off completely rather than just ending the current session, sign in, then turn it back on. Many VPN clients have an auto-connect or always-on setting that will reconnect within seconds and quietly undo your progress.

Check the clock. This sounds unrelated but is worth ten seconds. If your Mac's date and time are significantly wrong, certificate validation fails across the board, and portal pages that use HTTPS for the actual login form will refuse to load. Setting date and time back to automatic resolves it.

If all four fail, the cause is very likely DNS or a privacy setting, and the next two sections cover those in order.

Captive portals depend on DNS more than most people realise. When your Mac looks up an address, the network's own DNS server answers with the portal's address instead of the real one, and that is how the redirect starts. If your Mac is not asking the network's DNS server, that first step never happens.

This is why manually configured DNS is such a frequent cause. If you have set your Mac to a third-party resolver, or point it at a Pi-hole at home, or have DNS-over-HTTPS or a service like NextDNS configured, your lookups are going somewhere the hotel network cannot intercept. The fix is to set DNS back to automatic, temporarily. In macOS network settings you can remove the manually entered DNS servers, which returns the Mac to whatever the network provides over DHCP. Sign in, then put your own settings back. Encrypted DNS installed through a configuration profile may need to be disabled rather than edited, but the principle is the same.

How do you tell DNS is the problem? A good signal is a plain http:// address failing to resolve at all rather than redirecting, or failing instantly rather than after a slow timeout. Another: the router or gateway loads fine when typed as a bare IP address, but nothing typed as a name works. That points at name resolution rather than connectivity.

The VPN case has its own signature. With a VPN active the connection often looks entirely healthy, the client may even report a working tunnel, and yet no site loads and no portal appears. Some VPN clients ship a captive-portal or hotspot-detection mode that briefly allows unencrypted traffic so you can sign in. If yours has one, enable it. If not, disconnect fully, sign in, reconnect.

Stale DNS from a previous network can also linger. If you have just moved between networks and the Mac seems to be reaching for addresses that make no sense for where you are, flushing the DNS cache clears it. This is usually done from Terminal with sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder, though the exact command has varied across macOS releases. If you would rather not type commands, restarting the Mac achieves the same thing, and toggling Wi-Fi off and on clears a surprising amount of it.

Private Wi-Fi Address. macOS uses a randomised hardware address per Wi-Fi network by default, which makes it much harder for network operators and anyone nearby to track your device across locations and over time. It is a genuinely good feature. It also confuses some captive portals, particularly ones that tie a paid or time-limited session to a hardware address, and hotel systems that expect the same device to look the same each time it reconnects. The symptom is usually signing in successfully and then being thrown back to the login page minutes later, or a session you paid for yesterday not recognising you today.

You can turn Private Wi-Fi Address off for a single network in that network's Wi-Fi settings. Be clear about the trade-off, though: this is not a setting to switch off globally. Disabling it for one hotel network for one stay is a contained decision. Disabling it everywhere hands a stable identifier to every network you ever join. If you do turn it off for a portal, turn it back on, or forget the network entirely, when you leave.

Encrypted DNS and content filters. The same logic applies to DNS-over-HTTPS and DNS-over-TLS. They exist precisely so the network cannot see or alter your lookups, which is exactly what a portal needs to do. There is no clever way around that: for the sign-in itself, the network needs a window. The right approach is a narrow one, reverting to automatic DNS just long enough to authenticate.

Content filters and parental-control tools sit in the same category. Anything that inspects, rewrites or blocks DNS and HTTP requests can silently drop the portal's redirect, and because such tools are designed to fail quietly, you often get no error at all, just a page that never loads. If you run one, add it to your checklist before concluding the network is broken.

Browser behaviour. Browsers increasingly force HTTPS, block insecure redirects and cache aggressively. Trying a different browser, or a private window, can be enough to get a portal to render. Safari is often the most cooperative, since the captive-network assistant is built on the same engine.

Once you have been through this a few times, a pattern becomes obvious: every fix in this guide involves temporarily lowering a defence. Turn off the VPN. Give up your custom DNS. Reveal your real hardware address. Let an unencrypted request through. Then, having signed in on an untrusted network, you are supposed to remember to put all of it back. Most people do not, which is how a laptop ends up sitting on hotel Wi-Fi for three days with its protections still switched off from Tuesday.

That is the real cost here, and it is worth naming, because the answer is not to give up on protection. Public Wi-Fi is exactly where a Mac benefits from stricter treatment than it needs at home: fewer apps allowed to reach the internet, background services held back, and a clear view of what is actually communicating on a network you do not control.

The way out of the conflict is tooling that knows what a captive portal is, rather than tooling you have to disable around it. That is how NetMute's hotspot protection is built. When your Mac joins an unknown or public network it applies a stricter profile automatically, and it handles captive portals so the sign-in page still loads rather than being blocked along with everything else. You sign in normally, and the strict profile stays in force throughout.

The rest of the app follows the same idea. Network profiles are tied to the Wi-Fi network you are on, so your home rules and your airport rules can be genuinely different without you thinking about it. The per-app firewall blocks anything with one click, and temporary rules expire on their own, which is useful when you want to let one app through for a few minutes. The traffic monitor shows which apps are talking and where.

NetMute is free to download on the Mac App Store, and Premium is a single in-app purchase rather than a subscription. If you spend time on hotel and airport Wi-Fi, a Mac that tightens up on its own and still gets you past the login page removes the part of this problem no checklist can fix: remembering to turn everything back on.