Clash Campus Wi‑Fi: Captive Portal & Rules 2026

What goes wrong on authenticated campus Wi‑Fi

University and enterprise hotspots rarely give you raw internet immediately. The access point intercepts the first HTTP requests and redirects you to a login page—often hosted on a private address or a vendor domain tied to that network. Until you complete that flow, DNS lookups and TLS handshakes to arbitrary sites may be blocked or redirected.

Clash is designed to move traffic according to your rule order: DOMAIN, IP-CIDR, GEOIP, then MATCH. That is powerful for everyday split routing, but catastrophic when the “wrong” rule fires first. If MATCH sends the captive portal URL through a proxy group whose nodes are unreachable until after login, the browser spins forever. The same happens when TUN mode captures everything but your profile lacks a safe bypass for the portal subnet.

Another frequent culprit is DNS mode. With fake-ip, Clash synthesizes addresses for domain queries so that policy routing can attach flows to rules quickly. That is excellent for streaming splits, yet brittle for captive portals that expect real resolver behavior or that use odd internal names. Our Fake-IP versus redir-host article explains when to pivot DNS strategy; here we focus on the captive portal plus rule priority workflow.

IPv6 adds one more wrinkle: if the network advertises global IPv6 while IPv4 still sits behind a portal, some stacks prefer AAAA records and fail in ways that look unrelated to Clash. When you see odd timeouts only on dual-stack sites, test with IPv6 temporarily disabled at the OS level to confirm, then adjust your rules and DNS accordingly.

Step 1 — Reach the portal with a deliberate “direct window”

Before you edit YAML for an hour, give yourself a known-good path to the login page. The pragmatic approach is to pause global capture long enough to authenticate. In most clients that means turning TUN mode off temporarily, or switching to system proxy only, or using a dedicated “direct” profile with MATCH,DIRECT at the bottom.

Why this matters: captive portals are not “one hostname fits all.” Some schools redirect http://neverssl.com-style probes; others expect traffic to 10.x.x.x or 172.16.0.0/12 ranges. If every packet is forced through a tunnel interface whose rules are not yet correct, you are debugging two problems at once—portal reachability and your entire policy table.

After login succeeds and you have general internet, re-enable TUN if you need it. The rest of this guide ensures you do not need to flip that switch every morning: we bake DIRECT exceptions into rule order so the portal path stays local even when the tunnel returns.

1. Disconnect from exotic VPNs that also install filters; two tunnel drivers competing for the default route confuse captive detection.
2. Open a plain browser (not a privacy browser with custom DoH) for the first login attempt.
3. If the OS shows “Sign in to network,” use it—those flows often bypass user proxies by design.
4. Once you see “Connected” or can load an external news site without redirects, you are ready to layer Clash back in.

Step 2 — Identify portal endpoints you must not proxy

Grab the real hostnames and subnets your network uses. On many campuses you will see a redirect to something like wlanauth.example.edu or a vendor cloud such as securelogin.arubanetworks.com. Some portals stay entirely inside RFC1918 space—10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16—which means your IP-CIDR rules must be explicit.

Write these down before editing YAML. If you only memorize “school Wi‑Fi,” you will end up with vague rules that still lose to a catch-all GEOIP line. Precision beats optimism: one wrong ordering line can nullify ten careful DOMAIN entries.

When the portal hostname is shared with unrelated internet services—rare but possible—prefer narrower patterns (DOMAIN for the exact FQDN) over huge DOMAIN-SUFFIX unless you understand the collateral damage. For vendor appliances, the vendor’s documentation often lists required destinations for walled-garden operation; those strings belong in your allowlist.

Step 3 — Order rules so DIRECT wins for intranet and portal traffic

Clash evaluates rules top to bottom. Students often import a community profile where GEOIP,CN,DIRECT or a giant RULE-SET sits above personal tweaks, then wonder why a school portal still proxies. The fix is not “more proxies”—it is inserting specific lines earlier than the rules that send generic HTTPS traffic abroad.

A maintainable skeleton looks like this in concept: private IP ranges to DIRECT; explicit DOMAIN or DOMAIN-SUFFIX entries for portal hosts to DIRECT; regional or campus GEOIP rules if your school issues domestic addresses you want direct; only after that, your streaming and browser proxy groups; finally MATCH to a sane default.

If you rely on Rule Providers, remember they expand into the same ordered list—placement of the rule-providers: section relative to inline rules determines precedence. A provider that dumps tens of thousands of lines before your three campus lines will shadow them unless you load the provider after your exceptions or split providers across files intentionally. The policy group tutorial walks through that structure.

# Illustrative fragment — adapt to your profile; do not copy blindly
rules:
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - DOMAIN,wlanauth.university.example,DIRECT
  - DOMAIN-SUFFIX,campus-network.vendor.com,DIRECT
  # ... your usual splits (AI, streaming, etc.) ...
  - MATCH,PROXY

