Public WiFi Login Page Won’t Open With Clash? Captive Portal and Split-Tunneling Fix Steps

When the Problem Shows Up

You connect to public WiFi at a mall, airport lounge, or hotel, and the network expects a captive portal — a browser page or QR flow where you accept terms, enter a room number, or verify an SMS code. The operating system is supposed to pop a mini-browser or at least let you open http://neverssl.com or http://captive.apple.com to get redirected. Instead, you already enabled Clash with system proxy or TUN, and the authentication page never appears, loads forever, or shows a foreign error page. Sometimes you complete login, but general browsing still looks “offline” because post-auth checks still flow through a remote proxy that cannot reach the local gateway. None of that means your node list is bad; you are colliding with how hotspots validate clients before the Internet is fully opened.

What a Captive Portal Expects (In One Paragraph)

Most portal implementations hijack the first few HTTP(S) requests and answer from the access controller with a 302, a walled-garden IP, or a block page until the session is approved. The OS and browser rely on direct reachability to the LAN or provider-assigned DNS for names like wifi.example.com or a plain IP. When you insert an outbound that sends everything toward Tokyo or Los Angeles, the handshake no longer looks like a normal “I am on this AP” story. A split-tunneling design keeps those flows on DIRECT while the rest of your traffic uses a policy group, which is exactly what you want after the portal is out of the way.

First Aid: Get the Login Page Back

The least frustrating rule is temporarily turn the proxy off, finish the hotspot workflow in a normal browser, then turn Clash back on. In practice, that means disabling system proxy in your client (or the OS), and if you use TUN mode, toggling TUN off so no virtual interface captures the next hops. It feels crude, but it side-steps every ruleset edge case. After the network shows as connected without warnings, re-enable the features you use daily.

A Sensible Off-and-On Order

  1. Quit or disconnect anything that also installs a VPN profile. Two tunnels arguing over the default route is a separate failure mode, but the symptom looks similar.
  2. In your Clash-based GUI, turn off TUN first if it is on, then disable system proxy if the option exists as a separate control.
  3. Open the OS captive portal prompt if the OS offers one, or use Safari or Edge (not a hardened extension only profile) to trigger detection.
  4. After you see a working public Internet check (a simple search or the venue success page), re-enable system proxy and then TUN if you need full-device capture, not only browsers.

Do not paste random YAML to “whitelist the portal” while you cannot fetch anything at all. You need at least one clean path to learn the exact hostnames the venue uses. Start with a clean OS path, then refine rules with logs.

System Proxy vs TUN: Which One Blocks the Portal First?

System proxy usually breaks only applications that read the system settings, while the built-in captive network assistant can still be happier than a full TUN stack. TUN mode on Mihomo or Clash Meta, by contrast, moves IP-layer traffic — including DNS hijacks defined in the profile — and can make the OS think the wrong resolver answered. If you are deciding what to turn off for thirty seconds, prefer disabling TUN before you rip out the entire profile, then fall back to system proxy if the mini-browser is still wrong.

After Login: Build Split-Tunneling That Respects the Hotspot

Long term, the goal is split tunneling in the sense that Clash’s rule mode leaves local and hotspot infrastructure on DIRECT while your overseas or privacy-sensitive destinations still use a remote outbound. A minimal pattern looks like this in plain language, not as a copy-paste from a single provider: keep RFC1918 space off the remote path unless you have a very specific reason; put the venue’s own domains in front of a broad GEOIP or MATCH that would otherwise over-capture. Our rule split walkthrough explains the mental model; here we only stress the portal-specific twist — you are protecting local discovery, not “unblocking” a stream.

Private IPv4 and Link-Local Traffic

Network equipment on many portals lives on 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. If your rules section is aggressive and a catch-all MATCH,Proxy runs before a sane GEOIP,CN or a domestic direct entry, you can still force garbage through a node even after authentication. Put explicit IP-CIDR or IP-CIDR6 DIRECT lines high in the file for those ranges you trust on that SSID, then refine when you are back on a home network. Travel routers that NAT twice may use odd combinations; a short log session from the client shows what actually matched.

Common Portal Hosts (Verify; Do Not Guess)

Hotspot vendors often use branded hostnames, CDN edges, and cloudfront patterns that change. The honest workflow is: open logs while you browse right after a clean connect, and note which DOMAIN-SUFFIX or full DOMAIN values appear. Add those above your generic proxy rules, tagged DIRECT, and retest. Blindly importing someone else’s “airport” list from a forum is fragile because the next terminal renovation may change Akamai frontends overnight.

Mihomo DNS, Fake-IP, and the Portal Page

Mihomo’s dns block with enhanced-mode: fake-ip is excellent for app compatibility on normal broadband, but on a public WiFi the resolver you need may be the AP’s own forwarder, not a public DoH. If the captive portal name resolves to a fake-ip range and your rules then send the subsequent TCP to a node, you can get a page that is not the venue’s. When that happens, consider adding the portal-related domains to fake-ip-filter (or the equivalent in your build) so they resolve “as the hotspot intended,” or temporarily switch the testing browser to a profile that does not use the Clash stack while you are only doing login. This is a DNS policy issue more often than a “bad node ping.”

I Logged In, but Everything Still Times Out

Check three layers before you RMA the laptop. First, the hotspot may have issued a short session; idle timers drop you into the walled garden again. Second, a global proxy group that ignores domestic CDNs can send health-check hosts overseas, and the provider drops those flows as abuse. Third, IPv6 on the public SSID, if any, may bypass the exact path you tuned for IPv4 only, so a browser looks half-connected. A quick DIRECT test in the client’s log, or a temporary switch to a strict domestic rule group, tells you which bucket you are in.

Android and iOS: Two Extra Friction Points

On Android VPN-style profiles, the OS may treat Clash’s interface as the default tunnel while the system still needs to bring up a web view for sign-in. If the sign-in process repeatedly fails, use the system network panel’s “Sign in to network” action before re-enabling the app. On iOS or iPadOS, profiles such as Stash follow similar rules: finish the portal in Safari, then re-open the client so subscription refresh fetches real YAML, not the venue’s HTML splash page, which the parser will reject. Those symptoms look like a “subscription dead” error when the true cause is still hotspot text returned instead of a config file.

Some enterprise networks explicitly forbid split tunneling for compliance reasons. If you are on a work SSID, follow IT’s tool list. This article assumes personal travel scenarios where the venue allows standard browsing after authentication and you are not bypassing paywalls or access controls, only making your Clash client coexist with a legitimate WiFi sign-on flow.

Recap: A Practical Checklist

  • Turn off TUN and system proxy long enough to complete the captive portal.
  • Re-enable capture from the inside out: system proxy, then TUN, matching how your client labels controls.
  • Use rule mode with DIRECT for private ranges and for log-confirmed venue domains you actually see.
  • Revisit DNS if fake-ip answers steal the authentication page or its assets.
  • Separate “no YAML from subscription URL” from “no Internet” by testing once without the proxy path.

Where to Go Next

Compared with fighting opaque vendor firmware, a maintained Clash build on top of Mihomo gives you a transparent rule pipeline and logging so you can see why a given packet left on DIRECT or through a proxy group. That makes travel networks less of a superstition exercise and more of a solvable set of match lines. If you are still calibrating how much domestic traffic should bypass your nodes, our documentation hub collects additional patterns beyond this hotspot-specific note.

When you are ready to standardize on a client that makes toggling system proxy and TUN a single-gesture story, a polished GUI beats editing YAML on a bench at three in the morning. Download Clash for free and experience the difference — the same split-tunneling ideas apply whether you are at home or stuck behind a shopping-mall welcome screen.