Clash 速度慢怎麼排查？檢查節點品質、線路壅塞與本機設定

先釐清：是網頁開啟慢，還是下載持續低速

Clash 顯示節點延遲正常，不代表下載速度也正常。清單中的測速通常是透過節點請求測試 URL，結果會受連線建立、目標網站回應、連線重用及用戶端測速方式影響。這不是頻寬測試，也不能直接代表觀看影片或下載檔案的實際體驗。

排查前，先固定一個出問題的網站、一台裝置和一個節點。暫停雲端硬碟同步、系統更新及其他下載，使用規則模式，並在連線清單確認目標請求確實套用預期的策略組。若請求實際命中 DIRECT，更換代理節點無法驗證這條連線。

建立測速基準：固定入口、節點與目標

確認代理連接埠與實際出口

以下以本機混合連接埠 7890 為例。這不是所有用戶端共用的預設值，請先在用戶端的連接埠設定或目前生效的設定檔中確認 mixed-port。HTTP 代理請求可使用此連接埠；控制面板的 API 連接埠不是代理流量使用的連接埠，兩者不可混用。

在 Windows PowerShell 中可執行以下指令。指令會明確透過本機代理存取一個小型網頁，適合比較連線建立與回應時間，不適合測量最大下載頻寬。macOS 或 Linux 請將 curl.exe 改為 curl。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

macOS、Linux 也請將 NUL 改為 /dev/null。這些時間以秒為單位，表示從請求開始累計的時間。使用 HTTP 代理時，time_connect 主要表示連上本機代理所花的時間；time_appconnect 也包含建立代理通道與 TLS 交握的等待時間，不能直接解讀為節點往返延遲。網域通常由代理路徑負責解析，因此單靠這個指令也無法證明本機 DNS 的速度。

測頻寬請改用持續傳輸

1. 選擇自己有權存取、大小至少約 100 MB 的固定檔案，確保每次測試使用相同資源。
2. 先用單一連線下載，觀察穩定傳輸 30 至 60 秒後的速度，再測試下載工具的多連線模式。
3. 固定使用同一個節點；若策略組會自動切換，請暫時手動選定節點，並重新建立測試連線。
4. 記錄測試時間、網路類型、規則命中結果、節點、速度單位及用戶端核心資訊。

注意單位換算：8 Mbps ≈ 1 MB/s；標示為 100 Mbps 的寬頻，理論上限約為 12.5 MB/s，實際速度還會受到通訊協定額外負擔影響。不要直接比較測速網站的 Mbps 與下載工具顯示的 MB/s。

第一層：判斷節點品質與目標適配性

先從節點層確認是否只有特定節點速度慢。選擇同一地區的兩個節點，連線至相同目標，各測試 3 次。盡量保持地區一致，避免跨洲距離、出口地區和內容傳遞位置同時改變。若訂閱資訊標示兩種不同線路，也可進一步比較；節點名稱不同，不代表底層入口、伺服器或出口一定不同。

低延遲節點不一定有較高的傳輸速度

以下數據僅供判讀示範，並非本站實測結果或節點推薦。假設同一時段下載同一檔案的結果如下：節點 A 測得延遲 65 ms，下載速度 0.8 MB/s；節點 B 延遲 140 ms，下載速度 8 MB/s。若要持續下載，可優先選擇 B；互動用途則還需比較首位元組時間與穩定性。只按延遲數字排序，可能忽略節點限速和負載。

• 某個節點連多個網站都很慢：優先懷疑該節點負載過高、遭到限速，或通往入口的路徑不佳。
• 同一節點只有一個網站很慢：檢查目標網站限速、出口地區與 CDN 節點分配，不能因此判定整個節點失效。
• 所有節點都很慢：接著檢查線路與本機，特別留意家用網路的頻寬占用，以及是否真的選用了不同出口。