This illustration is intentionally conservative: wide private ranges direct everything local before your proxy picks up public IPs. If you run services on LAN that must use a remote exit, refine with narrower CIDRs later—get the portal stable first.

Step 4 — Align DNS with those rules (fake-ip, redir-host, nameserver-policy)

Rules only work when the traffic Clash sees matches what you think you wrote. In fake-ip mode, a domain might resolve inside Clash to a synthetic address; your DOMAIN rules may still match, but intranet portals that mix IP literals, captive redirects, and split-horizon DNS can behave oddly. When debugging captive failures, switching DNS mode to redir-host for a test window—or scoping nameserver-policy so the portal domain uses the dorm resolver—often clarifies whether the issue is policy or resolution.

Also watch encrypted DNS. A browser with DoH enabled may bypass the resolver Clash expects, making logs misleading. For the authentication minute, prefer system DNS or the same resolver your school documents, then re-enable DoH after you are online.

If your profile uses fake-ip-filter or equivalent exclusions, consider adding portal domains there so those names never receive synthetic addresses. The exact keys depend on core version; verify against your merged running config rather than a three-year-old gist.

Step 5 — Re-enable Clash, refresh subscription, verify with logs

After the network is “open,” bring Clash back online in the shape you actually want—often TUN on for full-device coverage. Trigger a manual subscription URL update to confirm HTTPS to your provider works through your chosen node group. If the update fails only here, the issue is rarely YAML syntax; it is usually time skew, TLS interception, or a route loop blocking the provider domain.

Open the log panel and load a few sites you care about. You should see portal-related hosts on DIRECT and public sites on your proxy groups. If a school intranet resource must stay domestic while YouTube uses another exit, split them into separate policy groups and keep ordering tight: specific DOMAIN rules first, broad GEOIP second, MATCH last.

Document what you changed. Campus networks sometimes swap captive vendors between semesters; a short note in your profile (“Added DOMAIN X on 2026-04-19 after SSID change”) saves future you from repeating the same trace.

Repeatable checklist you can paste into notes

When time is short before an exam block or library deadline, run the same five checks: (1) can you load the portal with Clash minimally invasive—TUN off or MATCH direct? (2) did you list concrete portal FQDNs and RFC1918 ranges? (3) are DIRECT lines physically above the rules that grab general HTTPS? (4) does DNS mode match that story—fake-ip versus redir-host versus nameserver-policy? (5) after login, does subscription refresh succeed and do logs show expected splits?

If any answer is “maybe,” fix that layer before buying new nodes. Captive portals punish vague configuration because they sit at the boundary between “local network trust” and “everything else.” Clash is precise; give it precise inputs.

One more habit helps in shared housing: when roommates change the SSID password or IT rotates certificates, re-validate the portal URL in a clean browser profile before you blame the proxy. Corporate and university networks sometimes publish maintenance windows; a captive page that moved from HTTP to HTTPS-only or swapped DNS names will look exactly like a “broken Clash” until you compare against an unproxied baseline on the same SSID.

• Transport — Confirm whether you are on system proxy, TUN, or mixed; each changes where DNS and routes apply.
• Policy groups — Keep campus DIRECT rules out of unrelated url-test groups to avoid flapping health checks.
• Updates — A working browser does not guarantee subscription fetch if the update path uses a different SNI or IP family—read the error string.

Quick FAQ

Why does “Sign in to Wi‑Fi” work but the browser does not?

Operating-system captive helpers often use a narrow set of probes that ignore user proxies. Your general browser session may still be steered by Clash. Align Clash rules with Step 3 so both paths agree.

Do I need special rules for Apple or Android captive detection?

Sometimes. If logs show Apple or Google connectivity URLs hitting the wrong policy group, add explicit DIRECT lines for those hostnames. Do this only when observed—do not cargo-cult huge lists from random forums.

Is OpenWrt different?

Gateway deployments add DHCP and dnsmasq into the story. The ordering principle is identical: local portal and RFC1918 first, then split routing. See our OpenWrt gateway guide for coexistence with desktop clients.

Closing thoughts

Clash on campus Wi‑Fi is not a special edition of the client—it is the same split routing engine with a sharper edge case. Captive portals punish sloppy rule order and DNS assumptions faster than most home broadband setups because authentication sits before the internet you are trying to optimize. Treat the portal as a first-class citizen in your policy table: DIRECT lines early, explicit hostnames, aligned DNS, then resume your usual groups for everything else.

Compared with endlessly toggling nodes, a clean five-step pass—direct window, identify endpoints, order rules, align DNS, verify logs—usually restores stability in one sitting. Keep your Meta core current, keep profiles readable, and prefer small edits you can undo. When you need a maintained desktop build with modern stacks, start from the site’s download page rather than random mirrors so helper binaries stay compatible with your OS.

Explore more routing patterns in our tech column, especially the YAML routing tutorial and subscription update checklist when refreshes fail for reasons unrelated to captive portals.