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

为什么一开 Clash，公共 WiFi 的鉴权页就「消失」了？ 一文看懂

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

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

当你在本机开启 Clash 并启用系统代理或 TUN 时，浏览器和系统的联网路径被改写：HTTP(S) 也许指向本机 Mixed 端口，IP 层流量则也许被虚拟网卡截获后再交给 Mihomo 做策略。

先看这一点：难点在于——门户检测与登录页通常必须走「当前热点分配的本地网关与 DNS」这条直连路径。一旦这些请求被失误地送进远程节点，或解析结果被 fake-ip 替换，操作系统就以为「已经能上网」，事实上鉴权页根本打不到真实门户，于是出现白屏、无限转圈、或只显示「已连接无互联网」。

典型现象：你能够对照哪几条 核心要点

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

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

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

先留意一条铁律：先完成门户，再谈分流 逐条拆解

实操上最稳妥的顺序是：

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

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

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

若规则里没有把这类流量提前放行直连，就会出现「鉴权永远完不成」或「鉴权后内置路由被改乱」的现象。TUN 的适用状态与留意点可参考本站 《Clash TUN 模式完全指南》，但请留意：在热点未鉴权阶段，TUN 的「全量感」更强，也更得显式 DIRECT 规则。

系统代理核心影响尊重系统设置的浏览器与部分应用。若你仅开启系统代理而未启用 TUN，某些系统级探测仍也许直连，所以有时表现为「关 Clash 能鉴权，开系统代理后只有浏览器异常」。此时首位核对浏览器是否被扩展劫持、是否走了独立代理，以及 Clash 是否改写了 PAC。

TUN 则在更广范围内接管 IP 层流量，强制门户运用的小型 HTTP 探测请求、对门户域名的 302 重定向、以及对 RFC1918 私网地址的连通，都更也许被统一送入内核。

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

完成登录后仍推荐保留一组置顶于订阅规则之前的直连条目，避免下次休眠唤醒或 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 与「鉴权后仍断网」 核心要点

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

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

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

分系统的小提示 逐条拆解

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

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

在 macOS 上，Captive Network Assistant 有时会单独弹窗。若 TUN 已接管，弹窗也许拿不到无误响应。此时关闭 TUN、用 Safari 完成鉴权，再按前文顺序恢复，通常最快。若你同时用着 iCloud 专用代理或第三方 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，开启流畅上网新运用感受