疑難排解 預計閱讀 12 分鐘

Clash Android 網速慢怎麼排查：節點、線路與本機設定三層定位法

依序檢查節點品質、線路壅塞與手機本機設定，搭配延遲測試、策略組切換及 DNS 檢查，找出 Android 版 Clash 速度變慢的真正原因。

先建立可重複的測速基準

Clash 顯示「已連線」只代表 Android VPN 介面或本機代理已啟動，不代表目前節點具備穩定的傳輸量。排查前應先固定測試條件，否則 Wi-Fi、行動網路、節點和目標網站同時變動，很難判斷速度損失發生在哪一層。

用四組結果區分故障範圍

  1. 關閉 Clash，在目前 Wi-Fi 下測速一次，記錄下載、上傳和閒置延遲。
  2. 保持相同 Wi-Fi，啟動 Clash，選擇目前節點後再測一次。
  3. 維持 Clash 開啟，只切換到其他地區、不同協定或另一條線路，再測一次。
  4. 關閉 Wi-Fi，改用 4G 或 5G，重複測試目前節點與備用節點。

每組測試至少執行兩次，每次持續 20 至 30 秒。測速伺服器、測試時段和目標檔案應保持一致。下載速度也要統一單位：100 Mbps 約等於 12.5 MB/s；瀏覽器顯示 8 MB/s 時，對應的連線速率約為 64 Mbps，不能直接拿 MB/s 與電信業者標示的 Mbps 比較。

測試情境 範例結果 優先判斷
關閉 Clash，Wi-Fi 測速 286 Mbps，延遲 18 ms 本地寬頻基準正常
啟用 Clash，節點 A 22 Mbps，延遲 96 ms 節點或中轉線路可能受限
啟用 Clash，節點 B 173 Mbps，延遲 72 ms 客戶端設定基本正常，節點 A 異常
行動網路，節點 A 118 Mbps，延遲 88 ms 家庭寬頻至節點 A 的路徑可能壅塞

第一層：檢查節點品質與策略組選擇

如果相同網路下只有少數節點速度慢，問題通常位於節點層。常見原因包括節點負載過高、出口頻寬不足、協定握手反覆重傳、訂閱中的節點已失效，以及策略組實際選取的節點與介面預期不一致。

從代理頁確認實際出口

在常見的 Clash Meta Android 客戶端中，可以進入「代理」頁面，展開目前被規則引用的策略組，再查看帶有選取標記的實際節點。不要只看頂層組名。例如規則指向「節點選擇」，而「節點選擇」內部又引用「自動選擇」，最終出口可能由 URL Test 自動切換，不一定是剛才手動點選的地區。

延遲測試出現 80 ms、95 ms、110 ms 這類接近的結果時，不應只選最低的一個。連續測試三輪；如果某節點分別為 72 ms、310 ms、逾時，代表抖動明顯；另一個節點穩定在 105 至 118 ms，實際網頁和影片體驗往往更可靠。

辨識節點負載與限速

節點在晚間尖峰時段變慢、凌晨恢復，通常與節點並發量或上游壅塞有關。可以在 08:00、20:00、23:30 三個時段記錄同一節點的速度。如果結果從 160 Mbps 降至 18 Mbps，而其他節點仍維持 120 Mbps 以上，應優先切換節點，而不是反覆修改 Android 設定。

另一個典型特徵是小檔案開啟正常，大檔案下載卻穩定停在固定速度。例如網頁首屏載入很快，但下載始終維持在約 2.0 MB/s。這可能是節點端的頻寬分配、訂閱方案速率限制或單一連線限速。使用兩個不同來源的大檔案測試，再嘗試支援多連線的下載工作，即可區分目標網站限速與節點整體傳輸量不足。

更新訂閱並排除失效項目

進入「設定檔」頁面，更新目前訂閱，然後重新選取設定檔。如果訂閱提供者已更換伺服器位址，而手機仍使用快取設定，舊節點可能出現偶爾可連線、握手緩慢或速度極低的情況。更新後應再次檢查策略組，因為節點名稱變更可能使原本的手動選擇退回第一個項目。

第二層：判斷電信業者線路與跨網壅塞

節點本身正常，但家庭 Wi-Fi 下明顯變慢、行動網路下恢復，代表問題可能位於本地電信業者至代理入口之間。即使兩個節點位於同一地區，其入口電信業者、中轉方式和回程路徑也可能完全不同。

透過切換網路定位入口路徑

最有效的對照不是反覆重新啟動 Clash，而是保持節點不變，只切換連線網路。假設節點 C 在家庭寬頻下為 14 Mbps、在 5G 下為 126 Mbps；關閉 Clash 後，兩種網路都能達到約 200 Mbps，那麼手機效能和節點出口通常不是主要限制，更值得懷疑的是家庭寬頻至節點入口的路徑。

比較直連規則與代理規則