切換策略後，已建立的下載連線可能仍使用舊節點。請取消測試並重新開始，或只關閉連線清單中對應的測試連線，再確認新的連線路徑。不要拿切換前後同一條長連線的速度作比較。

自動策略組也會影響測試結果。url-test 會根據設定的測試目標選擇節點；fallback 著重依序選擇可用節點；load-balance 會分配連線，不代表單一檔案下載可以合併頻寬。評估個別節點前，應先排除自動選擇的影響。

第二層：區分線路壅塞與本地網路瓶頸

在線路層採用「兩種網路、兩個時段」的比較方式。保持電腦、用戶端設定、節點和目標不變，先測家用寬頻，再測手機熱點，之後於離峰時段重測。手機熱點會改變電信業者路由，也可能改變 IPv4、IPv6 與 NAT 環境，因此這些結果只能用來縮小排查範圍，不能直接證明某家電信業者有特定限制。

先排除上傳占滿與無線網路問題

備份、直播或同步工作占滿上傳頻寬時，下載確認封包和互動請求也可能排隊。Windows 11 可開啟「工作管理員」→「效能」→目前使用的「乙太網路」或「Wi-Fi」，查看傳送與接收速率；再到「處理程序」頁面依網路使用量排序。先暫停高使用量工作，約 30 秒後再測試。

使用無線網路時，先靠近路由器，再改用網路線比較。隔牆時，5 GHz 不一定比 2.4 GHz 好，實際訊號強度與干擾才是關鍵。如果有線連線恢復正常，通常不必優先修改 Clash DNS。

路由追蹤只能作為輔助參考。中間路由器可能降低 ICMP 回應的優先順序，某一跳逾時或顯示封包遺失，不代表實際轉送的流量也有相同問題。請綜合最終目標的表現、持續下載速度曲線，以及不同網路間的比較結果判斷。

第三層：檢查系統代理、規則與 TUN 接管

先確認速度慢的應用程式是否經過 Clash

系統代理主要影響遵循系統代理設定的應用程式，不會自動接管所有流量。Windows 11 的系統設定路徑為「設定」→「網路和網際網路」→「Proxy」。用戶端開啟系統代理後，請確認此處顯示的位址與連接埠是否和用戶端一致。瀏覽器擴充功能或應用程式本身的代理設定，仍可能覆寫系統設定。

開啟用戶端的連線清單，再發出一次請求，查看目標網域或 IP、命中的規則、策略鏈，以及上傳和下載量。若沒有對應紀錄，先檢查流量接管；若紀錄顯示直連，先檢查規則順序。規則通常由上而下比對，太早出現的廣泛規則或 MATCH 可能會影響後續規則。

TUN 比較測試時一次只改一個變數

1. 先備份目前設定，並退出其他 VPN 及會建立虛擬網卡的代理工具。
2. 關閉 TUN，只開啟系統代理，用瀏覽器測試相同目標並記錄結果。
3. 關閉系統代理，再開啟 TUN，確認用戶端具備所需權限，且流量確實出現在連線清單中。
4. 比較相同節點下的測試結果，並檢查記錄中的路由、DNS 與連線錯誤。

以上步驟是用來比對和定位問題，不代表日常使用時一定要二選一。不同用戶端安裝 TUN 路由及接管 DNS 的方式各有差異，請以目前版本的實際設定為準。開啟 TUN 本身不會提升節點頻寬，主要用途是透明接管流量。

調整 DNS：適用於解析等待，不能取代頻寬排查

DNS 主要影響網域解析、位址選擇及部分分流判斷。如果連線建立後能持續高速下載，但每次首次開啟網域都要等待，DNS 才是優先檢查項目。反過來說，若持續傳輸速度穩定但偏慢，通常無法單靠更換 DNS 伺服器解決。

檢查目前生效的設定，不要只看訂閱原始內容

