Clash 節點逾時無法連線：從網路入口到代理鏈路的排查順序

Clash 顯示節點逾時，只能表示某次連線或延遲測試未在限定時間內取得有效回應，不能直接證明節點本身已失效。問題可能出現在本地網路入口、訂閱設定、節點伺服器、策略組選擇、DNS 解析、系統代理、TUN 路由或防火牆的任一層。若同時修改多個設定，原始故障點可能被新變數掩蓋，反而拉長排查時間。

建議沿著連線路徑逐層驗證：先確認裝置能直接連上網路，再確認設定確實更新，接著檢查節點與協定，然後核對代理模式和規則命中情況，最後處理 DNS、TUN、連接埠占用與安全軟體。每完成一步都保留結果，就能將「所有網站都打不開」縮小為明確的網路層、設定層或轉發層問題。

一、先區分逾時發生在哪一層

「逾時」不是單一錯誤。客戶端介面中的延遲測試、瀏覽器載入失敗與日誌中的連線逾時，可能測試的是不同路徑。部分客戶端會使用指定的 HTTP 或 HTTPS 位址測量延遲，這類測試包含 DNS、TCP 建立連線、TLS 交握與 HTTP 回應流程，並不等同於 ICMP Ping。測試位址暫時無法連線時，節點仍可能能夠轉發其他請求。

常見現象與初步判斷

• 所有節點同時逾時：優先檢查本地網路、測試位址、客戶端核心、系統時間、防火牆與網路介面，不要先逐一更換節點。
• 只有一個節點逾時：較可能是節點伺服器、連接埠、協定參數或線路狀態異常，可使用同一訂閱中的其他節點進行對照。
• 延遲測試正常但網頁打不開：重點檢查系統代理是否啟用、瀏覽器是否繞過代理、策略組是否選錯、規則是否命中 DIRECT，以及 DNS 是否回傳異常結果。
• 瀏覽器可用但其他應用程式無法使用：瀏覽器可能讀取了系統代理，而目標應用程式可能直接連線、使用獨立代理設定，或需要 TUN 模式接管。
• 網域打不開但 IP 可連線：優先排查 DNS。同時檢查作業系統 DNS、Clash DNS 模組、加密 DNS 的可達性與 fake-ip 行為。
• 啟用 TUN 後整個網路中斷：通常與預設路由、介面識別、權限、其他 VPN、虛擬網卡或 DNS 劫持衝突有關。

還應區分客戶端介面與實際核心狀態。圖形客戶端負責設定管理與系統整合，Clash Meta（目前通常以 mihomo 名稱維護）等核心則負責規則比對、協定連線與轉發。介面仍在執行，不代表核心已成功啟動。若日誌出現設定解析失敗、建立監聽連接埠失敗或權限錯誤，應先恢復核心運作，再測試節點。

二、確認本地網路入口與系統基礎狀態

關閉系統代理並暫停 TUN 後，直接造訪一個平時穩定的網站。如果直接連線也失敗，Clash 並不是目前唯一的變數。先檢查 Wi-Fi 是否完成驗證、有線網路介面是否取得位址、手機熱點是否能連上行動網路，以及公司或校園網路是否需要網頁驗證。公共網路的驗證頁通常要求先直接連線開啟，代理或加密 DNS 可能阻止驗證頁正常顯示。

1. 暫時退出其他 VPN、網路加速器、封包擷取工具與虛擬網卡軟體，避免多個程式同時修改預設路由或 DNS。
2. 重新連線目前的網路，確認系統取得有效的 IP 位址、預設閘道與 DNS 伺服器。
3. 檢查裝置日期、時間與時區。時間偏差過大可能導致 TLS 憑證驗證失敗，表現為訂閱更新失敗或 HTTPS 連線異常。
4. 分別測試家用寬頻與手機熱點。如果同一份設定在熱點可用、寬頻不可用，問題較接近路由器、電信業者路徑或區域網路策略。
5. 重新啟動客戶端後查看核心啟動日誌，確認 HTTP、SOCKS 或 mixed 監聽連接埠已建立。