進入「日誌」頁面，開啟速度異常的網站，觀察連線記錄中的規則名稱與最終策略。如果本應代理的網域命中 DIRECT，流量會直接經由本地電信業者；如果本應直連的大型下載網站被送往距離遙遠的節點，也會增加繞路和頻寬消耗。

例如規則集誤將軟體鏡像網站歸入代理組，原本 20 ms 的本地路徑可能變成「手機 → 境外節點 → 中國大陸鏡像」的往返路徑。此時節點測速正常，但單一網站下載緩慢。暫時將該網域加入直連規則後重新測試，即可驗證是否為分流問題。

rules:
  - DOMAIN-SUFFIX,example-download.com,DIRECT
  - DOMAIN-SUFFIX,example-video.com,PROXY
  - MATCH,節點選擇

修改規則時，應優先使用客戶端的覆寫功能或獨立規則提供者，避免每次更新訂閱後遺失本機修改。完成測試後查看日誌，確認網域確實命中新規則，而不是被前方優先級更高的規則提前攔截。

檢查 IPv4 與 IPv6 路徑差異

部分網路的 IPv6 直連速度很好，但代理節點只穩定支援 IPv4；也可能在 DNS 回傳 AAAA 記錄後，連線嘗試 IPv6 逾時，再退回 IPv4。通常會表現為網頁開始載入前停頓 2 至 5 秒，但下載開始後速度正常。

可以在客戶端「設定」→「網路」或「設定」→「DNS」中查看 IPv6 開關，暫時關閉後重新測試。不同客戶端版本的選單名稱略有差異，重點是讓 DNS 解析與 mihomo 核心的 IPv6 能力保持一致。如果關閉後首個封包回應恢復，應繼續檢查路由器的 IPv6 前綴、DNS 回傳結果和節點協定支援，不必長期依賴反覆重新連線。

第三層：核對 Android 本機設定

當多個節點、Wi-Fi 與行動網路都出現相近的低速結果，就要檢查手機本機層。Android 的省電策略、VPN 衝突、TUN 參數、DNS、MTU 和其他網路工具，都可能影響 mihomo 核心收發資料。

解除背景與省電限制

進入 Android「設定」→「應用程式」→ 目前 Clash 客戶端 →「電池」，選擇允許背景執行或不受限制；再進入「行動數據與 WLAN」，確認可使用背景數據。不同品牌的系統路徑可能是「設定」→「電池」→「應用程式耗電管理」。省電模式會限制背景 CPU 和網路活動，鎖定螢幕後尤其明顯。

測試時保持螢幕亮起 5 分鐘，再鎖定螢幕 5 分鐘，比較同一個持續下載工作。如果亮屏時為 90 Mbps、鎖屏後降至 6 Mbps，重新亮屏又恢復，基本可以確認背景排程參與了限速。

排除 VPN 與網路工具衝突

Android 在同一個使用者空間通常只能啟用一個系統 VPN 介面。廣告封鎖器、企業 VPN、私人 DNS 工具和其他代理客戶端可能與 Clash 爭用介面。進入系統「設定」→「網路和網際網路」→「VPN」，確認目前活動連線只有目標客戶端，並檢查是否啟用了其他一律開啟的 VPN。

私人 DNS 本身不一定會降低傳輸量，但伺服器無法連線時會造成網域解析等待。進入「設定」→「網路和網際網路」→「私人 DNS」，暫時切換為自動，再測試首次開啟網頁所需的時間。如果下載速度不變，但網頁等待時間從 4 秒降至不到 1 秒，問題主要在 DNS，而不是節點頻寬。

比較系統代理與 TUN 模式

系統代理模式只會處理遵循 Android 代理設定的應用程式，部分遊戲、QUIC 流量和自行實作網路堆疊的應用程式可能繞過代理。TUN 模式透過 Android VPN 介面接管更廣泛的流量，但會增加一層虛擬網卡處理。排查時不要同時變更節點、DNS 和 TUN，應一次只切換一個變數。

  1. 在「設定」→「網路」或「設定」→「TUN」中記錄目前狀態。
  2. 使用相同節點，在一般 VPN 接管方式下完成一次 30 秒測速。
  3. 啟用 TUN 後重新授權 Android VPN，再執行相同測試。
  4. 比較下載速度、上傳速度、延遲，以及目標應用程式是否被正確接管。

如果一般模式為 140 Mbps，而 TUN 模式只有 38 Mbps，應繼續檢查 MTU、協定堆疊和 DNS 劫持，而不是直接認定節點故障。反過來，如果瀏覽器正常但某個應用程式不走代理，TUN 模式可能解決的是接管範圍，而不是線路速度。

調整 MTU 處理分片問題

MTU 不匹配會導致封包分片或遭到捨棄，常見表現是小型網頁正常、圖片和影片卡住、上傳速度異常低。TUN 常用的 MTU 可從 1500 開始測試；在行動網路、額外通道或部分寬頻環境中，可依序測試 1480、1420、1400。每次只修改一個數值，並完全停止後重新啟動核心。

