Clash 速度慢怎麼排查:節點、線路、本機設定三層定位法

為什麼要按三層排查,不要一上來就換節點

速度變慢是使用 Clash / Clash Meta(mihomo 核心)過程中最常見的反饋,但「變慢」背後可能是三層裡的任意一層出了問題——節點本身品質下降、跨境傳輸線路壅塞、或是本機客戶端設定不當。很多人的第一反應是換節點,換了幾個還是慢,又懷疑是不是訂閱出了問題,反覆折騰卻始終沒找到根因,原因就是沒有分層驗證:三層問題的表現幾乎一樣(都是「卡」、「慢」、「載入不出來」),但排查方法完全不同,混在一起測只會浪費時間。

本文按照由遠到近的順序拆解:先確認節點本身是否健康(延遲、封包遺失、倍率),再確認跨境線路是否在擁塞(高峰時段、出口頻寬),最後檢查本機設定是否拖了後腿(DNS、規則命中、TUN 模式與系統代理衝突)。每一層都給出可以直接執行的判斷動作,而不是籠統的「換個節點試試」。

第一層:節點品質——延遲、封包遺失與倍率

節點品質是最容易驗證也最該先查的一層。客戶端介面裡節點右側顯示的延遲數值,來自策略群組的 url-test 探測,反映的是本機到節點再到測試位址的往返時間,數值本身只能作參考,更重要的是看它是否穩定。

除了延遲,還要關注封包遺失率和流量倍率。封包遺失率高會導致 TCP 反覆重傳,表現為網頁載入卡頓、影片緩衝頻繁,但延遲數值本身可能並不高——這也是很多人只看延遲數字判斷「節點很好」卻實際很卡的原因。流量倍率則直接影響可用頻寬感受,同一批共享節點,低倍率往往意味著更少人搶佔頻寬,高峰期差異會更明顯。

驗證節點是否穩定的一個簡單方法是把 url-test 策略群組的探測間隔調短、把測試位址換成離目標服務更近的站點,連續觀察幾分鐘的延遲曲線,而不是只看瞬時數值:

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [节点A, 节点B, 节点C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance 表示容差範圍,數值內的延遲差異不會觸發切換,可以避免節點在臨界值附近頻繁跳動;interval 控制探測頻率,過短會增加節點端壓力,過長則不能及時反映延遲變化,一般設定在 180~300 秒之間比較合理。

第二層:跨境線路與高峰時段擁塞

如果確認了某個節點本身延遲低、封包遺失少,但特定時段依舊明顯變慢,問題往往出在跨境傳輸線路上,而不是節點伺服器本身。國際出口頻寬是有限資源,晚間 20:00~23:00 這類高峰時段,同一批使用者集中連線,疊加國際出口的整體頻寬壓力,即便節點伺服器負載正常,實際可用速度也會打折。

識別這類問題的方法很直接:在不同時段用同一個節點重複測速並記錄結果。如果延遲和速度呈現明顯的「晝夜規律」——比如凌晨速度正常、晚間集中變慢——基本可以判定是線路擁塞而非節點問題。反之如果全天任意時段都慢,大概率要回到第一層重新檢查節點本身。

另外要區分「中繼轉發」和「落地直出」兩種線路結構:前者流量在中間節點做一次轉發,後者直接由落地伺服器出口連線目標站點。中繼結構在跳數增加的同時也可能引入額外擁塞點,如果同地區有多個節點可選,不妨分別測試,選出跳數更少、延遲曲線更平穩的一個作為日常使用節點,把延遲高但偶爾急用的節點留作備選,透過策略群組的手動選擇模式做區分,而不是依賴自動測速在兩者之間來回切換。

第三層:本機設定——DNS、規則命中與模式衝突

排除了節點和線路兩層之後,如果速度問題依舊存在,基本可以確定是本機客戶端設定的問題。這一層最容易被忽視,卻也是最常見的「隱性降速」來源。

DNS 解析方式

DNS 設定不當會導致網域名稱解析走了錯誤路徑,即便代理規則本身正確,連線體驗也會變慢或者出現「部分網站能打開、部分打不開」的情況。mihomo 核心建議使用 fake-ip 模式配合獨立的 DNS 伺服器,避免解析請求外洩給本地電信業者 DNS 或遭受污染:

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5, 119.29.29.29]
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"

如果使用的是 redir-host 模式,解析結果依賴本機網路環境,容易受到電信業者 DNS 污染或劫持影響,建議非特殊需要都改用 fake-ip。

規則命中與策略群組選擇

規則檔案順序錯誤或規則集未及時更新,會導致本該走代理的流量被判定為 DIRECT 直連,或者反過來把本機服務的流量也丟進了代理群組,兩種情況都會表現為「網速變慢」。可以在客戶端的連線日誌或流量面板裡查看具體連線實際命中了哪條規則、走了哪個策略群組,確認是否與預期一致,而不是單憑主觀感覺判斷。

TUN 模式與系統代理衝突

同時開啟 TUN 模式和系統代理,或者 TUN 模式下 MTU 設定過大導致分片重傳,都會造成明顯的速度下降。一般建議二選一:需要接管全域流量、覆蓋非瀏覽器應用時用 TUN 模式,只需要瀏覽器等少數應用走代理時用系統代理即可,避免兩種接管方式疊加造成路徑混亂。

三層排查流程小結與自查清單

把上面三層串起來,形成一個可以照做的排查順序,能大幅縮短定位問題的時間,避免反覆更換節點卻始終沒找到根因。

1. 先測節點

   切換 2~3 個同地區節點,連續觀察延遲曲線與封包遺失情況,排除節點本身失效或負載過高的可能。

2. 再測線路

   用同一個確認健康的節點,在高峰與非高峰時段各測一次,判斷是否存在明顯的晝夜規律性降速。

3. 最後查本機

   檢查 DNS 模式是否為 fake-ip、查看連線日誌確認規則命中是否符合預期、確認 TUN 模式與系統代理沒有同時開啟。

4. 記錄結果再下結論

   把三層的測試結果分別記下來,再決定是換節點、換時段使用,還是調整本機設定,避免同時改動多處導致無法定位到底哪一步起了作用。

大部分反覆出現的「速度慢」問題,最終都能歸到這三層中的某一層,而且往往不是單一原因,而是幾層疊加放大了體感上的卡頓。按順序逐層驗證,比憑感覺反覆換節點更省時間,也更容易把問題描述清楚,方便向訂閱提供方或社群反饋具體現象。