DNS redirect vs HTTP redirect for captive portals: which is better?

Key takeaways: DNS redirect intercepts DNS lookups and responds with the portal IP. HTTP redirect intercepts outbound HTTP connections and returns a 302 redirect to the portal URL. DNS redirect is more reliable across device types and works with the CNA (Captive Network Assistant) on iOS, Android, and Windows. HTTP redirect is simpler to implement but fails silently when guests use DNS-over-HTTPS (DoH) or custom DNS servers. Most cloud-managed captive portal platforms — including MyWiFi — use a hybrid approach that combines both methods for maximum reliability. HTTPS is the complication that breaks everything.

Technical details reflect protocol behavior as of 2026. OS-specific captive portal detection behavior varies by version.

Captive portal redirects look simple from the outside. Guest connects to WiFi. Browser opens. Login page appears. Guest enters email. Done.

Under the hood, getting that login page to appear reliably on every device, every OS version, every browser, every network configuration — that's where it gets complicated. Two primary redirect methods exist, each with distinct tradeoffs. Understanding them matters for resellers because when a portal "doesn't work" at a venue, the redirect mechanism is usually the culprit.

---

How DNS redirect works

The mechanism

1. •Guest device connects to the WiFi SSID
2. •Device requests an IP address via DHCP
3. •The DHCP response assigns the device an IP and points the DNS server to the AP (or a controller-managed DNS resolver)
4. •Guest device makes a DNS query (e.g., resolving google.com)
5. •Instead of returning Google's real IP address, the captive portal's DNS interceptor returns the IP of the portal login page
6. •Guest's browser connects to the portal IP → login page appears
7. •Guest authenticates
8. •DNS interception stops → subsequent DNS queries resolve normally

Why it works

DNS redirect works because every device on the network must perform DNS resolution to reach anything on the internet. By controlling the DNS response, the portal controls where the device goes. It's a chokepoint that catches all traffic, regardless of what website or app the guest is trying to access.

Advantages of DNS redirect

• •Device-agnostic. Works on iOS, Android, Windows, macOS, ChromeOS, Linux. Every device performs DNS lookups.
• •App-agnostic. Works whether the guest opens Safari, Chrome, or an app that makes HTTP requests. The DNS query is intercepted before the connection begins.
• •CNA compatible. Apple's Captive Network Assistant and Android's connectivity check rely on DNS resolution to detect captive portals. DNS redirect triggers these detection mechanisms reliably.
• •Pre-connection interception. The redirect happens before the device establishes any TCP connection. This is cleaner than intercepting an established connection.

Failure modes

DNS-over-HTTPS (DoH). Modern browsers (Firefox, Chrome, Safari, Edge) can bypass the local DNS server and resolve DNS queries directly through encrypted HTTPS connections to Cloudflare (1.1.1.1), Google (8.8.8.8), or other DoH providers. When DoH is active, the portal's DNS interceptor never sees the query. The device resolves the real IP address, bypasses the portal, and either gets a "connection refused" (because internet access is blocked pre-auth) or silently fails.

Prevalence of DoH: Firefox enables DoH by default in the U.S. Chrome enables DoH opportunistically (uses DoH if the configured DNS provider supports it). iOS 14+ and Android 9+ support DoH at the system level. As DoH adoption increases, pure DNS redirect becomes less reliable.

Mitigation: Block outbound DNS (port 53) and DoH (port 443 to known DoH servers) for unauthenticated devices, forcing them to use the portal's DNS server. Most cloud-managed controllers do this automatically.

Custom DNS servers. Some users configure their device to use a specific DNS server (8.8.8.8, 1.1.1.1) instead of the DHCP-assigned server. If the portal doesn't intercept traffic to those external DNS servers, the redirect fails.

Mitigation: "DNS masquerading" or "transparent DNS proxy" — the AP intercepts all DNS traffic (port 53) regardless of the destination IP and redirects it to the portal's DNS resolver. This catches devices with custom DNS settings.