如果 MTU 為 1500 時上傳只有 0.8 Mbps，改為 1400 後穩定達到 18 Mbps，而下載變化不大，可以保留較穩定的數值。MTU 過低也會增加封包標頭開銷，因此不應直接降到很小，而應以 20 至 40 位元組為步長定位。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

設定欄位是否可用，取決於客戶端整合的 mihomo 核心版本。使用覆寫前，應先在「關於」或「設定」→「核心」中記錄版本號，例如客戶端 2.11.15、mihomo 1.19.12，並在修改後查看日誌是否出現 unknown field、parse error 或 TUN create failed。

分開處理 DNS 緩慢與實際頻寬不足

DNS 問題常被描述成「網速慢」，但它主要影響連線建立前的解析階段。典型現象是輸入網址後等待數秒，頁面一開始載入就很快；已建立連線的影片串流和大檔案下載速度基本正常。

觀察首個封包等待時間與持續下載速度

mihomo 設定中常見的本機混合代理連接埠是 7890，SOCKS 連接埠可能是 7891，DNS 監聽連接埠常見為 1053。這些數值不是固定要求，但同一連接埠不能同時被兩個服務占用。如果日誌出現 address already in use，應檢查其他代理、DNS 轉送器或舊核心程序。

mixed-port: 7890

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上述位址僅用於說明設定結構。實際選擇上游 DNS 時，應考慮所在網路的可達性，以及是否需要透過代理查詢。如果 DNS 請求本身被規則送往不穩定的節點，解析時間也會隨節點壅塞而增加。

檢查協定、核心與裝置效能

在較舊或低功耗裝置上，高吞吐加密、規則比對和 TUN 轉送可能佔用大量 CPU。測速時可查看系統電池頁面或效能監控：如果單一核心長時間接近滿載，速度穩定卡在某個水平，同時機身升溫，裝置處理能力可能成為限制。

比較協定，而不只是比較地區

同一服務中的不同節點可能使用不同的傳輸協定。測試時選擇入口地區接近、線路等級相同但協定不同的節點，可以減少變數。如果某種協定在目前行動網路中頻繁遺失封包，而另一種保持穩定，應保留適合目前網路的節點，不必只依延遲數字強行選擇。

UDP 與 QUIC 也需要分開觀察。網頁基於 TCP 時正常，不代表遊戲或 HTTP/3 也正常。可以暫時關閉瀏覽器 QUIC，或讓目標網域改走另一個節點進行對照。如果關閉 QUIC 後影片啟動恢復，但一般下載沒有變化，應檢查節點的 UDP 支援和電信業者的 UDP 品質。

更新核心前先保留測試記錄

客戶端版本和 mihomo 核心版本會影響協定實作、TUN 堆疊及 DNS 行為。更新前記錄四項資訊：Android 版本、客戶端版本、核心版本、目前設定的更新時間。更新後使用相同節點和相同測速條件重新測試，才能判斷變化來自軟體還是網路時段。

如果更新後立即出現全面降速，可以進入「日誌」檢查設定相容性錯誤，並暫時停用自訂覆寫。舊設定中的棄用欄位可能被忽略，也可能導致某個模組未按預期啟動。恢復基礎訂閱設定後速度正常，再逐項加回 DNS、TUN 和規則覆寫，即可快速定位衝突欄位。

依結果執行的最終排查順序

完整排查不需要一次修改所有設定。按照「節點 → 線路 → 本機」的順序，每一步只變更一個變數，通常能在 15 至 30 分鐘內縮小範圍。

  1. 記錄直連基準：關閉 Clash，在 Wi-Fi 和行動網路各測速兩次。
  2. 確認實際節點：進入「代理」，查看規則實際引用的策略組與選取的節點。
  3. 橫向切換節點：至少測試三個入口，記錄延遲、下載、上傳和測試時段。
  4. 更新訂閱：進入「設定檔」更新目前訂閱，並重新確認策略組選擇。
  5. 切換連線網路：保持節點不變，比較 Wi-Fi 與 4G、5G。
  6. 核對規則日誌：確認速度慢的目標命中了預期的 DIRECT 或代理策略。
  7. 檢查 Android 限制：解除背景電池限制，停止其他 VPN 和網路工具。
  8. 區分 DNS 與傳輸量：比較首個封包等待時間和持續下載速度，不要把解析緩慢誤判為頻寬不足。
  9. 比較 TUN：在相同條件下切換模式，必要時測試 1500、1480、1420、1400 MTU。
  10. 檢查版本與覆寫：記錄客戶端和 mihomo 版本，停用自訂項目後重新測試。

最終判斷可以歸納為三類：只有個別節點速度慢，直接處理節點品質；同一節點在不同網路下差異明顯，重點處理電信業者路徑和路由器；所有節點、所有網路都慢，重點檢查 Android 背景限制、TUN、DNS、MTU、核心版本和裝置效能。保留測試表比反覆點選重新連線更有效，也方便在訂閱或網路環境變更後重新確認。

前往安裝檔頁面