校园网场景里，问题往往出在「认证流量」与「代理」抢优先级
很多同学习惯电脑一开机就打开 Clash，再连 Wi‑Fi。这在家庭宽带或手机热点上通常没问题，但在校园网里，链路顺序常常是：你连上 AP → 系统获得局域网 IP → 访问外网前必须先通过强制门户完成账号认证。门户会把你的首次 HTTP 访问重定向到内网认证页；若此时本机 HTTP 流量已被 Clash 导向境外代理，认证请求可能根本到不了学校内网，浏览器就会一直转圈或提示证书异常。
另一类典型症状是：认证明明做完了，过一会儿又弹登录页。除了会话过期、多终端互踢等学校侧原因外，客户端侧常见原因是分流规则把学校认证域名或内网段匹配到了「代理」策略，导致心跳、计费或二次校验失败。要稳住连接，核心只有一句话：凡是必须走校园内网才能完成认证、计费和访问图书馆资源的流量，都应在规则靠前位置明确标记为直连（DIRECT）。这与单纯「打不开网页」的泛排查不同，而是刻意把 Captive Portal 与规则顺序放在一起设计。
第 1 步：认证前先让浏览器「真直连」，避免门户被代理截胡
在尚未确认已通过强制门户之前，建议采用最保守策略：暂时退出 Clash 客户端，或关闭系统代理写入，或切换到直连／规则里明确不接管 HTTP 的模式（各客户端菜单名称不同，本质是减少对 80/443 的拦截）。然后用系统自带浏览器打开任意常见网站，等待自动跳转到学校登录页，完成账号密码或二次验证。
若你必须保留 Clash 进程（例如同时挂着别的任务），可尝试：在客户端里关闭「设置为系统代理」「TUN 模式」「增强模式」等会全局改写流量的开关，仅保留本地端口监听而不接管系统；或在浏览器侧使用「不使用代理」的配置（部分浏览器支持按站点例外，但门槛较高，不如先整体暂停接管来得稳）。校园网认证阶段的目标是：让操作系统认为你在直接访问校园内网与运营商提供的门户地址，而不是把包交给 127.0.0.1 上的 Clash 再转发。
认证成功后，建议先打开一个校外网站确认「已出墙」（对学校网络而言是已获准访问公网），再进入第 2 步配置规则。若学校使用透明缓存或强制 DNS，你会看到 DNS 被指向校内地址，这在下一步会一起处理。
第 2 步：把内网、校园网段与认证相关域名放在分流规则最前
Clash 的规则是按顺序自上而下匹配的，第一条命中的规则生效。因此与校园网相关的条目必须放在「MATCH 国外流量」或「GEOIP 非 CN 走代理」这类宽泛规则之前。常见需要直连的对象包括：
- 私有地址段：例如
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16，以及链路本地169.254.0.0/16（部分设备会用到）。可用IP-CIDR规则配合no-resolve等参数，具体以你所用内核文档为准。 - 学校提供的门户与计费域名：不同学校主机名差异很大，可在未开代理时用浏览器开发者工具看认证页实际请求的域名，再写入
DOMAIN-SUFFIX或DOMAIN-KEYWORD（注意关键词规则误伤面更大，尽量用后缀精确收敛）。 - 图书馆、教务、校内 OA：若学校要求这些资源必须走校内 IP，也应直连；否则可能出现「走了代理反而访问不了教务系统」的情况。
若你使用 GEOIP 或远程 RULE-SET 判定国内外，请核对分流规则集合的加载顺序：内网与校园直连规则应早于 GEOIP，否则内网 IP 可能被误判为「非中国」而送进代理链。更完整的策略组与 Rule Providers 写法见YAML 分流指南。
第 3 步：DNS、fake-ip 与校园解析：避免「认证域名」被错误解析
仅写好分流规则还不够：DNS 若在客户端内被统一改写为远程解析，仍可能导致认证页域名解析到错误地址。Clash 系常见两种增强解析模式：fake-ip 与 redir-host，二者与局域网、校内域名的互动方式不同。
在校园网环境下，建议：
- 为校内后缀或学校指定的认证域名配置 fake-ip-filter（或等价选项），让这些域名走真实解析路径，而不是返回一段虚假地址。
- 若学校 DHCP 下发了校内 DNS 服务器，可通过 nameserver-policy 把特定域名后缀指到校内 DNS，其余仍走你信任的公共 DNS。
- 遇到「只有部分页面无限加载」时，可临时切换到 redir-host 做 A/B 测试，确认是否为 fake-ip 与内网解析冲突。
关于 fake-ip 与 redir-host 的取舍、nameserver-policy 样例与典型报错，可参考本站 DNS 专文中的局域网与直连段落。路由器网关与桌面 Clash 并存时，还要避免 DHCP 把网关指到软路由而 DNS 仍指向本机造成双重劫持，这类拓扑请对照OpenWrt 与桌面客户端并存一文。
第 4 步：认证通过后再逐步打开「系统代理」或 TUN
完成Captive Portal且确认公网可访问后，再开启 Clash 对本机的接管。推荐顺序是：先系统代理，确认规则命中正常，再按需升级到 TUN。原因是 TUN 会在路由层兜更多流量，排错面更大；在校园网这种对内网依赖强的环境里，先小步验证可降低「一开 TUN 全校断网」的心理压力。
若你确实需要 TUN（例如命令行、游戏或不读系统代理的应用），请在开启前再次确认第 2、3 步中的直连与 DNS 策略已生效。TUN 与系统代理的差异、权限与虚拟网卡问题，可并行阅读桌面端 TUN 专文，但请始终把「校园内网优先」作为前置条件，而不是先调节点再调规则。
第 5 步：用连接日志验收：认证页、内网与订阅更新是否仍走错路
配置完成后，建议在客户端连接日志里抽查三类目标：
- 访问学校认证页或心跳接口时，策略是否为 DIRECT，延迟是否落在校园网合理范围。
- 访问教务、图书馆等内网业务时，是否仍误走代理节点（若出现，补 DOMAIN 或 IP 规则并前移）。
- 订阅链接更新是否成功：若订阅域名被错误直连或错误代理，会导致节点列表过期；对照日志里订阅请求的命中规则与 TLS 错误信息逐项修正。
若仍频繁退回登录页，先在学校允许的范围内排除账号会话问题，再在 Clash 里搜索认证相关域名是否被某条宽泛规则（例如大型广告拦截规则集）误杀。此类问题往往需要「精简规则集」或「为校园域名加白」而不是盲目换节点。
整体而言，Clash 校园网场景的关键不是「哪个节点快」，而是强制门户与分流规则谁先谁后：认证与内网必须稳定直连，其余流量再按你的策略组走代理。把顺序写对，比反复重装客户端有效得多。
常见问题（与上文 5 步对照）
问：为什么一定要先浏览器直连认证，再开 Clash？
答：未认证时，外网默认不可达，学校会把流量导向内网门户。若 HTTP 连接被提前送进境外代理，认证页无法呈现，你会看到长时间空白或证书错误。先直连完成会话，再让 Clash 接管，是避免认证页面进代理的最短路径。
问：分流规则里 GEOIP 和国内直连要怎么和校园网共存？
答：原则是「更具体的内网与校园规则在前，国家/地区类规则在后」。不要把「所有非中国 IP 走代理」写在私有网段规则之前。具体条目命名与策略组依赖你的订阅与规则集版本，可对照 YAML 指南中的示例逐步添加。
问：在图书馆用手机热点给电脑开代理是否更简单？
答：有时是权宜之计，但热点与校园网策略、计费无关，且可能违反校规。本文聚焦在合规使用校园 Wi‑Fi 的前提下，用配置解决问题。
写在最后：先让内网「看得见」，再让代理「接得住」
Captive Portal 与 Clash 并不天然互斥，冲突多半来自接管顺序与规则优先级：认证流量需要真实的内网路径，而代理的本质是改写路径。把直连写清楚、把 DNS 与 fake-ip 对齐、再用日志验证，你就能在宿舍与图书馆里稳定使用 Clash，而不必每天重复登录或赌运气换节点。相比其他同类工具，Clash 系在规则表达与 Meta 生态上一致性较好，长期维护订阅链接与规则集时，复用本站 YAML 与 DNS 教程能显著省时间。
如果你希望在一个入口获取各平台客户端、并在下载页统一维护免费订阅链接与版本说明，可以从我们的下载中心选择适合自己系统的发行版，把精力留给网络策略本身。
更多内容可继续浏览技术专栏中的 YAML 分流、DNS 与 Meta 内核升级等文章，把「认证 → 直连 → 规则 → 模式」串成一条完整链路。