• 確認用戶端是否透過覆寫或合併功能修改 dns；實際執行的設定可能與訂閱檔案不同。
• 確認 DNS 上游伺服器可連線；若使用加密 DNS，也要檢查連線是否逾時。
• 使用 mihomo 的 respect-rules 等選項時，請確認 DNS 請求如何分流，以及代理伺服器的網域能否獨立解析，避免形成依賴循環。
• 若使用 fake-ip，部分應用程式取得對應位址是預期行為；切換模式後請重新啟動測試中的應用程式，避免舊快取造成干擾。

在 Windows 終端機執行 ipconfig /flushdns 可清除系統 DNS 快取，但不會同步清除瀏覽器快取或核心本身的 DNS 快取。清除後首次請求變慢，也可能只是重新解析所致，不能只比較這一次請求。

IPv6 也應透過比較來排查，不要直接永久關閉。若記錄顯示 IPv6 連線反覆逾時，而 IPv4 正常，可暫時限制 IPv6 解析或連線進行驗證。作業系統、用戶端與 DNS 層的相關開關並非同一項設定。驗證完成後請還原，再針對實際故障修正設定。

並行設定：區分連線競速與多執行緒下載

mihomo 的 tcp-concurrent 用於對網域解析所得的多個位址進行 TCP 連線競速。這可能縮短部分目標的連線等待時間，但不會成倍提高節點頻寬上限，也不等同於增加檔案下載執行緒。舊版 Clash 或其他核心不一定支援同名選項，請先確認用戶端顯示的核心版本及對應文件。

# mihomo 頂層設定片段，請合併至現有設定
tcp-concurrent: true

這不是完整設定檔。只有確認核心支援，且懷疑多個位址造成連線等待時，才進行 A/B 測試。若訂閱由遠端維護，請優先使用用戶端提供的持久化覆寫功能；直接編輯訂閱快取，下次更新時可能會還原。套用後查看記錄，確認欄位已生效，再比較首次回應時間。

逐步增加下載工具的連線數

針對允許分段下載的資源，可依序測試 1、4、8 個連線。若單一連線為 1 MB/s，4 個連線合計約 4 MB/s，表示增加並行連線緩解了單一連線的限制，但仍無法確定限制來自來源站、線路或節點。若 8 個連線比 4 個更慢，或網頁回應明顯變差，就應降低連線數，不必繼續增加執行緒。

也要留意裝置資源使用狀況。Windows 11 可在「工作管理員」→「詳細資料」查看代理核心程序；macOS 可在「活動監視器」檢查 CPU 與網路使用量。測速時若核心 CPU 持續滿載、裝置過熱或路由器負載過高，都可能形成傳輸瓶頸；CPU 使用率低，也無法單獨證明線路正常。

整理結論：保留能重複驗證的設定

完成排查後，結論應描述具體條件，例如「同一節點使用手機熱點正常，家用有線網路在晚間變慢」，而不是「Clash 不穩定」。前者能繼續定位線路問題，後者無法指引下一步。

1. 只有少數節點速度慢：保留相同目標的比較結果，改用表現穩定的節點，並向訂閱提供者回報發生時間與線路名稱。
2. 同一網路整體變慢：先處理上傳流量占用、無線連線與路由器負載，再評估電信業者的路由。
3. 只有 TUN 模式速度慢：依序測試路由衝突、DNS 接管與 MTU，不要同時修改多個參數。
4. 只有首次開啟時變慢：優先檢查 DNS 解析與連線建立；若持續下載很慢，則回頭比較節點、線路與來源站。
5. 修改設定後沒有穩定改善：還原原值、移除暫時的除錯設定，只保留最少且原因明確的修改。

回報問題時，請附上用戶端版本、核心名稱與版本、作業系統、網路類型、發生時段、代理模式，以及三次測試結果。記錄只保留必要片段，並隱藏訂閱連結、存取權杖、節點密碼及其他憑證。連接埠與接管方式可參閱連接埠排查說明；初次設定則可從系統代理設定步驟開始檢查。