Clash 速度慢分層排查法：先釐清是節點、線路還是本機設定問題

先定義「慢」：延遲、頻寬與回應時間不是一回事

Clash 或 mihomo 面板顯示的延遲只有幾十毫秒，網頁仍可能載入緩慢；反過來，延遲 180 ms 的節點也可能穩定跑滿寬頻。因為延遲、封包遺失、可用頻寬和網站回應時間，描述的是不同環節。排查前若只盯著節點清單中的單一數字，很容易把線路壅塞誤判為用戶端故障。

建立可重複的測試基準

開始切換節點前，先固定測試條件。建議關閉正在同步檔案、下載更新或播放影片的應用程式，讓同一台裝置連線到同一台路由器，並選定兩個測試目標：一個觀察網頁首次開啟時間，另一個進行持續下載。每輪至少測試 3 次，記錄中位數，不要根據單次峰值下結論。

1. 在用戶端切換至「直連」模式，記錄本地寬頻的延遲與下載速度。
2. 恢復「規則」模式，固定同一個測試節點與測試網址。
3. 分別在上午及晚間 20:00 至 23:00 測試，比較不同時段的差異。
4. 記錄用戶端目前模式、節點名稱、下載速度、首次開啟等待時間，以及是否發生逾時。

第一層：檢查節點延遲、負載與協定狀態

節點側問題通常表現為同一策略群組內只有少數節點明顯變慢，切換至其他地區或其他入口後立即恢復。這裡要區分「延遲測試通過」和「節點具備穩定吞吐量」這兩個結論。Clash 面板的延遲測試通常會透過指定 URL 建立連線並測量回應時間，能篩出失聯節點，但不能直接代表大檔案下載速度。

使用策略群組進行同條件橫向比較

進入用戶端的「代理」頁面，找到目前規則實際引用的策略群組。以常見桌面用戶端為例，可沿著「代理」→「節點選擇」查看群組內節點；若使用 Clash Verge Rev，可在「設定」→「Clash 設定」確認目前執行模式，再回到「代理」頁面切換節點。不要一邊更換節點，一邊修改 DNS、TUN 或規則，否則無法判斷是哪項變更產生效果。

• 先選擇 3 個同地區節點，分別執行 3 次延遲測試。
• 延遲波動超過 100 ms，或連續發生逾時，優先視為節點或入口不穩定。
• 延遲穩定但下載速度偏低，再進行至少 60 秒的持續下載測試。
• 同地區節點全部偏慢時，加入一個不同地區節點作為對照。
• 只有單一節點變慢時，直接更換節點通常比繼續調整本機參數更有效。

倍率不等於速度

訂閱面板常見的「0.5 倍」「1 倍」「2 倍」，通常代表流量計費倍率，而不是速度倍數。2 倍節點不會天生比 1 倍節點快兩倍；它可能使用不同線路，也可能只是流量扣除比例不同。判斷速度仍應以實測吞吐量、封包遺失與時段穩定性為準。

自動測速群組可能選到「低延遲、低頻寬」節點

url-test 策略群組會依測試 URL 的回應結果自動選擇節點。若測試目標回傳的資料很小，某個節點可能因握手速度快而勝出，但持續頻寬未必理想。可以適度調長測試間隔，避免頻繁切換；也可以將穩定性相近的節點放進同一群組，而不是把所有地區混在一起。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點-A
      - 節點-B
      - 節點-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

interval: 300 表示每 300 秒測試一次，tolerance: 80 用於減少延遲差異較小時的頻繁切換。這裡的 URL 只負責可用性與回應測試，不應視為完整的頻寬測試。修改訂閱產生的設定前，還要確認用戶端更新訂閱時是否會覆寫本機變更。

第二層：判斷線路側的尖峰壅塞、封包遺失與路由變化

線路問題位於本地電信商、跨網互聯、入口伺服器與出口伺服器之間。它通常具有明顯的時間特徵：白天速度正常，晚間 20:00 後延遲升高；或者行動網路正常，家用寬頻變慢。此時反覆重裝用戶端、刪除設定通常不會改變結果。

透過時間與接入網路交叉驗證

測試時應保持節點與用戶端設定不變，只切換網路。例如先透過家用 Wi-Fi 測試，再使用手機熱點測試。若熱點環境下速度從 12 Mbps 恢復到 90 Mbps，表示用戶端與節點至少能提供更高吞吐量，問題較可能出在家用寬頻至節點入口的路徑。

延遲波動比單次低延遲更值得關注

連續測試得到 58 ms、61 ms、64 ms，通常比 28 ms、190 ms、逾時更穩定。後者雖然出現過更低的數字，但抖動與封包遺失會導致 TCP 重傳，下載速度也會下降。影片、遠端桌面與遊戲對抖動更加敏感。

在 Windows 中，可先使用 PowerShell 檢查節點入口連接埠是否能建立 TCP 連線。請將範例主機與連接埠替換為訂閱節點實際使用的值：

Test-NetConnection example.com -Port 443
ping example.com -n 20

