校園網場景裡，問題往往出在「認證流量」與「代理」搶優先級
很多同學習慣電腦一開機就打開 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 內核升級等文章，把「認證 → 直連 → 規則 → 模式」串成一條完整鏈路。