Clash 速度慢如何排查：從節點、線路到本機設定逐層檢查

先區分高延遲、低吞吐量與連線卡頓

Clash 速度慢不一定是單一故障。網頁第一次開啟很慢，可能是 DNS 解析或建立連線耗時；下載速度持續只有幾百 KB/s，較可能是吞吐量受限；影片一開始播放順暢、幾分鐘後卻開始緩衝，則要檢查線路波動、出口壅塞，以及應用程式實際使用的連線。先記錄症狀再調整設定，避免一次引入多個變因。

Clash 是代理核心，mihomo 則是沿著 Clash Meta 路線發展的相容核心。桌面或行動裝置用戶端也負責介面、系統代理與設定管理。相同設定在不同用戶端中的位置可能不同，因此排查時應記下用戶端名稱、用戶端版本與核心版本，不要只寫「已安裝最新版」。

建立基準：固定測試目標、時段與連線方式

測速按鈕通常只測試指定網址的回應時間，不代表所有網站都能正常使用，也不是頻寬測試。自動選擇策略組可能在測試期間切換節點。排查時先切換到可手動選擇節點的策略組並固定節點，暫停背景下載與雲端硬碟同步，再進行比較。

1. 記錄原始狀態。備份設定，記下規則模式、系統代理、TUN 開關與目前的出口節點。確認只執行一個代理用戶端。
2. 測試本機網路。在可直接連線的可信任下載網站測試一次。如果直接連線也很慢，先比較有線網路、靠近路由器的 Wi-Fi 與手機熱點。
3. 固定代理測試目標。選擇允許測速、檔案夠大的 HTTPS 下載資源。每次測試約 30 秒，忽略前 5 秒的波動，連續測試 3 次。
4. 記錄應用程式實際連線路徑。在用戶端的「連線」頁面搜尋目標網域，確認請求進入預期的策略組，而不只是查看主畫面顯示的節點名稱。
5. 每輪只調整一個變因。更換節點時不要同時更改 DNS；測試 TUN 時不要同時改用手機熱點。每輪結束後關閉舊下載工作，再重新建立連線。

以下是記錄格式範例，並非本站實測結果。實際填寫時請使用自己的數據，並維持測試檔案、裝置與時段一致。不要用單次峰值代替整段測試結果。

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

延遲最低的節點，不一定下載最快

延遲測試反映的是小型請求的往返狀況。節點可能回應很快，但出口頻寬吃緊、並行連線限制較嚴，或通往目標網站的路徑不理想。反過來說，地理位置較遠的節點即使延遲稍高，也可能有更穩定的持續吞吐量。網頁互動與大型檔案下載應分開測試，不能只看延遲排序就下結論。

• 從同一份訂閱中挑選 2～3 個節點，優先比較不同入口或不同線路，而非只比較名稱相近的節點。
• 檢查訂閱服務的流量餘額、速率限制與到期狀態。更新訂閱可以更新節點資訊，但不會自動增加伺服器端頻寬。
• 確認策略組的巢狀關係。規則指向 Proxy 時，Proxy 可能又指向另一個自動選擇組；請展開策略組，確認最後使用的節點。
• 切換節點後，先關閉舊下載工作再重試。已建立的連線可能繼續使用原本的出口，不能把舊連線的結果當成新節點的測試結果。

避免自動切換影響比較結果

url-test 主要根據指定 URL 的延遲選擇路徑；fallback 著重依序選擇可用項目；load-balance 則可能將不同連線分配到不同節點。這三種策略組都不能直接證明某個節點的持續下載能力。若正在使用這類策略組，先透過現有的手動選擇組固定出口，再下載同一項資源進行測試。

如果只有某個節點速度慢，而其他節點在相同條件下正常，問題範圍就已縮小。此時反覆重裝用戶端、清除所有設定的幫助不大，應進一步確認該節點的入口與出口線路，或向訂閱服務提供具體的測試紀錄。

第二層：接入線路、出口路徑與尖峰壅塞

一次代理連線至少會經過本機至節點入口、節點轉送，以及出口至目標網站等數段路徑。節點名稱中的地區資訊通常不足以判斷入口電信業者或中轉方式。不同名稱的節點也可能共用入口；只換節點名稱、不換實際路徑，不一定能避開壅塞。

透過三種比較縮小問題範圍

1. 同一節點切換網路。比較家用寬頻與手機熱點。若手機熱點明顯改善，表示接入網路或該網路通往節點的路徑較值得懷疑，但還不能直接斷定是電信業者限速。
2. 同一網路比較不同時段。例如分別在 10:00 與 21:00 進行三輪測試。若多個晚上都出現類似降速，才較能支持尖峰壅塞的判斷。
3. 同一出口測試不同目標。比較兩個不同服務提供的合法下載資源。如果只有一個網站很慢，應考慮該網站的 CDN 節點分配、單一連線限制，或對代理出口採取的策略。

測速網站通常會使用多條連線，瀏覽器下載檔案則可能只用一條或少數幾條，因此兩者的數值不同並不少見。測速結果高、單一檔案下載卻慢時，應繼續比較單一連線的表現，而非直接認定用戶端「把速度吃掉了」。影音網站還會依據緩衝狀況與位元率調整下載節奏，不適合當作唯一的頻寬基準。