在 macOS 或 Linux 中，可觀察連續延遲：

ping -c 20 example.com
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "connect=%{time_connect} total=%{time_total}\n" https://www.gstatic.com/generate_204

範例中的 7890 是常見的混合連接埠，並非固定值。實際連接埠應在用戶端「設定」→「連接埠設定」或設定檔的 mixed-port 欄位中確認。若命令回傳連線被拒絕，先檢查 mihomo 是否正在執行、連接埠是否一致，不要直接判定遠端節點失效。

第三層：本機設定檢查 DNS、規則命中與代理衝突

如果多個節點表現相近，而且更換網路後問題仍存在，就應回頭檢查本機設定。常見症狀包括網頁首次開啟緩慢、某個應用程式不經代理、規則模式緩慢但全域模式正常，以及啟用 TUN 後速度突然下降。本機層應依照「連線是否進入核心、規則是否選對策略、DNS 是否順暢」的順序檢查。

先看連線記錄，不要只看節點名稱

開啟用戶端的連線或日誌頁面，然後重新造訪發生問題的網站。常見用戶端可從「日誌」或「連線」頁面查看目標網域、命中的規則與最終策略。應確認三項資訊：網域是否被 mihomo 擷取、命中了哪條規則，以及最終使用哪個策略群組與節點。

• 若連線記錄中完全沒有目標應用程式的流量，請檢查系統代理或 TUN 的接管範圍。
• 若目標網域命中 DIRECT，但預期應經過代理，請檢查規則順序與規則集更新狀態。
• 若命中錯誤地區的策略群組，回到「代理」頁面檢查群組內目前的選擇。
• 若日誌持續出現 DNS 逾時，優先處理解析鏈路。
• 若同一請求反覆建立連線，請檢查系統中是否還有另一套代理軟體。

Clash 規則會由上到下比對，最先命中的規則生效。過於寬泛的規則若放在前面，可能使後續精確的網域規則失效。例如 GEOIP,CN,DIRECT 通常應放在網域規則之後、最終 MATCH 之前。調整時一次只移動一類規則，重新載入後再從連線日誌驗證。

rules:
  - DOMAIN-SUFFIX,example.net,代理節點
  - DOMAIN-KEYWORD,stream,媒體策略
  - GEOIP,CN,DIRECT
  - MATCH,代理節點

使用全域模式進行短時間對照

規則模式很慢時，可以短暫切換至全域模式，使用同一節點造訪同一個目標。如果全域模式立即恢復，而規則模式持續緩慢，問題通常不在節點頻寬，而在規則命中、DNS 分流或某些資源走了不同路徑。測試結束後應切回規則模式，再依據日誌修正规則，不建議長期使用全域模式掩蓋設定問題。

DNS 緩慢常見表現是「先卡住，之後很快」

網域解析逾時會拉長第一個請求的等待時間。尤其當多個 nameserver 品質差異較大、IPv6 可以解析但無法連線，或系統 DNS 與 mihomo DNS 路徑混用時，瀏覽器可能等待失敗連線回退。可以在設定中統一 DNS 處理，並確認用戶端已成功載入設定。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

ipv6: false 適合用來驗證 IPv6 回退是否造成等待，但不代表所有網路都應永久關閉 IPv6。如果本機與代理鏈路都完整支援 IPv6，可以恢復後重新測試。fake-ip 能讓網域流量更早進入規則判斷，但區域網路裝置、部分遊戲與依賴真實位址的服務，可能需要加入 fake-ip-filter。

檢查系統代理與瀏覽器代理是否疊加

桌面環境常見的衝突是：用戶端已設定系統代理，瀏覽器擴充功能又將流量轉送到另一個連接埠；或者舊用戶端結束後仍留下系統代理位址。此時請求可能繞行兩次，甚至在本機形成失敗重試。

1. 進入用戶端「設定」→「系統代理」，確認目前的開關狀態。
2. 進入「設定」→「連接埠設定」，記錄 HTTP、SOCKS 或 mixed 連接埠。
3. 檢查瀏覽器代理擴充功能，暫時改為跟隨系統代理。
4. 檢查作業系統網路代理，確認位址通常為 127.0.0.1，且連接埠與用戶端一致。
5. 完全結束其他代理用戶端，再重新測試首次開啟與持續下載。

若設定使用 mixed-port: 7890，HTTP 與 SOCKS 用戶端都能連接該連接埠。不要讓同一個瀏覽器請求先交給 SOCKS 擴充功能，再轉送至系統 HTTP 代理。只需要瀏覽器代理時，若系統代理已生效，擴充功能通常只要保持直連或跟隨系統設定即可。

TUN 模式專項：應用程式接管、MTU 與 UDP

TUN 模式透過虛擬網卡接管不遵循系統代理的應用程式流量，適合遊戲用戶端、命令列工具與部分商店應用程式。但它也增加了額外的路由、DNS 劫持與封包處理環節。若「關閉 TUN 正常，啟用 TUN 變慢」，應檢查 TUN 設定，而不是先更換所有訂閱節點。