切換網路後，舊介面與舊路由可能暫時保留。尤其是裝置從有線網路切換至 Wi-Fi、從公司網路切換至熱點後，TUN 自動識別的出口介面可能尚未更新。此時先關閉 TUN，等待系統路由穩定後再重新啟用。若客戶端提供「重新啟動核心」或「重新載入設定」，優先使用這些操作，不必反覆匯入同一份訂閱。

三、檢查訂閱狀態與設定是否真正生效

訂閱更新成功的提示只代表客戶端完成某個下載動作，不一定表示下載內容是有效的 Clash 設定。訂閱位址過期、伺服器回傳登入頁、回應被網路驗證頁取代，或訂閱格式與目前客戶端不相容，都可能導致節點清單為空或繼續使用舊快取。

先查看訂閱更新時間、設定檔名稱與節點數量。若節點名稱、策略組與規則和伺服器近期變更不一致，應手動更新並查看日誌。出現 YAML 解析錯誤時，常見原因包括縮排層級錯誤、冒號後缺少空格、字串中的特殊字元未正確加上引號，以及設定引用了目前核心不支援的欄位。

訂閱檢查順序

1. 確認訂閱位址仍處於有效狀態，帳戶對應的服務尚未到期或遭到暫停。
2. 使用直接連線網路更新一次；若直接連線無法更新，再透過現有可用代理嘗試，判斷連線至訂閱伺服器的路徑。
3. 核對回應內容是否為設定文字，而不是 HTML 登入頁、錯誤頁或閘道驗證頁面。
4. 確認客戶端實際啟用的是剛更新的設定，而不是歷史設定、範例設定或另一份本機檔案。
5. 重新載入設定後檢查策略組選擇，因為組內節點名稱變更時，舊選擇可能會被重設或指向無法使用的項目。

不要在公開日誌、截圖或論壇內容中展示完整訂閱位址、節點密碼、UUID、憑證欄位或存取權杖。這些欄位屬於連線憑證。排查時通常只需保留協定類型、伺服器是否為網域、連接埠範圍、傳輸方式、TLS 狀態與錯誤類別。

如果匯入後核心無法啟動，可以暫時切回上一份能夠載入的設定，確認客戶端與網路環境仍正常，再比較兩份設定的差異。在大幅刪改設定檔前，應保留原始副本。規則集、代理提供者或外部資源下載失敗，也可能讓設定載入停留在錯誤狀態。

四、驗證節點、協定參數與伺服器路徑

確認本地網路與設定正常後，再檢查個別節點。先從同一份訂閱中選擇兩至三個不同地區、不同入口的節點進行測試。如果只有某個節點失敗，可暫時從策略組中排除該節點；如果同一伺服器下的多個連接埠都失敗，可能是伺服器離線、入口網域解析異常或網路路徑受阻。

節點參數必須與伺服器端整體匹配，不能只確認位址與連接埠正確。不同協定還可能依賴密碼、UUID、加密方式、TLS、SNI、ALPN、傳輸層、WebSocket 路徑、gRPC 服務名稱或 Reality 相關參數。任何一個欄位不一致，都可能在 TCP 建立連線後繼續出現交握逾時或連線遭關閉。

從日誌關鍵字定位發生階段

• i/o timeout：連線或讀寫未在限定時間內完成，需要結合目標位址與前一行日誌，判斷是節點入口還是最終目標。
• connection refused：目標主機明確拒絕連線，通常表示連接埠未監聽、服務尚未啟動或中間設備主動拒絕。
• network is unreachable：系統沒有可用路由，常見於介面切換、TUN 路由異常或 IPv6 路徑無法使用。
• no such host：網域未取得有效解析結果，請檢查節點伺服器網域與目前 DNS 連線路徑。
• TLS handshake timeout：TCP 可能已建立，但 TLS 交握未完成，應核對網路品質、SNI、系統時間與伺服器狀態。
• authentication failed：連線憑證或協定參數不匹配，應重新取得訂閱設定，而不是增加逾時時間。

