連商場或機場 WiFi 要網頁認證時，Clash 開代理後打不開登入頁？Captive portal 與分流設定步驟

商場、機場 WiFi 一開 Clash 就沒有登入頁，是什麼情況？

不少使用者在飯店、高鐵站、展場或辦公訪客網路連上 公共 WiFi 時，作業系統本來會偵測到「尚未完全上網」，自動跳出 Captive portal（臺灣常稱 強制入口網路 或 網頁認證）的登入畫面。此時若同時在筆電上開啟 Clash 系列用戶端、並啟用 系統代理 或 TUN 模式，作業系統用來判斷是否仍被關在「圍牆內」的偵測流量，可能被導到遠端節點、或被規則改寫，導致偵測回應看起來「已經能上外網」，系統便不再幫你打開 認證頁面；另一種則是登入 URL 的網域或閘道 IP 被代理出去，實際連不到內部網頁。本文用固定分層順序還原：先完成 直連 通過 分流 以外的內建步驟，再談 分流 規則怎麼補，最後點到與 WSL2、全域代理有關的站內延伸閱讀，避免和「只有瀏覽器能走代理」或「WSL2 路由」兩主題重疊又混淆。

Captive portal 與 Clash 為何會衝突？

多數 公共 WiFi 在未完成驗證前，只允許極少數位址可達（例如內部閘道、供應商自訂的登入主機、或導向 Captive 的 HTTP 回應）。作業系統與瀏覽器會向已知偵測端點發出請求，若回應不是預期碼，就判斷仍處在需認證狀態，並幫你開啟一個導向實際登入表單的連結。當 系統代理 把包括這些偵測在內的 HTTP(s) 全塞進 Clash 核心、而核心又預設把流量送到境外節點時，偵測可能得到「偽造的正常網路」結果，讓你以為可以上網，卻從沒在本地熱點內打開 認證頁面。

若你改開 TUN，整台電腦的 IP 層轉送改由虛擬介面與核心路由接手，層次更高：DNS、ICMP、到閘道與內部網段的走法都會變。若沒有把「熱點內的私有網段、閘道、以及登入用網域」留在 直連，一樣會出現轉圈、只見瀏覽器錯誤頁、或彈出空白頁。觀念上可併讀 TUN 模式完全指南，釐清 系統代理 只影響支援代理的應用，而 TUN 是更廣的接管，與 Captive portal 的衝突點不盡相同但常一起發生。

步驟一：登入前暫停代理，是最穩的捷徑

實務上最省事、也最不容易和路由器百態搏鬥的方法，是連上 SSID 之後、看到訊號已連線，但尚未打開 認證頁面 時，先在 Clash 圖形介面把系統代理 與 TUN 一併關閉（或切到不會寫入系統的全域狀態），讓作業系統用預設路由完成 Captive portal 偵測。macOS 與 Windows 多數情況下會在幾秒內自動彈出瀏覽器視窗，或顯示「需要登入此網路」；若沒有，可手動開瀏覽器造訪 http://captive.apple.com、http://www.msftconnecttest.com 等常見觸發頁，僅在關代理狀態下測。完成手機簡訊、一鍵登入、或掃碼之後，再回頭開啟 Clash 即可。這比一邊上網一邊改 YAML 還是快，且能排除「其實是熱點本身 DNS 有問題」的假警報。

步驟二：若必須開著核心，讓內網與偵測路徑 直連

部分使用者因為要長駐 分流 或內部腳本依賴本機代理埠，不希望在公共場所反覆關閉。此時可往規則層面處理：在 rules 前段（或 rule-providers 的命中順序）把下列類型放進 DIRECT 或專用 策略群 指向 直連。常見寫法包括：IP-CIDR,10.0.0.0/8,DIRECT、IP-CIDR,172.16.0.0/12,DIRECT、IP-CIDR,192.168.0.0/16,DIRECT 等內部網段，以及 GEOIP,private,DIRECT（以你實際核心與訂閱是否支援為準；mihomo／Clash Meta 行為與欄位請對照自用手冊）。重點是登入前「閘道與熱點分配給你同一網段上的 HTTP」不要被送去境外。若你使用 fake-ip 模式，還要確認內部網域沒有在 DNS 層被替換成節點可解析的假象；這類與 分流 細節、國內外規則骨架可再對照 規則分流實戰主題，但請記得在 公共 WiFi 情境把 直連 的優先順序提得夠高。

步驟三：通過 認證 之後，再啟 TUN 與 系統代理

熱點常在驗證通過的瞬間改變你對外可見的 NAT 或配額，此時最穩的是：確認瀏覽器已能直連公網一個小網站（不經 Clash）後，再依序啟用 系統代理 或 TUN。若你啟 TUN 後又立刻斷線，多半是剛寫入的預設路由與熱點的閘道衝突，可檢查「預設路由是否被核心覆蓋」、「閘道是否仍能 ping」、以及 Clash 日誌是否顯示 DNS 全數超時。與 Allow LAN 或讓手機走筆電代理不同場景的除錯，可參考 Allow LAN 與防火牆排查；該文著重區網入站，本文著重 Captive portal 的出站，兩者互補。

手機、平板也適用同樣邏輯

iOS 與 Android 在連上需登入的 WiFi 時，同樣依賴系統偵測。手機上若安裝了會建立 VPN 或 本機代理 的 App，亦可能讓 認證頁面 不跳出。建議在連上 SSID 時暫關此類服務、完成 Captive portal 後再開。筆電若透過手機熱點上網，則是另一條路徑：行動網路多半沒有圍牆，但若電信商仍有入口頁，同樣先關 Clash 再驗證最乾淨。

常見情況：顯示已登入、仍無法上網

若 認證 畫面顯示成功、但一開 Clash 又變成全面逾時，請分兩層看：一層是熱點只放行特定埠或速率極低，導致你的節點 TLS 交握失敗，這與 分流 是否正確無關；另一層是 DNS 全被導到 fake-ip 或遠端，而熱點的 DNS 必須用在地伺服器。可以暫切「僅用訂閱內幾個可信 DNS 測」與「跟隨作業系統 / 跟隨閘道」兩邊比對。此時不必急著大改 分流 檔，先讓一個最簡專用設定檔在該 公共 WiFi 能跑，再回到日常用的 heavy 規則。

實作順序小結

• 最優先：登入熱點前關 系統代理 與 TUN，讓內建 Captive portal 流程跑完。
• 必須開核心時：規則前段讓內部網段、閘道相關名稱 直連，並核對 DNS 與 fake-ip 行為。
• 通過驗證後：先確認直連上網正常，再啟 Clash，必要時在該場域暫用較單純的節點與策略。

結語

與 Allow LAN 或 WSL2 路由一類主題相比，公共 WiFi 的 Captive portal 問題多數不來自節點品質，而來自「在錯的時間讓系統以為已經出了圍牆」或「把該打熱點內的 HTTP 丟到境外」。釐清 系統代理 與 TUN 的管轄範圍後，用先直連、再分流的順序處理，可省下大量在機場櫃檯旁改規則的時間。相較於在論壇撿零碎片段，用持續更新、行為可預期的用戶端與可驗證的規則，通常能讓 分流 在通過 認證 之後穩定接手。

若您需要 Windows、macOS 或行動裝置上安裝與下載的統一入口，可從本站 下載頁面 取得對應平台連結，再依各教學完成訂閱與 分流 設定。