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

先建立基準：延遲、頻寬與穩定性不是同一項指標

Clash 面板中的延遲通常只是一次 HTTP 連線測試所需的時間。它能判斷節點是否可連線，以及建立連線大約需要多久，卻不能直接代表下載速度。延遲 85 ms 的節點可能只有 8 Mbps；延遲 160 ms 的節點也可能穩定達到 90 Mbps。前者回應快但出口壅塞，後者距離較遠但頻寬充足。

正式排查前，先固定測試條件。不要同時切換節點、修改 DNS 和開啟 TUN。變數一起改動後，即使速度恢復，也無法確認是哪項設定發揮作用。建議先保留目前設定，並記錄測試時間、節點名稱、代理模式、下載速度與延遲。

四組基準資料

1. 直連基準：關閉 Clash 的系統代理與 TUN，開啟電信業者的測速頁面。若直連只有 20 Mbps，代理就不可能穩定跑滿 100 Mbps。
2. 中國大陸下載基準：下載至少 200 MB 的中國大陸鏡像檔案，觀察 30 秒後的穩定速度，排除 Wi-Fi 與本機寬頻問題。
3. 節點延遲：針對同一地區的 3 至 5 個節點各測試三次，不採用第一次結果，記錄後兩次的數值範圍。
4. 代理吞吐量：選定單一節點下載同一個測試檔案，每次至少持續 60 秒，避免把剛開始的突發速度誤認為穩定速度。

換算時要注意單位。測速頁面常用 Mbps，下載器則常用 MB/s，兩者相差約 8 倍。80 Mbps 對應的理論下載速度約為 10 MB/s，扣除協定、TCP 與加密開銷後，實際看到 8 至 9.5 MB/s 通常算正常。

第一層：判斷是不是節點本身變慢

節點層問題出在代理伺服器本身或節點提供商的出口。典型情況是同一訂閱中只有少數節點變慢，切換到同地區其他節點後立即恢復；或者該節點全天速度都偏低，其他節點不受影響。

不要只按延遲排序

自動選擇策略組通常會依測試 URL 的回應時間挑選節點。這種方式適合判斷可用性，卻測不出節點的持續傳輸能力。測試 URL 回傳的內容很小，節點即使只剩少量頻寬，也可能得到漂亮的延遲數字。

以三次測試為例：節點 A 的延遲為 72、81、76 ms，下載速度穩定在 2.1 MB/s；節點 B 的延遲為 145、151、148 ms，下載速度穩定在 11.4 MB/s。瀏覽網頁重視首個封包回應時，A 可能體感更快；下載大型檔案或觀看高碼率影片時，B 更合適。

辨識節點過載

• 上午速度正常，晚間固定時段降至白天的三分之一以下。
• 延遲從約 100 ms 週期性跳到 500 ms 以上，並伴隨連線重設。
• 同一地區的多個節點中，只有一個節點持續低速。
• 短連線網頁仍能開啟，但持續下載數十秒後速度不斷下降。
• 切換到另一種協定或另一個入口後恢復，但本機設定完全未變。

節點名稱中的「倍率」通常用於計算訂閱流量消耗，不代表速度等級。標示 0.5 倍的節點不一定較慢，2 倍節點也不等於速度加倍。選擇節點時，應分別查看延遲、穩定吞吐量、丟包情況與流量成本。

節點層的處理方式

1. 先在同一地區內切換節點，維持代理模式與測試檔案不變。
2. 關閉自動選擇，暫時固定使用單一節點，避免測試過程中策略組自行切換。
3. 更新一次訂閱，確認節點位址、連接埠與協定參數沒有被服務提供方調整。
4. 若只有一個節點異常，記錄測試時間與穩定速度，再回報給節點提供方。

第二層：判斷是不是跨境線路與電信業者路徑壅塞

線路層位於本機寬頻與代理節點之間。節點伺服器本身可能有充足頻寬，但目前電信業者通往該入口的路徑若發生繞路、丟包或尖峰時段壅塞，實際速度仍會下降。此時切換同一機房的多個節點，結果往往都差不多。