若節點伺服器位址本身是網域，Clash 必須先解析該網域才能建立代理連線。這個過程使用的 DNS 不能依賴尚未建立的同一條代理鏈路，否則會形成啟動依賴。mihomo 設定中的 proxy-server-nameserver 可用來解析代理伺服器網域，但是否需要設定，應依目前 DNS 方案與核心版本決定。

IPv6 也需要單獨驗證。網路可能取得 IPv6 位址，卻沒有穩定的 IPv6 出口；DNS 回傳 AAAA 記錄後，連線會等待無法使用的路徑直到逾時。排查期間可暫時關閉客戶端 DNS 的 IPv6 回應，或切換至明確支援 IPv6 的網路進行對照。確認問題後，再決定保留 IPv4 優先，或修復 IPv6 路由。

五、核對代理模式、策略組與規則命中

節點可用不代表流量一定會經過該節點。Clash 的規則模式會由上而下比對規則，命中後交由對應策略組或動作處理。若目標網域被前面的 DIRECT 規則命中，切換其他代理節點不會改變結果。排查時應開啟連線記錄，查看目標網域、目標 IP、命中規則、出站策略與實際節點。

可以暫時切換至全域代理模式進行對照：若全域模式可用、規則模式失敗，重點檢查規則順序、規則集載入與策略組選擇；若兩種模式都失敗，問題較接近節點、DNS、系統代理或網路入口。測試結束後應恢復原本模式，避免所有流量長期偏離預期規則。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上例展示基本比對順序：特定網域規則在前，區域 IP 規則隨後，MATCH 放在最後處理先前未命中的連線。如果將寬泛的直接連線規則放在特定代理規則之前，後面的規則就不會再執行。使用遠端規則集時，還要確認規則集已下載並完成解析。

策略組名稱同樣必須一致。規則指向的群組必須存在，組內應包含目前可用的節點或其他有效策略組。自動選擇組通常依週期性測試結果選擇節點，但測試位址無法連線時可能產生錯誤判斷。故障排查期間可改為手動選擇一個已通過實際存取驗證的節點，以排除自動策略波動。

六、定位 DNS 解析、fake-ip 與加密 DNS

DNS 故障常見表現是節點測試有結果，但存取網域時持續等待；也可能是瀏覽器顯示名稱解析錯誤，而連線至 IP 位址卻能建立。Clash 的 DNS 模組可接管查詢，並依設定回傳真實 IP 或 fake-ip。系統 DNS、瀏覽器安全 DNS 與客戶端 DNS 同時啟用時，查詢路徑容易分流，因此必須先確認請求實際由哪一方處理。

DNS 排查重點

1. 查看日誌中是否出現 DNS 查詢逾時、名稱不存在或上游伺服器無法連線。
2. 暫時關閉瀏覽器獨立的安全 DNS，讓瀏覽器跟隨系統代理與系統 DNS，減少一條額外路徑。
3. 確認設定中的 nameserver 在目前網路可連線；加密 DNS 的網域本身也需要可用的引導解析。
4. 若使用 fake-ip，請檢查目標應用程式是否相容，並確認區域網路裝置、系統服務與需要真實 IP 的網域都已正確處理。
5. 清除作業系統與瀏覽器的 DNS 快取後重新測試，避免舊記錄掩蓋設定變更。

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

這段設定僅用於說明欄位關係，不應直接套用於所有網路。部分網路無法穩定存取範例上游伺服器，企業網路也可能要求使用內部 DNS 才能解析內部網域。實際設定應選擇目前網路可達且符合使用環境的伺服器。若關閉 IPv6 後恢復存取，表示仍需繼續檢查 IPv6 路由，而不是把所有節點故障都歸因於 DNS。

fake-ip 模式會從保留位址池回傳對映位址，再由核心還原網域並執行規則。某些依賴區域網路探索、硬編碼 DNS 或特殊網路偵測的程式，可能需要加入過濾範圍。redir-host 模式回傳真實解析結果，相容路徑不同，但也更依賴上游解析品質。切換增強模式會改變快取與連線狀態，測試時應重新啟動核心並重新建立連線。

七、檢查系統代理、監聽連接埠與防火牆

