连商场或机场 WiFi 要网页校验时，Clash 开代理后打不开登录页？Captive portal 与分流设置一路走下来

为什么一开 Clash，公共 WiFi 的校验页就「消失」了？ 内在逻辑与实践

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

要留意之处在于——门户检测与登录页惯常必须走「当前热点分配的本地网关与 DNS」这条直连路径。一旦这些请求被错漏地送进远程节点，或解析结果被 fake-ip 替换，操作系统就以为「已经能上网」，真正落地时校验页根本打不到真实门户，于是出现白屏、无限转圈、或只显示「已连接无互联网」。

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

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

典型现象：你完全能对照哪几条 技术拆解

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

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

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

先放在心上一条铁律：先完成门户，再谈分流 结构解析

实操上最稳妥的顺序是：

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

更严格地说：这条顺序看似朴素，却能规避八成「校验页打不开」的求助。数不清用户习惯「先开代理再连 WiFi」，在公共热点上很容易把个人锁进死胡同——因为第一次到位探测就没走对路。

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

系统代理重心影响尊重系统设置的浏览器与部分应用。若你仅开启系统代理而未启用 TUN，某些系统级探测仍存在存在可能直连，正因如此有时表现为「关 Clash 能校验，开系统代理后只有浏览器异常」。此时在前验一遍浏览器是否被扩展劫持、是否走了独立代理，以及 Clash 是否改写了 PAC。

若规则里没有把这类流量提前放行直连，就会出现「校验永远完不成」或「校验后初始路由被改乱」的现象。TUN 的适用当下与在意点可参考本站 《Clash TUN 模式完全指南》，但请放在心上：在热点未校验阶段，TUN 的「全量感」更强，也更免不了要显式 DIRECT 规则。

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

分流怎么写：把「门户」固定在直连 内在逻辑与实践

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

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

换个层面：私有网段：将 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 不会被误送节点，以免本地回环与客户端面板异常。

DNS、fake-ip 与「校验后仍断网」 技术拆解

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

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

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

分系统的小提示 结构解析

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

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

在 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，开启流畅上网新实际感受