線路問題的三個明顯特徵

• 與時間有關：平日上午可達 70 Mbps，20:00 至 23:00 只能達到 10 Mbps。
• 與電信業者有關：同一個節點在家用寬頻下速度很慢，切換到手機熱點後明顯恢復。
• 與地區有關：某一地區的整組節點都很慢，換到另一地區後吞吐量恢復。

一般 ping 使用 ICMP 封包，部分伺服器會降低其優先級或直接不回應。因此「ping 丟包 100%」不一定代表代理無法使用，「ping 只有 40 ms」也不保證 TCP 或 UDP 傳輸順暢。Clash 的 HTTP 延遲測試更接近實際代理連線，但仍只是小流量探測。

用對照法定位電信業者路徑

1. 固定一個節點與一個至少 200 MB 的下載網址，使用家用寬頻測試 60 秒。
2. 維持節點不變，切換到 4G 或 5G 手機熱點，再測試 60 秒。
3. 分別在上午與晚間尖峰時段重複測試，記錄穩定速度而非峰值。
4. 如果熱點可達 8 MB/s，而家用寬頻只有 900 KB/s，Clash 本機設定通常不是首要嫌疑。

如果同地區的節點普遍壅塞，優先更換地區，而不是繼續在同一組中逐一嘗試。物理距離較近通常意味著較低延遲，但線路品質比直線距離更重要。實際選擇應以目前電信業者的測試結果為準。

第三層：檢查 Clash 用戶端與本機網路設定

當所有節點同時變慢，而且更換網路後差異不大，應檢查本機層。常見問題包括系統代理連接埠、代理模式、TUN、DNS、瀏覽器代理擴充功能、安全軟體與虛擬網路卡。排查原則仍是一次只修改一項。

先核對代理模式與連接埠

以 Clash Verge Rev 2.3.x 搭配 mihomo 1.19.x 的介面為例，可在「設定」→「Clash 設定」中查看混合連接埠。常見值為 7890，但設定檔也可能使用 7897、7899 或其他連接埠。系統代理指向的連接埠必須與目前核心監聽的連接埠一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

連接埠不一致通常會完全無法存取，但當瀏覽器擴充功能、系統代理與應用程式內代理同時存在時，也可能出現請求繞路、重複代理或部分程式速度異常。測試階段只保留一種入口：要麼開啟用戶端的系統代理，要麼讓目標應用程式明確使用 HTTP/SOCKS 連接埠。

確認規則沒有把測速請求送到錯誤的策略組

Rule 模式會由上到下比對規則，首次符合後便停止。測速網站首頁、下載網域與統計網域可能符合不同策略。如果下載網域被送往 DIRECT，而頁面本身經過代理，測速結果就不能代表節點速度。

開啟用戶端的連線記錄，找到正在傳輸的網域，檢查對應的規則與策略組。記錄中應能看到請求符合哪條規則，以及最後使用哪個節點。若要進行純節點測試，可暫時切換到 Global 模式並固定單一節點；測試結束後再切回 Rule，避免日常流量全部經過代理。

TUN 模式變慢時如何拆分排查

TUN 會接管更多系統流量，適合不讀取系統代理的程式與部分遊戲。它也會增加虛擬網路卡、路由與 DNS 處理環節。若系統代理模式正常，開啟 TUN 後卻明顯變慢，請依下列順序測試：

1. 關閉 TUN，保留系統代理，重複相同的下載測試。
2. 重新開啟 TUN，確認沒有同時執行其他 VPN、加速器或舊版虛擬網路卡。
3. 在用戶端的 TUN 設定中切換可用堆疊，例如 system 與 mixed，每次切換後重新啟動核心。
4. 檢查 MTU。預設值造成部分網站卡頓時，可依序測試 1500、1400、1280，並記錄變化。
5. 若只有 UDP 應用程式異常，請單獨檢查節點協定是否支援穩定的 UDP 轉發。