瀏覽器通常會讀取系統代理，但部分應用程式只支援自身的 HTTP 或 SOCKS 設定，另有一些程式完全不讀取系統代理。首先確認客戶端顯示的監聽連接埠與作業系統代理設定一致。例如客戶端監聽 mixed 連接埠時，系統代理不能繼續指向舊設定留下的連接埠。

連接埠被其他程序占用時，核心可能啟動失敗或改用其他連接埠。若日誌出現位址已被占用，請退出占用程式或調整監聽連接埠，再同步更新系統代理。不要同時執行兩個都會接管系統代理的 Clash 客戶端，否則可能反覆覆寫代理位址與略過清單。

系統防火牆或端點安全策略可能阻止新核心存取網路、禁止監聽本機連接埠，或限制 TUN 虛擬介面。更新客戶端後，核心可執行檔路徑可能改變，舊的允許規則不一定仍能匹配。應在系統安全設定中核對目前程式路徑與網路權限，並透過日誌確認阻擋時間與測試時間一致。

八、TUN 模式啟用後無法連線的處理方式

TUN 模式透過虛擬網路介面接管更多系統流量，適用於不讀取系統代理的應用程式，以及需要透明轉發的情境。它涉及的路由、DNS 與權限變數比系統代理更多，因此應在一般系統代理已可正常使用後再啟用。若系統代理模式都無法連線，直接啟用 TUN 通常只會增加排查層級。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

mihomo 常見的 TUN 設定包含自動路由與出口介面偵測，但欄位支援情況取決於核心版本與客戶端封裝。啟用後應檢查虛擬介面是否成功建立、預設路由是否產生，以及出口介面是否正確識別。Windows 可能需要相應權限；macOS 可能要求核准網路延伸功能；Linux 則涉及 TUN 裝置、能力權限與策略路由。

若啟用後立即斷網，先關閉 TUN 以恢復基礎網路，然後退出其他 VPN 與虛擬網卡程式。重新啟動核心時，只啟用一個網路接管工具。裝置休眠、切換網路或撥號重新連線後出現問題時，可重新啟動 TUN 或核心，讓系統依目前介面重新建立路由。

還應檢查區域網路略過範圍。印表機、路由器管理頁面與本地服務通常需要直接連線，錯誤接管後可能看似「整個網路都壞了」，實際上只是私有位址被送入代理。同時，過寬的略過範圍又可能讓目標應用程式完全跳過代理。應透過連線日誌判斷流量是否進入核心，不要只依應用程式介面推測。

九、用最少變數完成最終驗證

完成逐層檢查後，使用最小測試組合進行驗證：一份能成功載入的設定、一個手動選擇的節點、一種明確的代理模式、一個穩定的目標網站，以及一種網路入口。先驗證瀏覽器，再驗證需要 TUN 的應用程式。每次只變更一個變數，並記錄變更前後的結果。

1. 關閉 TUN，只啟用系統代理，確認瀏覽器請求出現在連線日誌中。
2. 手動選擇已知可用的節點，避免自動策略組在測試過程中切換。
3. 分別測試規則模式與全域模式，判斷是否為規則命中問題。
4. 查看失敗請求的網域、目標位址、命中規則、策略組、出站節點與錯誤時間。
5. 切換至另一個網路，重複相同測試，判斷故障是否與目前寬頻或區域網路有關。
6. 基礎代理穩定後再啟用 TUN，並檢查虛擬介面、路由與 DNS 是否出現預期變化。

如果需要提交故障資訊，應包含作業系統版本、客戶端版本、mihomo 或其他核心版本、設定來源類型、網路環境、重現步驟，以及經過去識別化處理的日誌片段。日誌應保留錯誤前後的上下文，但移除訂閱位址、驗證資訊與節點憑證。只有「節點逾時」四個字，通常不足以判斷故障層級。

完整排查順序可以歸納為：直接連線網路可用性 → 核心啟動狀態 → 訂閱與設定載入 → 節點協定參數 → 策略組與規則命中 → DNS 查詢鏈 → 系統代理與連接埠 → 防火牆與權限 → TUN 路由。沿著連線鏈路逐步推進，比連續重新安裝客戶端或隨機切換設定，更容易得到可重現的結論。