Clash 顯示已連接卻無法上網？DNS 洩漏與 fake-ip 逐步排查
許多用戶遇過這種情況：Clash 介面顯示「已連接」、延遲測試也正常，但瀏覽器就是打不開網頁，或只有部分網站異常。這類問題往往不是「節點壞了」這麼單純，而是系統代理是否生效、DNS 是否繞過了 Clash，以及規則與 fake-ip 搭配是否一致交錯造成。本文提供一套可照做的排查順序，協助您快速縮小範圍。
先確認現象：是哪一種「無法上網」？
開始改設定前，建議先用兩分鐘釐清問題邊界。若只有瀏覽器無法開啟，但同一台電腦上的部分應用程式仍可連線，常見原因是該應用程式沒有走系統代理，或瀏覽器安裝了獨立的代理／DNS 外掛。若所有應用幾乎都失敗，則要優先懷疑系統代理未開啟、TUN／防火牆衝突，或本機 DNS 仍指向電信／路由器，導致解析結果與 Clash 規則不一致。
另外請留意：Clash 顯示「Connected」多半代表本機與 Clash 程序之間的狀態，不等同「您選的節點一定能連上目標網站」。若日誌出現 dial tcp、i/o timeout、TLS handshake 等錯誤，仍要先換節點或確認機場線路。本文假設您已試過更換節點，問題仍存在或呈現「時好時壞」。
建議排查順序（由快到慢）
總覽：請依序執行
- 確認代理模式與出口策略組（是否誤選
DIRECT／REJECT） - 用「全域模式」做二分法：全域正常則偏向規則優先順序問題
- 檢查系統是否真的把 DNS 交給 Clash（避免 DNS 洩漏到路由器）
- 檢視
dns區塊：enhanced-mode、nameserver與fake-ip是否與規則匹配 - 必要時暫時改為
redir-host或調整fake-ip-filter驗證假設
第一步：模式與策略組，比您想的更容易誤觸
在 Rule 模式下，請打開用戶端的 Proxies／策略組 頁面，確認主出口（常見名稱如「♻️ 自動選擇」「🚀 節點選擇」）沒有停在 DIRECT 或 REJECT。有些訂閱會把「漏網之魚」策略組預設到奇怪的位置；若您曾手動調整過策略鏈，也可能造成看似連上、實際上關鍵域名被判斷為直連或拒絕。
快速二分法
暫時切換到 Global（全域）並選定一個可用節點。若此時瀏覽器立刻恢復正常，代表節點大致沒問題，應回到 Rule 檢查規則優先順序與策略組指向。
第二步：規則優先順序——上面的規則先匹配
Clash 的規則清單是由上而下匹配，命中第一條即停止。當您遇到「只有特定網站打不開」時，請在 Logs／Connections 觀察該域名最終是 DIRECT 還是 PROXY。若您認為它應該走代理，卻顯示直連，很可能是更上方有一條更寬鬆的規則先命中（例如錯誤的 GEOIP、過大的 DOMAIN-SUFFIX、或訂閱附帶的廣告攔截規則）。
實務上建議：先鎖定問題域名，對照規則列表從頂端往下找第一個可能命中的條目；必要時在測試環境暫時註解可疑規則驗證。請記得，規則調整屬於「精準手術」，每次只改一處，改完立即用瀏覽器復現，避免同時動 DNS 與規則導致無法回推原因。
第三步：什麼是 DNS 洩漏？為何會讓您「已連接卻上不了網」？
簡單說：瀏覽器造訪網站前需要把域名解析成 IP。若系統或瀏覽器仍向路由器／電信商 DNS查詢，而 Clash 的規則卻基於「應由 Clash 處理的解析結果」來分流，就可能出現解析與實際連線不一致：介面顯示正常，但流量走向與您預期不同，表現為無法開啟、頻繁重定向、或只有 HTTPS 網站異常。
請在作業系統的網路設定中檢查 DNS：理想情況下，使用 Clash 作為本機代理時，應讓系統 DNS 指向本機（常見為 127.0.0.1 或 Clash 用戶端指定的 DNS 監聽位址），或由用戶端啟用「覆寫 DNS」類選項，避免應用繞過。若您開啟 TUN 模式，也要確認沒有與其他 VPN／安全軟體同時搶佔虛擬網卡或 DNS 轉發。
注意
某些公司網路會強制網頁認證（Captive Portal）或注入 DNS。此時若強制全走代理，可能出現「能連上 Clash、但一般網頁不正常」。需先完成入口認證或暫時直連。
第四步：認識 dns.nameserver 與 fallback
Clash／Clash Meta 的 dns 區塊中，nameserver 用於一般查詢。建議至少準備一組可信的上游 DNS（例如支援 DoH／DoT 的服務），並避免只依賴可能被污染或攔截的線路。若設定檔支援 fallback，請理解其語意：當主要 nameserver 回傳可能被認為「不可信」的結果時，核心會再向 fallback 求證。若您把所有上游都設成同一類型或同一運營商，遇到異常時反而難以互相驗證。
實務建議：nameserver 清單精簡但多元；不要在未理解選項含義時同時開啟過多實驗性 DNS 功能。修改後請在 Logs 觀察 DNS 查詢是否仍從非預期路徑離開本機。
第五步：fake-ip 不是萬靈丹——常見踩雷點
當 enhanced-mode 設為 fake-ip 時，Clash 可能對部分域名回傳虛擬 IP 位址，再在內部映射回真實域名，以提升匹配效率。這在大多數瀏覽器場景可行，但若遇到下列情況，就容易出現「連上了但打不開」「特定 App 異常」：
- 某些應用程式自行快取 DNS，拿到 fake-ip 後嘗試繞過 Clash 直接連線
- 區網裝置、NAS、或內網域名被誤判，需要透過
fake-ip-filter讓其走正常解析 - 與
sniffing／TUN 搭配不當時，日誌看似正常但實際握手失敗
排查時可採用對照實驗：在備份設定後，暫時將 enhanced-mode 改為 redir-host（或依您核心版本支援的等價模式）並重載設定。若問題立刻消失，即可高度懷疑與 fake-ip 相容性相關，接著再用 fake-ip-filter 精準放行問題域名或應用相關後綴，而不是永久關閉 fake-ip。
小結
fake-ip 的目標是效能與規則匹配；若您的環境有「非瀏覽器應用」「內網解析」「特殊安全軟體」，請優先檢查 filter 與 TUN 搭配，而不是先怪節點。
第六步：用外部工具驗證 DNS 是否如您預期
完成本機設定後，建議用瀏覽器開啟知名的 DNS 洩漏檢測頁面（搜尋關鍵字「DNS leak test」即可找到多種工具）。重點不是記分高低，而是觀察出現的 DNS 供應商與地理位置是否仍為您的住宅 ISP／路由器供應商。若始終顯示 Clash 上游或預期地區，代表本機側大致成功把查詢納入代理體系。
同時請在 Clash 的 Connections／Logs 同步觀察：當您造訪問題網站時，對應連線是否走到正確策略組。兩邊證據交叉比對，通常能快速分辨是「純 DNS」還是「規則＋DNS 組合」問題。
第七步：瀏覽器正常、其他程式不行？
這通常與系統代理的覆蓋範圍有關。瀏覽器會讀取系統代理，但不少遊戲啟動器、命令列工具、或自帶網路堆疊的程式不會。若您已確認 DNS 與規則無誤，仍建議在理解風險的前提下評估 TUN 模式（需安裝服務／驅動與管理員權限），讓流量在系統層被納管。相關基礎步驟可參考本站 Clash for Windows 安裝與設定教學 中的 TUN 說明。
最後：可列印的自檢清單
- 策略組未停在
DIRECT／REJECT；Global測試可區分規則問題 - 規則由上而下匹配；用 Logs 找到「第一條命中」而非憑印象
- 系統 DNS 未悄悄指向路由器；必要時覆寫為本機或由用戶端接管
nameserver可信且具備備援邏輯；避免單一污染源fake-ip異常用redir-host對照；長期用fake-ip-filter精準放行- 外部 DNS 洩漏測試與 Clash Logs 交叉驗證
若您依照上述順序仍無法排除，請保留最小可復現步驟（作業系統版本、用戶端種類、是否 TUN、問題域名範例、相關日誌片段）再向機場客服或社群求助，會比只說「連不上」更快獲得有效回覆。
需要穩定、整合度較高的用戶端與預置規則時，可前往 Clash 下載頁面 取得經整理的版本，減少手動拼湊設定檔的時間成本。