先判斷「已連線」具體代表哪一層
Clash 用戶端中的「系統代理已啟用」、「VPN 已連線」或「核心執行中」，只代表本機代理入口已啟動，不表示遠端節點可用，也不表示瀏覽器流量已進入 Clash。完整鏈路至少包含應用程式、系統代理或 TUN、mihomo 核心、規則比對、DNS、代理節點與目標網站七個環節。任何一層中斷，介面上的開關都可能仍顯示為開啟。
排查時不要同時修改節點、DNS、規則與 TUN。一次只處理一層，並在每個步驟保留可重現的測試結果。建議準備三個目標：一個本地路由器位址、一個可直接連線的網站，以及一個需要透過代理策略存取的網站。如此即可快速判斷問題位於本地網路、直連鏈路還是代理鏈路。
用四種現象縮小範圍
| 現象 | 優先檢查 | 常見故障點 |
|---|---|---|
| 所有網站都無法開啟 | 本地連接埠、系統代理、TUN | 代理連接埠未監聽，或流量被錯誤接管 |
| 直連網站能開啟，代理網站失敗 | 節點、訂閱、策略群組 | 節點失效，或策略群組選中了 DIRECT |
| IP 位址可存取，網域名稱卻無法開啟 | DNS | 解析逾時、DNS 劫持或 Fake-IP 鏈路不完整 |
| 瀏覽器可用，其他應用程式失敗 | TUN、應用程式代理支援 | 應用程式不讀取系統代理，或 UDP 未被接管 |
第一步：確認節點、訂閱與策略群組確實可用
先進入用戶端的代理或策略頁面，找出目前實際承擔流量的策略群組。許多設定的頂層群組名稱是「節點選擇」、「Proxy」或「GLOBAL」，下方還會再套一層自動選擇、故障轉移或地區分組。首頁顯示某個節點名稱，不代表最終出口一定是它；應逐層開啟策略群組，確認鏈路中沒有誤選 DIRECT、REJECT，或選到已失效的子策略群組。
不要只看延遲數字
延遲測試通常會存取設定中的測試 URL。顯示 80 ms 或 200 ms，只能代表該測試當下收到回應。目標網站的連線仍可能因 TLS 交握、線路壅塞、伺服器限流或 UDP 支援差異而失敗。排查時手動選擇一個已知穩定的節點，連續存取兩個不同網域，再觀察連線記錄。
- 延遲顯示「逾時」：先切換到另外兩個不同地區的節點，排除單一節點故障。
- 所有節點同時逾時：檢查本機基礎網路、訂閱期限與節點伺服器的網域解析。
- 延遲正常但網頁載入失敗：繼續查看策略比對、DNS 與 TLS 錯誤，不要反覆測速。
- 只有 UDP 應用程式失敗：節點協定或伺服器可能沒有提供可用的 UDP 轉發，也可能是 TUN 設定未接管 UDP。
重新擷取訂閱並核對更新時間
訂閱過期不一定會顯示為「匯入失敗」。用戶端可能繼續保留舊設定，介面仍能顯示節點清單。進入「設定」→「訂閱」或「Profiles」頁面，手動執行更新，記錄更新後的時間與回傳資訊。若狀態碼為 401 或 403，應檢查訂閱權限；若發生逾時，先用直連網路開啟訂閱網域；若回傳內容無法解析，可能取得的是登入頁、提示頁或格式不相容的文字。
更新後確認目前啟用的是新設定，而不是清單中同名的舊副本。部分桌面用戶端需要在設定清單中再次點選啟用。若設定使用 provider，也應檢查 provider 的更新時間，因為主設定更新成功不代表遠端節點集合也已同步。
第二步：檢查本地代理連接埠與系統代理
桌面端最常見的故障點是：核心監聽在某個連接埠，作業系統或瀏覽器卻指向另一個連接埠。常見設定會使用 HTTP 連接埠 7890、SOCKS5 連接埠 7891，或只啟用一個 mixed-port，例如 7890。連接埠號並非固定標準，必須以目前設定與用戶端設定頁顯示的值為準。
先繞過瀏覽器，直接測試本地連接埠
在 Windows PowerShell、macOS 終端機或 Linux shell 中，可以使用 curl 指定代理。以下假設 mixed-port 為 7890：
curl -I --max-time 10 -x http://127.0.0.1:7890 https://example.com
curl -I --max-time 10 --proxy socks5h://127.0.0.1:7891 https://example.com如果回傳 HTTP 回應標頭，表示應用程式到本地代理、代理到目標網站的基本鏈路已連通。若立即出現「Connection refused」，通常是連接埠未監聽或輸入錯誤；等待 10 秒後逾時，則繼續查看節點與 DNS；如果 HTTP 代理成功而 SOCKS5 失敗，請核對設定是否確實啟用了 socks-port。
網路正常時，本地代理請求通常會在 0.2 至 3 秒內回傳回應標頭。這個範圍不是節點品質標準，但若每次都穩定卡到 10 秒後逾時，就應查看核心記錄，而不是繼續等待瀏覽器自行恢復。
核對系統中的實際代理位址
- Windows 11 24H2：開啟「設定」→「網路和網際網路」→「代理」，檢查「使用代理伺服器」的位址與連接埠。常見位址是 127.0.0.1，連接埠應與用戶端一致。
- macOS 15：開啟「系統設定」→「網路」→目前網路→「詳細資訊」→「代理」，檢查網頁代理與安全網頁代理。由用戶端自動管理時，不要再手動填寫另一組連接埠。
- Android 15：Clash 類用戶端通常透過系統 VPN 介面接管流量，不需要在 Wi-Fi 的手動代理中再次填寫 127.0.0.1。
- 瀏覽器：確認沒有同時啟用代理擴充功能。擴充功能指向舊連接埠時，會覆蓋或繞過系統代理。
如果關閉系統代理後可以正常直連，開啟後所有請求卻立即失敗，表示故障點很可能位於本地代理連接埠之後。此時查看記錄中是否出現連線遭拒、交握逾時或找不到策略群組。若關閉系統代理後仍無法存取任何網站，應先修復 Wi-Fi、網路線、閘道或系統 DNS，而不是繼續調整 Clash。
第三步：將 DNS 問題與代理問題分開排查
「IP 可連線、網域名稱無法連線」是典型的 DNS 線索。Clash Meta，也就是目前常見的 mihomo 核心，可以在本地執行網域解析、規則比對與 Fake-IP 對映。只要用戶端漏掉 DNS 劫持、上游解析無法連線或 Fake-IP 流量接管中的任何一環，就可能出現瀏覽器持續轉圈、部分應用程式提示網路無法使用的情況。
先確認網域名稱是否能取得解析結果
在終端機執行系統解析測試。Windows 可使用 nslookup example.com，macOS 與 Linux 可使用 dig example.com。如果設定採用 Fake-IP 模式，取得 198.18.0.0/16 範圍內的對映位址可能是正常現象；這個位址需要繼續進入 mihomo，由核心還原網域名稱並執行規則。看到 198.18.x.x 不應直接判斷為解析錯誤。
真正需要注意的是查詢持續逾時、回傳 SERVFAIL，或系統取得 Fake-IP 後流量沒有進入 TUN。若關閉 TUN 後系統仍快取 Fake-IP，網頁可能暫時無法存取。可先停用代理、清除系統 DNS 快取，再重新啟動核心與 TUN。
核對設定中的 DNS 結構
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
fallback:
- tls://8.8.8.8:853這段範例展示的是欄位關係，不應未經判斷就覆蓋現有訂閱。連接埠 1053 只是常見的本地監聽值。排查時確認 dns.enable 已啟用、監聽連接埠未被其他程式佔用，且上游位址在目前網路中可連線。若設定引用網域形式的 DoH 服務，還要確保用於解析該網域的 bootstrap 路徑可正常運作，避免出現「解析 DNS 伺服器網域又依賴該 DNS 伺服器」的循環。
當記錄中持續出現 DNS timeout 時，可暫時切換到設定提供者建議的另一組上游進行比對。只修改 nameserver，節點、規則與 TUN 保持不變。若切換後立即恢復，問題集中在原本的上游或其存取路徑；若仍然失敗，則檢查 53 連接埠劫持、防火牆與 TUN 路由。
第四步：排除 TUN、系統代理與其他 VPN 的衝突
系統代理主要影響會主動讀取代理設定的應用程式。遊戲、命令列程式、部分商店應用程式與 UDP 流量可能會忽略它。TUN 模式透過虛擬網卡與路由接管更多流量，但也更容易與企業 VPN、虛擬機器網路、容器網路、加速器及安全軟體發生衝突。
用開關組合定位流量接管層
- 先關閉 TUN，只啟用系統代理。測試瀏覽器與前面的 curl 指令。
- 若瀏覽器恢復正常，表示節點與 HTTP 代理大致正常，問題集中在 TUN 路由、DNS 劫持或權限。
- 再關閉系統代理，只啟用 TUN。測試瀏覽器與一個不讀取系統代理的應用程式。
- 若兩者分開啟用都正常、同時啟用卻異常，請檢查用戶端是否重複設定路由，或是否存在兩套 DNS 接管。
- 最後恢復用戶端建議的組合，不要長期依賴反覆切換來掩蓋設定錯誤。
mihomo 的 TUN 設定常見欄位包括 enable、stack、auto-route、auto-detect-interface 與 dns-hijack。不同系統與用戶端支援的 stack 選項可能有所差異。若目前使用 gVisor 時路徑異常，可在用戶端支援的前提下切換至 system 進行比對；修改後需要完整重新啟動核心，而不只是關閉再開啟系統代理。
在 Windows 上啟用服務模式或 TUN 後，虛擬網卡與路由寫入需要相應權限。可在「設定」→「網路和網際網路」→「進階網路設定」中確認虛擬介面卡狀態。macOS 首次使用通常需要在「系統設定」→「一般」→「登入項目與延伸功能」→「網路延伸功能」中允許相關延伸功能。Android 則應確認狀態列有 VPN 標誌，並在系統 VPN 頁面檢查是否有另一個常駐 VPN 佔用唯一介面。
檢查預設網卡識別
筆記型電腦從有線網路切換至 Wi-Fi、連線到手機熱點或喚醒後，預設出口可能會改變。若 auto-detect-interface 未正確識別目前網卡，TUN 流量可能被送回虛擬介面，形成路由迴圈。典型表現是啟用 TUN 後延遲測試全部逾時，關閉後立即恢復。此時先重新啟動核心；仍未恢復時，斷開不使用的虛擬網卡與舊 VPN，再重新建立網路連線。
第五步：從記錄確認規則、交握與連線錯誤
前四步仍未定位問題時，應將記錄層級暫時調整為 info 或 debug。常見用戶端入口位於「設定」→「記錄層級」或「設定」→「參數設定」→「核心」。開啟記錄後只重現一次失敗請求，再立即查看對應網域，不要讓測速與背景更新產生大量無關記錄。
重點辨識這些記錄線索
| 記錄線索 | 含義 | 下一步 |
|---|---|---|
| match DIRECT | 請求被規則判定為直連 | 核對規則順序、規則集更新狀態與目標網域 |
| match REJECT | 請求遭拒絕規則攔截 | 檢查廣告攔截或自訂規則 |
| connection refused | 目標連接埠主動拒絕連線 | 切換節點，檢查伺服器端連接埠與協定參數 |
| i/o timeout | 連線或讀取超過時限 | 區分 DNS、節點伺服器與目標網站的逾時 |
| no such host | 網域名稱解析失敗 | 檢查 nameserver、網路權限與 DNS 劫持 |
| TLS handshake timeout | TLS 交握未能在時限內完成 | 測試其他節點，檢查時間、MTU 與線路品質 |
規則會按照由上而下的順序比對，通常命中第一條後停止。自訂的 DOMAIN-SUFFIX、IP-CIDR 或程序規則若放在通用規則之前，可能會將目標錯誤地送往 DIRECT 或 REJECT。排查時可以暫時選擇全域模式並指定一個可用節點：若全域模式恢復正常，節點與基礎代理鏈路大致正常，問題更可能位於規則或 provider；若全域模式仍然失敗，則繼續檢查節點、DNS 與 TUN。
全域模式只適合短時間比對，不適合作為最終修復方案。確認問題後，應回到規則模式，修正規則集來源、策略群組名稱或自訂覆寫。設定中的策略名稱必須與規則引用完全一致，大小寫、空格與符號差異都可能導致載入錯誤或回退行為。
最後按照固定順序重新測試，避免「碰巧恢復」
完成修改後，先停止核心 5 秒，再重新啟動。接著依照「本地網路、DNS、本地代理連接埠、節點、規則、TUN」的順序驗證。不要只看某個網頁是否開啟，還應測試直連與代理兩類網域、瀏覽器與非瀏覽器應用程式，以及切換 Wi-Fi 後的表現。
- 關閉 Clash，確認基礎網路可以存取本地閘道與直連網站。
- 啟動核心，確認設定載入完成，沒有 YAML 欄位或 provider 錯誤。
- 指定 127.0.0.1 與目前的 mixed-port 執行 curl 測試。
- 確認訂閱更新時間、目前節點與頂層策略群組的選擇。
- 檢查網域解析結果與 DNS 記錄，區分正常 Fake-IP 與實際逾時。
- 先使用系統代理重新測試，再單獨啟用 TUN，確認衝突出現在哪種組合。
- 恢復規則模式，從記錄確認請求命中了預期策略。
如果故障只在公司、校園或飯店網路出現，還應考慮該網路是否限制 UDP、特定連接埠或加密 DNS。使用手機熱點進行一次比對最有效：同一台裝置、同一份設定在熱點上正常，卻在原本的網路中失敗，就能將範圍縮小至區域網路出口、認證頁面或網路策略。完成認證後再啟動 Clash，也能避免飯店 Wi-Fi 的登入頁面被代理規則攔截。
這套順序的核心是先驗證最短鏈路，再逐層增加接管能力。節點、DNS、系統代理與 TUN 都可能造成相似的「已連線卻無法上網」，但測試結果並不相同。保留每個步驟的連接埠、時間、記錄與開關組合，通常比反覆重新安裝用戶端更快找到真正的故障點。