MTU 不應憑感覺長期設得過低。數值過大可能導致分片或特定連線停頓，過小則會增加封包標頭開銷。只有出現「網頁能開但大檔案停住」、「部分圖片長時間載入不完」等症狀時，才值得進行分級測試。

DNS 慢不等於節點頻寬慢

DNS 異常主要會拖慢首次開啟頁面與網域解析。頁面開始下載後仍能跑滿頻寬，通常表示節點吞吐量正常。若每個新網站都要等待 3 至 5 秒，但進入後載入很快，應優先檢查 DNS，而不是更換節點。

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

這段設定僅供排查示範，不應直接覆蓋現有訂閱。使用 fake-ip 時，區域網路裝置、企業內網與少數依賴真實位址的應用程式可能需要加入過濾規則。DNS 上游也要配合目前網路選擇，境內解析與代理端解析所承擔的任務不同。

排除瀏覽器與背景程式干擾

• 關閉瀏覽器中的代理擴充功能，避免擴充功能連接埠與系統代理疊加。
• 暫停雲端硬碟同步、系統更新與遊戲更新，查看工作管理員中的即時網路使用量。
• 暫時關閉 HTTP/3 後重複測試，用於判斷 UDP 路徑是否異常；確認後恢復原本設定。
• 使用有線連線或 5 GHz、6 GHz Wi-Fi，避免在擁擠的 2.4 GHz 頻段測速。
• 將記錄層級維持在 info。長期使用 debug 會產生大量記錄，不適合作為日常設定。

依症狀執行固定排查流程

實際處理時不需要把所有設定都改一遍。先依症狀選擇最短路徑，再用對照測試確認結果。

情境一：延遲低，但下載速度只有幾百 KB/s

1. 固定目前節點，不看延遲數字，測試持續下載 60 秒。
2. 切換到同地區的另一個節點。如果速度恢復，原節點過載的可能性較高。
3. 同地區仍然很慢時，換到另一個地區，判斷是否為線路壅塞。
4. 所有地區都很慢時，關閉 TUN、瀏覽器擴充功能與背景下載，再檢查本機層。

情境二：白天快，晚上固定變慢

先保留一組白天與晚間資料。例如白天 11:00 為 78 Mbps，晚間 21:30 為 14 Mbps，而手機熱點使用同一節點仍有 55 Mbps。這組結果更指向家用寬頻的晚間尖峰路徑，而不是 Clash 用戶端故障。處理方向是更換地區入口、更換線路類型或避開壅塞時段。

情境三：瀏覽器快，遊戲或下載器慢

先確認該程式是否讀取系統代理。許多遊戲與部分下載器不會使用 HTTP 系統代理，需要 TUN 或應用程式內的 SOCKS5 設定。若程式允許手動代理，可填入 127.0.0.1 與目前的 SOCKS/mixed 連接埠，例如 7890。設定後，在連線記錄中確認流量確實進入 mihomo。

情境四：開啟 Clash 後中國大陸網站也變慢

查看連線記錄，確認中國大陸網域是否符合 DIRECT。若誤入代理組，請檢查規則順序與規則集更新狀態。不要直接把所有流量改為直連來掩蓋問題；應找出錯誤符合的規則，確認規則集是否載入成功。

處理優先順序：先做低風險操作，再修改底層參數

建議順序為：更新訂閱、固定節點、切換同地區節點、切換地區、變更網路進行對照、關閉 TUN 進行對照、檢查規則與連接埠，最後再調整 DNS 與 MTU。這個順序會從外部變數逐步深入本機底層，回復成本較低。

每次測試至少保留 60 秒的穩定資料，並在修改後重新啟動核心。不要同時更換設定檔、DNS、TUN 堆疊與節點，否則結論無法重現。排查結束後，應恢復 Rule 模式、關閉臨時除錯記錄，並刪除不再使用的手動代理設定。

如果需要進一步了解 DIRECT、PROXY、策略組、規則比對與 fake-ip 的關係，可查看術語手冊與進階設定。第一次設定用戶端時，則依照使用指南重新核對訂閱、系統代理與模式選擇。