先判斷是否只有 TUN 路徑受到影響

1. 固定一個節點，在系統代理開啟、TUN 關閉時測試瀏覽器。
2. 保持節點不變，啟用 TUN，再測試相同網址。
3. 查看連線頁面，確認兩輪測試命中相同規則與相同節點。
4. 若只有啟用 TUN 後速度下降，請檢查虛擬網卡衝突、MTU 與網路堆疊。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed 是 mihomo 常見的相容選擇。若裝置同時執行 VPN、虛擬機器、容器網路或遊戲加速工具，自動路由可能選錯出口網卡。此時可先結束其他會建立虛擬網卡的軟體，再重新啟動用戶端測試。不要同時修改 stack、MTU 與 DNS 劫持，否則難以定位具體原因。

MTU 不合適時的典型表現

MTU 問題可能造成小型網頁可開啟、大檔案卻卡住，或特定網站上傳失敗。可以從較保守的數值開始對照，例如在 TUN 設定中測試 mtu: 1400，確認有效後再逐步調整。不同系統、寬頻撥號方式與上層通道的合適數值並不相同，因此 1400 只是一個排查起點。

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

如果修改 MTU 後大檔案下載明顯恢復，而節點與規則都沒有變化，表示分片或路徑 MTU 探索可能參與了故障。若沒有改善，應恢復原設定，繼續檢查 DNS 與線路，而不是不斷降低數值。

訂閱與核心狀態：排除舊設定與版本不相容

訂閱更新失敗不一定會讓所有節點離線，有時用戶端仍在使用快取設定，導致節點入口、規則集或 DNS 參數長期未更新。排查時應確認「訂閱更新時間」與「目前執行設定」是同一份內容。更新訂閱後還要套用設定或重新載入，不能只看到下載完成就認為核心已經切換。

檢查訂閱更新時間與設定載入結果

• 在「訂閱」或「設定」頁面查看最後更新時間，確認不是幾週前的快取。
• 手動更新後檢查是否出現 HTTP 逾時、驗證失敗或內容為空。
• 更新成功後選取該設定並重新載入。
• 進入日誌頁面，確認設定解析成功，策略群組與規則集已建立。
• 如果訂閱包含覆寫功能，請檢查本機覆寫是否仍適用於目前欄位。

將舊版 Clash 設定遷移至 mihomo 時，基本的代理、策略群組與規則結構通常仍可使用，但部分擴充欄位、TUN 參數與規則集行為可能隨版本變更。出現設定載入錯誤時，應先根據日誌定位欄位，而不是刪除整個訂閱。核心版本可以在用戶端「設定」→「核心」或「關於」頁面查看；不同用戶端的選單名稱可能略有差異。

十分鐘排查流程與結果判斷

故障發生時，可以依照以下順序快速縮小範圍。核心原則是每輪只變更一個變數，並記錄變更前後的結果。

1. 第 1 分鐘：關閉背景下載，使用直連模式測試一次本地基準。
2. 第 2 至 3 分鐘：恢復規則模式，固定測試節點，記錄延遲、首次開啟時間與 60 秒下載速度。
3. 第 4 分鐘：切換至同地區的另一個節點。只有原節點變慢時，歸類為節點側問題。
4. 第 5 分鐘：切換至不同地區的節點。所有代理節點都慢但直連正常，繼續判斷線路或本機設定。
5. 第 6 分鐘：使用手機熱點重新測試同一節點。熱點恢復時，優先判斷家用寬頻路徑。
6. 第 7 分鐘：查看連線日誌，核對規則、策略群組與目標節點。
7. 第 8 分鐘：短暫切換至全域模式。全域模式恢復時，重點檢查規則與 DNS。
8. 第 9 分鐘：關閉瀏覽器代理擴充功能與其他代理用戶端，排除本機代理疊加。
9. 第 10 分鐘：比較 TUN 開關狀態；只有 TUN 模式變慢時，再檢查虛擬網卡、MTU 與 DNS 劫持。

排查記錄應保留哪些資料

如果需要向訂閱服務商、網路管理員或用戶端專案回報問題，只說「速度慢」很難重現。應提供可比較的資料，但不要公開訂閱網址、節點密碼或完整設定。建議保留測試日期、時段、接入網路、用戶端版本、mihomo 核心版本、節點地區、執行模式與測試結果。

測試時間：2026-06-20 21:30
接入網路：家用寬頻，有線連線
執行模式：規則模式，TUN 開啟
本地直連：286 Mbps
節點 A：延遲 72 ms，持續下載 18 Mbps
節點 B：延遲 81 ms，持續下載 96 Mbps
手機熱點 + 節點 A：74 Mbps
規則命中：MATCH → 代理節點
現象：晚間下降，白天恢復

這組記錄可以直接支持判斷：節點 A 在家用寬頻晚間路徑下表現較差，而節點 B 與手機熱點的對照顯示，用戶端基本設定並未完全失效。相比反覆清除設定，這類分層證據更容易找出真正需要更換或調整的環節。