连商场或机场 WiFi 要网页认证时，Clash 开代理后打不开登录页？Captive portal 与分流设置步骤

为什么一开 Clash，公共 WiFi 的认证页就「消失」了？

很多用户在商场、机场、高铁站或连锁酒店连上 WiFi 后，系统会提示需要网页认证或扫码登录。这类网络在工程上通常依赖强制门户（captive portal）：在你未完成身份验证之前，运营商或场地方会把大部分外网访问重定向到一台内网门户服务器，只有完成登录后才放开出口。

当你在本机打开 Clash 并启用系统代理或 TUN 时，浏览器和系统的联网路径被改写：HTTP(S) 可能指向本机 Mixed 端口，IP 层流量则可能被虚拟网卡截获后再交给 Mihomo 做策略。问题在于——门户检测与登录页往往必须走「当前热点分配的本地网关与 DNS」这条直连路径。一旦这些请求被错误地送进远程节点，或解析结果被 fake-ip 替换，操作系统就以为「已经能上网」，实际上认证页根本打不到真实门户，于是出现白屏、无限转圈、或只显示「已连接无互联网」。

这与 《Allow LAN 与局域网代理》 里讨论的「同一局域网多设备共享代理」不同：公共热点场景的核心矛盾是在未认证前，你的设备在路由上仍处于受限状态，任何把「本应去网关的探测与重定向」强行代理化的行为，都会让门户流程断裂。

典型现象：你可以对照哪几条

下面几种组合在排障群里极其常见，且都与「代理 + 强制门户」强相关：

• 关闭 Clash 时能弹出认证页或自动跳转登录，打开系统代理或 TUN 后反而打不开；
• 手机连同一热点可以认证，笔记本开了 Clash 却不行；
• 浏览器地址栏里出现奇怪的跳转链，最终停在空白页或证书报错；
• 认证按钮点得通，但认证完成后仍无法访问外网，直到关掉 TUN 或改规则才恢复；
• 仅部分域名（例如场地方自己的登录域名）需要直连，其余流量你希望继续分流，但规则顺序不对导致登录域名仍走了代理。

若你同时遇到「只有浏览器能走代理、其它软件异常」，可再对照 《系统代理与 TUN 差异排查》，避免把纯门户问题误判成全局模式失效。

先记住一条铁律：先完成门户，再谈分流

实操上最稳妥的顺序是：

1. 连上 WiFi 后暂时关闭 Clash 的系统代理与 TUN（或退出客户端），让操作系统用默认路由完成探测与重定向；
2. 在系统浏览器中完成网页认证或扫码关联；
3. 确认能访问任意一个公网测试页（由场地方放行或已解除限速）；
4. 再打开 Clash，按需启用系统代理或 TUN，并确保门户相关域名与内网网段在规则里优先 DIRECT。

这条顺序看似简单，却能规避八成「认证页打不开」的求助。许多用户习惯「先开代理再连 WiFi」，在公共热点上很容易把自己锁进死胡同——因为第一步探测就没走对路。

系统代理和 TUN，哪一种更容易踩坑？

系统代理主要影响尊重系统设置的浏览器与部分应用。若你仅开启系统代理而未启用 TUN，某些系统级探测仍可能直连，因此有时表现为「关 Clash 能认证，开系统代理后只有浏览器异常」。此时优先检查浏览器是否被扩展劫持、是否走了独立代理，以及 Clash 是否改写了 PAC。

TUN 则在更广范围内接管 IP 层流量，强制门户使用的小型 HTTP 探测请求、对门户域名的 302 重定向、以及对 RFC1918 私网地址的访问，都更可能被统一送入内核。若规则里没有把这类流量提前放行直连，就会出现「认证永远完不成」或「认证后默认路由被改乱」的现象。TUN 的适用场景与注意点可参考本站 《Clash TUN 模式完全指南》，但请记住：在热点未认证阶段，TUN 的「全量感」更强，也更需要显式 DIRECT 规则。

分流怎么写：把「门户」固定在直连

完成登录后仍建议保留一组置顶于订阅规则之前的直连条目，避免下次休眠唤醒或 DHCP 续租后再次掉进门户。常见写法思路如下（具体语法随你使用的内核与配置格式略有差异，此处强调顺序与语义而非照抄）：