---

How HTTP redirect works

The mechanism

1. •Guest device connects to WiFi and gets an IP via DHCP
2. •Guest device makes an HTTP request (e.g., http://example.com)
3. •The AP/controller intercepts the TCP connection on port 80
4. •Instead of forwarding the request to the destination server, the AP returns an HTTP 302 redirect response pointing to the portal URL
5. •Guest's browser follows the 302 redirect → portal login page loads
6. •Guest authenticates
7. •HTTP interception stops → subsequent HTTP requests pass through normally

Why it works (sometimes)

HTTP redirect is conceptually simple. It's a standard web redirect — the same mechanism every website uses for URL changes and page redirections. The AP acts as a transparent proxy that intercepts outbound HTTP traffic and redirects it.

The HTTPS problem

Here's where HTTP redirect falls apart in 2026: almost everything is HTTPS.

When a guest's device makes an HTTPS request (which is the default for virtually every website and app), the AP can't inject a 302 redirect without breaking the TLS encryption. The device expects to receive a valid TLS certificate from google.com. Instead, it receives one from the captive portal. The browser displays a certificate error — "Your connection is not private" — which terrifies users and prevents them from reaching the portal.

The numbers: As of 2025, 95%+ of Chrome page loads use HTTPS (Google Transparency Report). That means HTTP redirect only triggers on the shrinking percentage of plain HTTP traffic.

CNA to the rescue

The practical reason HTTP redirect still works for captive portals: operating systems perform captive portal detection using a specific HTTP (not HTTPS) request:

These are intentionally HTTP (unencrypted) requests designed to be interceptable by captive portals. When the OS detects that the response to this request is a redirect (rather than the expected 204 or 200 response), it opens the Captive Network Assistant — a mini-browser that loads the portal login page.

This is why captive portals still work in 2026 despite near-universal HTTPS adoption: the OS-level detection mechanism uses HTTP by design.

Failure modes

CNA bypass. Some users dismiss or close the CNA mini-browser. If they then open a regular browser and type an HTTPS URL, the HTTP redirect can't intercept it. The user sees "no internet" or a certificate error.

API-only devices. IoT devices, smart speakers, and some apps don't perform HTTP connectivity checks. They make direct API calls over HTTPS. HTTP redirect doesn't trigger for these devices, and they appear offline on the guest network until authenticated through another method.

VPN clients. Guests running VPN apps that tunnel all traffic (including DNS) through the VPN connection bypass both DNS and HTTP redirect mechanisms. The portal never appears. The VPN connection fails (because internet access requires authentication), and the guest sees "VPN connection failed" instead of the portal.

---

The hybrid approach: what modern platforms use

Cloud-managed captive portal platforms don't rely on a single redirect method. They use a hybrid approach:

1. •DNS interception catches the initial DNS query from the device
2. •HTTP redirect catches the CNA connectivity check
3. •ICMP redirect (on some platforms) catches devices that bypass DNS and HTTP
4. •Walled garden allows access to the portal URL and authentication endpoints while blocking everything else

How MyWiFi handles redirect

MyWiFi's captive portal operates through cloud controller integrations with Meraki, UniFi, Aruba, Ruckus, and other platforms. The redirect mechanism is managed by the AP vendor's controller:

• •Meraki: Uses a combination of DNS interception and HTTP redirect. The Excap (External Captive Portal) framework handles the redirect and passes the client to the MyWiFi portal URL.
• •UniFi: Uses the UniFi Guest Portal framework, which intercepts DNS and HTTP traffic for unauthenticated clients and redirects to the external portal URL.
• •Aruba: Uses ClearPass or the built-in captive portal engine with role-based firewall policies. Unauthenticated clients are restricted to a "captive portal" role that redirects to the MyWiFi portal.

In all cases, the reseller doesn't configure the redirect mechanism directly. The cloud integration handles it. But understanding what's happening helps you troubleshoot when portals don't appear correctly.

---

Troubleshooting portal redirect failures

When a client reports "the portal doesn't show up," work through this checklist:

Step 1: Identify the device and OS

iOS, Android, Windows, and macOS each have different CNA behaviors. A portal that works on iOS but not on Android (or vice versa) points to a CNA detection issue.

Step 2: Check DNS resolution

From a test device on the guest SSID, try resolving a domain:

• •If the DNS query returns the portal IP → DNS redirect is working
• •If the DNS query returns the real IP → DNS interception is not configured or the device is using DoH/custom DNS

Step 3: Check HTTP redirect

Open a browser on the test device and navigate to http://neverssl.com (a site that never uses HTTPS, designed for captive portal testing):

• •If you're redirected to the portal → HTTP redirect is working
• •If neverssl.com loads normally → HTTP interception isn't configured for unauthenticated clients

Step 4: Check the walled garden

The "walled garden" is the list of domains/IPs that unauthenticated clients can reach before logging in. The portal URL, authentication endpoint, and social login providers (Facebook, Google) must be in the walled garden. If they're not, the portal page loads but the login button fails.

Step 5: Check CNA detection URLs

Verify that the device's captive portal detection URL is being intercepted:

• •Navigate to http://captive.apple.com (iOS/macOS)
• •Navigate to http://connectivitycheck.gstatic.com/generate_204 (Android)

If these URLs load normally (returning the expected content), the portal detection isn't triggering. The AP or controller isn't intercepting these requests for unauthenticated clients.

---

Which method is "better"?

Neither. Both. The question is outdated because modern platforms use both simultaneously.

But if forced to choose:

DNS redirect is more robust because it operates at a lower network layer, catches all device types, and works with the OS-level captive portal detection mechanisms.

HTTP redirect is simpler but increasingly fragile as HTTPS and DoH adoption reduces the surface area of interceptable HTTP traffic.

The best approach is a cloud-managed captive portal that handles redirect through the AP vendor's native framework. This abstracts the redirect mechanism entirely — the reseller configures the portal in the MyWiFi dashboard, and the controller handles the technical details of getting the portal to appear on guest devices.

---

FAQ

Why does my captive portal work on iPhones but not Android devices? iOS and Android use different CNA detection URLs and slightly different redirect handling. If the AP's walled garden or firewall rules block Android's connectivitycheck.gstatic.com, Android devices won't trigger the CNA. Ensure both Apple and Google connectivity check domains are accessible (but interceptable) for unauthenticated clients.

Does DNS-over-HTTPS (DoH) break captive portals? It can. If a device uses DoH to bypass the local DNS server, DNS redirect fails. Most cloud-managed controllers mitigate this by blocking outbound DoH traffic for unauthenticated clients, forcing DNS resolution through the portal's DNS server.

What about DNS-over-TLS (DoT)? DoT (port 853) has the same effect as DoH — it bypasses the local DNS interceptor. Block port 853 outbound for unauthenticated clients as part of the guest VLAN firewall rules.

My portal shows a certificate error on some devices. Why? The device is trying to load an HTTPS site, and the redirect is injecting a portal certificate that doesn't match the requested domain. This is a symptom of HTTP redirect attempting to intercept HTTPS traffic. The fix: ensure the AP uses DNS redirect (which catches the request before TLS negotiation) and that the CNA detection URLs are properly intercepted.

Do I need to configure redirect manually for MyWiFi deployments? No. MyWiFi's cloud controller integrations handle the redirect mechanism through the AP vendor's native captive portal framework. Resellers configure the portal content (design, form fields, redirect URL) in the MyWiFi dashboard. The AP vendor's controller handles the network-level redirect.

---

Resellers troubleshooting portal redirect issues can explore the hardware documentation for vendor-specific configuration details and integration guides.