Clash 節點全紅？延遲測試、UDP 與 DNS 逐項排查步驟

先釐清：「節點全紅」與延遲測試到底在量什麼

在 Clash、Clash Verge、FlClash 等圖形介面中，常見的延遲測試（或稱延遲檢查、Latency test）多半會對每個代理節點發起一輪可設定的探測請求，再把結果顯示成毫秒數或逾時。當所有節點同時顯示失敗、逾時或「全紅」時，使用者很容易直覺認定「線路全部掛了」；但實務上，這也可能是本機 DNS 解析異常、探測網址被規則導向錯誤群組、UDP 被環境擋住，或單純健康檢查網域在您所在網路被干擾所致。

因此第一步請先問自己兩個問題：第一，不跑延遲測試時，一般網頁或通訊軟體是否仍可用？若實際上網正常，只是介面測速全掛，問題多半在「測速鏈路」而非節點本體。第二，您是否剛切換過 DNS 模式、fake-ip、TUN，或換過訂閱／規則？這些變更會同步影響探測流量怎麼走。釐清後再往下排查，能避免在錯誤的假設上反覆重裝。

請記得：代理用戶端只負責依設定檔轉送流量，並不提供節點服務。您仍需透過合法合規的管道取得訂閱或設定檔，並自行確認使用情境符合當地法規與服務條款。以下步驟假設您已能連上基礎網際網路（未開代理時可開啟搜尋引擎），若連底層網路都不通，請先檢查路由器、網卡驅動或 ISP 狀態。

第一步：核心是否運行、訂閱是否載入、目前選中的群組

在懷疑 DNS 或 UDP 之前，請先完成最基本的狀態確認。請確認代理核心（如 Mihomo／Clash Meta）已啟動且無反覆崩潰，設定檔已成功載入，且介面上看得到節點清單而非空白。若節點列表為空，問題在訂閱或設定檔合併，與延遲數字無關，應回到訂閱更新與 YAML 語法檢查。

接著確認模式：Rule、Global、Direct 是否與您預期一致。若您使用規則分流，請留意策略群組內目前選中的節點名稱；有些介面會記住「上次選擇」，若該節點已從訂閱移除或改名，可能導致看似連線但實際指向無效後端。此時可手動切換到另一個節點再做一次延遲測試，排除單點設定殘留。

最後請確認系統代理或 TUN是否已依平台正確開啟。僅「開著 App 視窗」但未把流量交給核心，測速與實際上網都會表現異常。若您剛從「僅本機埠」切換到「系統代理／TUN」，請等待數秒讓路由表或 VPN 槽位建立完成，再重試延遲測試，避免在過渡期誤判為全紅。

第二步：DNS 與解析鏈——fake-ip、redir-host 與 DoH

許多「節點全紅」案例，追根究柢是DNS 請求沒有穩定解析到測速目標，或解析結果與 fake-ip 映射不一致。Clash 系核心常見的 fake-ip 模式能加速體感連線，但若規則或 DNS 設定與實際使用情境不匹配，可能出現「部分網站正常、探測網址永遠失敗」的割裂現象。建議您在理解風險的前提下，暫時切換到 redir-host 或讓域名解析走較可預測的路徑，觀察延遲測試是否恢復；若恢復，即可把問題收斂到 DNS 與規則互動，而非節點供應商。

若您啟用了 DNS over HTTPS（DoH）或 DNS over TLS，請確認上游位址可從目前網路連線，且未被公司防火牆或 ISP 攔截。可嘗試暫時改回傳統 UDP DNS 或使用另一組公共解析做 A／B 測試（請自行評估隱私與合規性）。同時檢查作業系統層是否啟用私人 DNS（Android）或第三方過濾工具，這些常會與核心內 DNS 鏈路打架。

另一個易忽略點是分流規則是否把探測網域導向錯誤策略。部分訂閱附帶的規則會將特定測速或 CDN 網域寫入不同群組；若該群組內節點全數不可用，介面就會呈現全紅，但實際瀏覽其他已正確分流的網站仍可能正常。此時應檢視設定檔中與探測 URL 相關的規則命中情形，必要時在除錯階段將探測網域暫時置前為走代理或走直連，依環境驗證。更多 DNS 與規則觀念也可參考本站 教學文件 相關章節。

第三步：UDP 與 STUN——什麼時候會扯進來

一般網頁與 API 多以 TCP 為主，延遲測試也多以 TCP 連線或 HTTP(S) 探測實作；因此「全紅」未必代表 UDP 故障。但若您的使用情境包含語音通話、部分遊戲、WebRTC，或某些客製測速元件改用 UDP／QUIC 類行為，則需額外檢查 UDP 是否被路由器、公司網路或本機防火牆阻擋。