• 私有网段：将 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 等 RFC1918 段设为 DIRECT，让网关与内网门户可达；
• 场地方提供的登录域名：若页面地址栏里出现固定后缀（例如物业或运营商的门户域名），用 DOMAIN-SUFFIX 或精确域名置顶 DIRECT；
• 操作系统探测域名：不同系统会用不同主机名检测「是否需登录」，将这些探测域名直连可减少「假联网」；
• 本地与环回：确保 localhost、127.0.0.1 不会被误送节点，以免本地回环与客户端面板异常。

若你使用大型社区规则集，仍建议自建一小段「热点 / 门户」规则放在 RULE-SET 之前。规则集更新频繁，但你的物理环境是本地网关——本地网关永远应当优先于远程策略。这与日常「国内外分流」不冲突：你只是为「当前局域网的生存必要流量」预留快车道。

DNS、fake-ip 与「认证后仍断网」

另一类高频问题是：网页认证已经显示成功，但开启 Clash 后外网仍不可用。此时除了看规则，还要怀疑 DNS 与 fake-ip 的交互。

当内核使用 fake-ip 为域名返回虚假地址以便后续嗅探与分流时，若某些本应直连的门户域名也被分配了 fake-ip，浏览器会尝试连接一个并不存在的本地映射，表现为页面打不开或反复重试。处理方式通常是：将门户相关域名加入 fake-ip 过滤或跳过列表（视客户端与内核选项而定），或确保这些域名在 DNS 阶段就走真实解析并配合 DIRECT。

同时，公共热点往往下发运营商 DNS。若你在 TUN 下强制所有 53 端口查询进 Clash，而规则又未放行该 DNS 服务器所在网段，也可能出现「解析看似成功、连接却失败」的错觉。排障时可在日志里观察 DNS 查询与最终连接目标是否一致。

分系统的小提示

在 Windows 上，若曾启用自动检测设置或 PAC，记得核对「设置 → 网络和 Internet → 代理」里是否被 Clash 写入了与预期不符的条目。部分企业安全软件会叠加过滤驱动，与 TUN 并存时路由表更复杂，可暂时以「仅系统代理」完成认证，再分层开启 TUN。

在 macOS 上，Captive Network Assistant 有时会单独弹窗。若 TUN 已接管，弹窗可能拿不到正确响应。此时关闭 TUN、用 Safari 完成认证，再按前文顺序恢复，通常最快。若你同时用着 iCloud 专用代理或第三方 VPN，注意多网络扩展争用会导致路由抖动。

在 Android / iOS 上，VPN 类 Clash 客户端一旦建立隧道，系统探测同样可能被改写。若热点强制门户，常见做法仍是先断开 VPN 完成登录，或在客户端提供的「绕过私有地址 / 分应用」选项中把系统浏览器与探测流量留在直连（具体以你所用客户端为准）。

可打印的检查清单（建议按序勾掉）

1. 连接热点后先关 Clash，用系统浏览器访问任意 http 站点，确认能否被重定向到门户；
2. 完成短信或扫码认证，确认外网可用后再启动 Clash；
3. 在规则最前加入 RFC1918 与已知门户域名的 DIRECT；
4. 若用 TUN，核对虚拟网卡是否抢占了默认路由，必要时在客户端里调整「严格路由」或等价选项；
5. 观察 Mihomo 日志：门户阶段应看到直连命中，而非远程节点；
6. 若认证后仍异常，暂时关闭 fake-ip 或排除门户域名，再逐项恢复。

涉及 WSL2、Docker 或虚拟机的用户，热点场景下还要避免子网路由与宿主机默认网关打架，可延伸阅读 《Windows 11 上 Clash 与 WSL2 路由》；其核心思想与本文一致：先保证宿主机能按热点要求完成门户，再叠加复杂拓扑。

小结

公共 WiFi 上的 强制门户（captive portal）依赖直连网关与特定探测流程；Clash 的 系统代理与 TUN 会改变流量入口，若缺少针对性的 直连（DIRECT） 与 分流 置顶，就容易出现认证页打不开或认证后仍断网。把「先认证、后代理」当作默认流程，再配合 RFC1918 与门户域名的规则优先级，大多数场景可以稳定复现成功路径。

相比在搜索引擎里零散试错，按本文顺序逐项排除，能更快判断问题是出在规则顺序、DNS fake-ip，还是多网络扩展冲突。持续维护的 Clash 系客户端在分流与 TUN 组合上已经相当成熟；若你希望从安装、订阅到规则模板系统上手，不妨通过本站渠道获取适合自己系统的构建版本。→ 立即免费下载 Clash，开启流畅上网新体验