第三層：系統代理、規則與本機監聽連接埠

先確認應用程式是否經過用戶端

系統代理不會接管所有裝置流量。部分應用程式不會讀取系統代理，命令列工具也可能只使用自己的參數或環境變數。TUN 模式透過虛擬網路介面接管符合路由條件的流量，但仍受平台實作、路由與排除項目影響。瀏覽器正常、遊戲或命令列工具卻很慢時，應先檢查流量接管方式，不要立刻歸咎於節點。

以 Windows 11 為例，可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理伺服器位址與連接埠。以 macOS 13 及後續版本為例，可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」檢查。用戶端啟用系統代理後通常會自動填入這些資訊；手動修改前請先記下原值。

以下是監聽設定片段，並非完整設定。7890 只是範例值，測試時應確認用戶端實際使用的連接埠；部分用戶端會由介面產生設定，直接編輯訂閱檔案可能在下次更新後被覆寫。

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

mixed-port 可透過同一個連接埠接收 HTTP 與 SOCKS 代理請求。如果應用程式仍指向舊連接埠，可能會連線失敗，或在失敗後改為直接連線。allow-lan: false 用於限制區域網路存取，修改它不會提升本機網速。

在規則模式下確認實際命中結果

在用戶端的「連線」頁面查看網域、目標 IP、命中規則與出口路徑。若中國大陸的下載網站被送進代理，速度可能反而變慢；應經代理的目標若命中 DIRECT，也可能長時間等待。規則通常依序比對，前面的寬泛規則可能蓋過後面的細部規則。訂閱中的策略組名稱必須與規則引用的名稱一致。

可以短暫切換全域模式進行比較，但它只適合用來診斷。全域模式正常、規則模式卻很慢時，應優先檢查規則與策略組，而非長期使用全域模式掩蓋問題。欄位用途請參閱代理模式說明與連接埠說明。

DNS、TUN 與裝置負載的個別檢查

DNS 主要用來解釋「開啟很慢」，不適用於所有速度問題

DNS 解析發生在建立連線之前，快取與重複使用連線可能讓第二次瀏覽變快。若頁面要等幾秒才開始載入，但開始下載後速度正常，應依照時間順序檢查解析與建立連線的耗時。反過來說，已建立的長連線持續低速，單純更換 DNS 通常無法解決。

• 檢查系統、瀏覽器的安全 DNS 與用戶端 DNS 是否各自設有不同設定。瀏覽器內建的加密 DNS 可能不會依照用戶端預期的解析流程運作。
• 使用 fake-ip 時，系統查詢到映射位址不代表解析失敗。例如 198.18.0.0/16 範圍可作為 fake-ip 位址池，須搭配實際設定判斷。
• 若懷疑 IPv6 路徑異常，可暫時比較 IPv4 與 IPv6，並記下還原方式。不要只因為單一網站很慢，就永久關閉整個系統的 IPv6。

切換 TUN 時一次只改一個變因

先在系統代理模式下測試明確支援 HTTP 代理的瀏覽器，再維持節點與目標不變，改用 TUN 測試。若只有 TUN 模式變慢，請檢查其他 VPN、虛擬機器網路、路由衝突與用戶端記錄。切換流量接管方式後，須確認目標仍經由同一個出口，否則兩輪結果不能直接比較。

MTU 不匹配可能造成小型請求正常、大型回應卡住，但不能只憑這個現象就下定論。不要照抄網路上的「通用最佳 MTU」。確實需要驗證時，先記下原值，在支援相關設定的用戶端中一次調整一項，重新建立連線並再次測試；若沒有改善就還原。TUN 的 stack 支援狀況與行為也會隨平台及核心版本改變，不宜宣稱某一種堆疊一定比較快。

CPU 滿載與記錄寫入也會影響吞吐量

在 Windows 的「工作管理員」→「效能」→「CPU」中，可將圖表切換為邏輯處理器；在 macOS 的「活動監視器」→「CPU」中查看用戶端與核心程序。即使整體使用率不高，某個核心仍可能接近滿載。舊型裝置、複雜規則與大量並行連線都可能增加處理負擔。

日常診斷先使用 info 記錄等級，需要更多細節時才短暫切換至 debug，重現一次問題後再恢復。持續大量寫入除錯記錄會增加負擔，也可能記錄敏感的瀏覽資訊。提交資料前，請遮蔽訂閱連結、權杖、節點密碼與個人網域。

依照測試結果收尾：保留證據並還原臨時設定

排查結束時，應能整理出可重現的結論，例如「同一個檔案、同一個網路，節點 A 連續三次約 1 MB/s，節點 B 約 7 MB/s」，而不只是「晚上很卡」。數值僅為範例，重點是記錄完整條件並能重複得到相近結果。向服務提供者回報時，附上含時區的發生時間、接入電信業者、節點識別資訊、用戶端與核心版本即可，請勿傳送完整訂閱內容。

最後還原臨時使用的全域模式、除錯記錄與網路參數，並確認更新訂閱後設定仍如預期生效。測速會消耗實際流量，使用手機熱點或計量型服務時請控制測試時間。若仍無法找出問題，可依照連線故障說明繼續檢查，或回到使用指南確認基本設定流程。