STUN（Session Traversal Utilities for NAT）常用於協助點對點連線穿越 NAT，瀏覽器或通訊軟體可能會發起 STUN 請求以探測對外 IP 與連線路徑。若您看到相關流量異常，請先確認 TUN 模式是否已涵蓋該程式、規則是否誤將 STUN 伺服器導向錯誤出口，並檢查路由器是否啟用過於嚴格的 ALG 或對 UDP 的限制。若只在特定 App 失敗、其餘正常，較可能是應用程式自身的 UDP 路徑問題，而非整批節點故障。

實務上可採取的對照實驗包括：在相同網路下關閉其他 VPN 或安全軟體後重試、暫時改用另一組節點協定（若服務商提供）、或在日誌中搜尋 UDP、timeout、reject 等關鍵字。請避免為了「強行打通 UDP」而關閉所有安全機制；應在可接受的風險範圍內逐步放寬規則。

第四步：健康檢查、url-test 與探測 URL

在設定檔層級，策略群組常透過 url-test、fallback 或類型相近的選擇器，依健康檢查結果自動挑節點。此處的「健康」定義於設定中的 url、interval、timeout 與容忍度參數。若探測網址在您所在網路被干擾、TLS 握手失敗，或間隔太短導致頻繁判定失敗，介面可能長期顯示劣化或切換失敗，外觀就像節點全紅。

建議您確認：探測 URL 是否為穩定可達的 HTTPS 端點；逾時是否過於激進；是否在行動網路與 Wi-Fi 之間切換時未給足重試時間。若服務商提供建議的測速或健康檢查網址，優先採用以降低誤判。對於手動延遲測試按鈕，亦請留意圖形介面是否使用與設定檔相同的探測目標；若不同，可能出現「設定檔健康檢查過了、介面按鈕卻全紅」的落差。

第五步：系統代理、TUN、防火牆與安全軟體

即使節點與 DNS 都正常，若本機出站連線被擋，延遲測試仍會全數逾時。Windows 上請檢查 Defender 防火牆是否允許核心程式與用戶端 GUI 出站；macOS 請留意 Little Snitch 類工具或企業 MDM 政策；Linux 桌面則可能受 nftables／iptables 或 Docker 網路影響。若您剛安裝系統更新或安全套件，優先檢視是否出現新的阻擋規則。

若您使用公司或校園網路，HTTP(S) 以外的連線、特定 DNS 或已知測速網域可能被中間設備攔截，造成全面逾時。此時可嘗試改用手機熱點做對照實驗：若熱點下立即恢復，表示瓶頸在原始網路環境而非 Clash 設定檔本身。

跨平台快速對照

在 Windows 上，請同時確認是否安裝了多個代理或 VPN 搶占系統槽位，以及 WSL2 與主機路由是否衝突（可延伸閱讀本站 WSL2 路由相關文章）。在 macOS 上，留意系統「代理」設定是否被其他工具覆寫。在 Android 上，私人 DNS、省電與背景限制常影響長時間連線與 DNS 解析；在 iOS 上，Network Extension 權限與描述檔策略亦可能限制特定流量。此處不重複單平台長篇步驟，但核心原則一致：先讓「核心—系統—網路」這條鏈路無阻擋，再談節點品質。

可勾選檢查清單

當您需要快速掃一輪，可依序自問：訂閱是否成功載入且節點非空？目前模式與策略群組選擇是否合理？DNS 模式與規則是否讓探測網址走預期路徑？健康檢查與手動測速的 URL 是否過於嚴苛或被干擾？UDP／STUN 是否屬於當前故障場景？本機與網路防火牆是否放行？若以上皆已檢查，再進入供應商狀態與日誌層級。

• 基線：核心運行、設定檔無語法錯誤、節點列表存在。
• DNS：fake-ip／redir-host、DoH、私人 DNS 對照實驗。
• 探測：健康檢查 URL、interval、timeout 與介面測速目標一致。
• UDP／STUN：僅在相關應用失敗時優先排查。
• 環境：防火牆、熱點對照、公司網路限制。

結語

Clash 延遲測試與健康檢查是除錯利器，但它們量到的是「探測封包在當前規則與 DNS 下的體驗」，不等同於您關心的每一種真實流量。遇到節點全紅時，先把問題拆成「實際上網是否受影響」與「僅測速失敗」兩類，再依序處理 DNS、探測 URL、UDP／STUN 與本機防火牆，通常能顯著縮短繞圈時間。把本文順序記下來，下次遇到類似狀況時，您會更快分辨是環境、設定檔還是線路本身需要調整。

相較於零散論壇截圖，使用固定來源的用戶端與文件能降低版本不一致造成的誤判。若您正在找可長期使用的 Clash 系用戶端與對應說明，建議從本站彙整的下載入口取得安裝檔，再依教學完成訂閱與進階設定。