Your hotspot login page won’t load. It is almost always DNS.

The symptom is always the same. A phone joins the Wi-Fi, gets an address, shows the Wi-Fi icon — and then the captive portal never appears. Open a browser and pages simply time out.

Here are the causes worth checking, in the order that finds the problem fastest.

1. Clients were given a DNS server they cannot reach

This is the big one, and it is worth checking before anything else.

A captive portal works by intercepting the client’s first web request. But the browser only makes that request after it has resolved a hostname. If the DNS server the client was handed is out on the internet — 8.8.8.8 is the usual culprit — the lookup goes nowhere, because an unauthenticated client is not allowed out to the internet yet. No lookup means no request, and no request means nothing for the hotspot to intercept.

Check IP → DHCP Server → Networks. The dns-server field should be the router’s own address on that network, not a public resolver.

Then check IP → DNS and make sure Allow Remote Requests is ticked, or the router will refuse to answer the queries you have just pointed at it. Your upstream resolvers go here, in the router’s own DNS servers list.

2. The hotspot server is not actually on the client’s interface

A hotspot server is bound to one interface. If clients arrive on a bridge but the hotspot is bound to a single ethernet port that happens to be in that bridge, traffic may never pass through the hotspot at all.

As a rule: if your clients arrive over a bridge, bind the hotspot to the bridge.

3. HTTPS is doing exactly what it was designed to do

Captive portals intercept unencrypted HTTP. They cannot transparently intercept HTTPS without presenting a certificate for a domain they do not own, which every modern browser correctly refuses.

So if the first thing a phone tries is an HTTPS site, the connection fails silently rather than redirecting. Most current phones handle this themselves by probing a known plain-HTTP address on joining a network, which is what triggers the “Sign in to Wi-Fi” notification.

To test manually, browse to a plain HTTP address such as http://neverssl.com. If the portal appears, interception is working and the earlier failure was just HTTPS behaving correctly.

4. The walled garden is missing something the page needs

If your login page loads but appears broken — no logo, no styling, no fonts — the page is referencing resources the client is not yet allowed to fetch.

Anything the login page loads from outside the router must be in the walled garden, or it will be blocked until after login. This includes web fonts, CDN-hosted CSS, analytics and any external image.

The more robust fix is to stop the page depending on external resources at all: put the CSS inline and the images on the router. A login page that renders correctly with zero internet access is a login page that always works. Our free login page builder produces self-contained pages for exactly this reason.

A quick diagnostic order

1. On a connected client, check which DNS server it was given. Is it the router?
2. On the router, is allow-remote-requests enabled?
3. Browse to a plain HTTP address. Does the portal appear?
4. Does the portal appear but look broken? That is the walled garden.
5. Check IP → Hotspot → Hosts. Are clients listed there at all? If not, their traffic is not reaching the hotspot.

In our experience the first check resolves the majority of cases.