The portal works by intercepting DNS. Encrypted DNS cannot be intercepted, so before you authenticate the two are at a standstill. Signing in opens the gate and the standoff ends.
The frustrating part is that this is encryption doing exactly its job. The same refusal-to-be-redirected that protects you on a hostile network is what stalls the hotel login, because the hotel login depends on doing the redirect.
What a captive portal actually is
A captive portal is the sign-in page that public Wi-Fi, in hotels, airports, cafes and trains, makes you pass through before it lets you online. The trick it uses to force that page in front of you is DNS interception. When your device asks for any name, the network ignores the real answer and replies with the address of its own login page instead, so whatever site you try to open, you land on the portal. It is, mechanically, a deliberate and temporary version of the same hijack described in DNS spoofing, only here it is the network doing it openly to collect your agreement to the terms or your room number.
Once you sign in, the portal stops intercepting and lets your traffic through. Until then, it answers every lookup with the same one address: itself.
Why encrypted DNS gets stuck on it
Encrypted DNS exists precisely so the network cannot read or rewrite your lookups. On hostile Wi-Fi that is exactly what you want. But the captive portal needs to rewrite your lookups to function, and your device, with encryption on, sends its questions in a sealed form straight to your chosen resolver. The portal cannot read them to inject its login address, so it does the only thing it can: it blocks the connection to your resolver entirely until you authenticate.
Now you have a standoff. Your device wants to reach its encrypted resolver, which the portal is blocking. The portal wants to show you a login page, which it can only do by hijacking a lookup your device will not let it hijack. So lookups simply fail, no page appears, and it looks like the internet is down. It is not down. It is two correct behaviours refusing to budge, and the fix is just to break the tie.
What your device is doing in the background
Modern phones and laptops expect this. The moment you join a network, the operating system quietly fetches one small, known test address over plain HTTP to check whether it gets the real answer or a redirect. If it gets redirected, it knows a captive portal is present and pops up the "Sign in to network" notification, opening the portal in a stripped-down browser.
That detection probe is intentionally outside your encrypted DNS, so it can still trigger the login even when your normal resolution is sealed. The trouble is that it does not always fire, especially with strict encrypted-DNS modes, and that is when the network looks dead instead of showing the sign-in box.
How to get online, without giving up encryption
In order, easiest first. You almost never need to go past the first two.
-
1
Wait a moment, then tap the sign-in prompt
Give it a few seconds. If the "Sign in to network" notification appears, open it, complete the login, and your encrypted DNS resumes on its own. Nothing to change.
-
2
Open a plain, non-HTTPS page to summon the portal
If no prompt shows, visit a plain http:// address your browser will not silently upgrade to HTTPS. The captive-check pages built into operating systems work best, because portals are tuned to intercept them: http://captive.apple.com is easy to remember and stays on plain HTTP, so the portal redirects it and the login appears. Sign in, and you are through. Your router's own address, often http://192.168.0.1, is a good fallback.
-
3
Briefly relax strict mode, then turn it back on
As a last resort, switch encrypted DNS off or to automatic for a moment (on Android, set Private DNS to Automatic instead of a fixed hostname), load the login, sign in, then switch it back on. The unencrypted window is only the sign-in itself.
One thing not to do: leave encryption off afterward. The captive portal is the one moment it gets in the way, and it lasts seconds. The rest of the time on that same untrusted network is exactly when you want your lookups sealed.
Why "strict" mode is the usual culprit
There is a difference between asking for encrypted DNS and demanding it. Android's Private DNS set to a fixed hostname, and the equivalent strict settings elsewhere, will not fall back to plain DNS for anything, including the portal detection. That is the safer setting in general, and it is also the one most likely to make a captive network look dead, because it refuses even the probe that would have triggered the login.
The automatic mode is the gentler trade: it uses encrypted DNS when it can and steps aside when a network genuinely blocks it, which lets the portal appear. Neither is wrong; they simply weight the same dial differently. If you keep strict mode on, step 2 above is your reliable way through.
A few seconds of sign-in, then sealed again
Captive portals are the one place encrypted DNS gets in its own way, and only until you log in. On every other network it is the protection you want. Set it up once and just sign in when a portal asks.
Set up encrypted DNSRelated: DNS spoofing (the same hijack, done with bad intent), DNS blocking and censorship, and how DNS actually works.