Clash 網速慢怎麼排查？從節點、線路到本機設定的三層檢查法

先固定測試條件，分清延遲與傳輸速度

Clash 節點旁的延遲數字，只代表一次探測請求所花的時間，不能反映持續下載速度，也不代表影音平台、程式碼儲存庫和網頁會走同一條線路。若出現「延遲 80 毫秒，下載速度卻只有 200 KB/s」的情況，先記錄實際連線，再決定要檢查哪一層。

本文的 TUN 設定以使用 mihomo 核心的用戶端為討論對象。傳統 Clash 核心和不同用戶端提供的選項不盡相同。開始前，請在用戶端的「關於」或「核心」頁面記下用戶端名稱、版本、核心版本及目前的設定檔名稱，避免直接套用其他核心的設定欄位。

建立可重現的基準測試

1. 暫停雲端硬碟同步、系統更新及其他大型檔案下載。電腦盡量使用有線網路；使用 Wi-Fi 時，固定測試位置與頻段。
2. 選擇一個穩定的直連網站，以及一個需要代理的目標。每次使用相同檔案和相同測試時間，不要每輪更換測速伺服器。
3. 保持規則模式與策略群組不變，手動選定節點。每種條件測試 3 次，每次 30 秒，記錄中位數。
4. 記錄開始載入所需時間、穩定下載速度、是否中斷，以及連線面板顯示的規則、策略群組和最終節點。

下表僅示範記錄方式，不代表任何特定服務的實測結果。實際排查時，請填入同一台裝置以同一測試資源測得的結果。

第一層：確認節點與實際出站

先查看連線面板，再切換節點

在用戶端的「連線」面板找到正在下載的請求，核對目標網域、符合的規則、策略鏈及出站節點。只更改策略群組中的節點，不一定會改變已建立連線的出口；瀏覽器長連線、影音連線和下載工作可能仍沿用舊連線。

每次切換後，停止並重新啟動測試。必要時只關閉該測試對應的連線；遠端桌面或會議進行中，請勿清除所有連線。若面板顯示 DIRECT，問題就不是所選代理節點的傳輸速度，應先檢查規則是否命中。

• 只有單一節點速度慢：在同一個策略群組中比較 2～3 個節點。若只有一個節點持續低速，優先懷疑該節點負載過高、受到限速或出口品質不佳。
• 自動選擇群組反覆切換：暫時改用手動選擇群組完成測試。url-test 主要依探測延遲選擇節點，不等於測試頻寬。
• 只有單一網站速度慢：改用另一個目標資源重測。網站限速、CDN 調度，以及節點出口與目標網站之間的網路互連，都可能影響速度。

僅短時間對照規則模式與全域模式

若懷疑目標被錯誤地設為直連，可短暫切換至全域模式，並明確選擇 GLOBAL 出站，再重新建立測試連線。若全域模式恢復正常、規則模式仍然緩慢，請切回規則模式，檢查網域規則、規則集更新狀態及策略群組指向。全域模式不會提高節點本身的頻寬，也不保證接管未經用戶端的流量。

不要為了測速就立刻改寫訂閱中的所有規則。先記下命中的規則，再使用用戶端支援的本機覆寫修正目標網域。直接編輯訂閱產生的設定檔，可能會在下次更新時被覆蓋。

第二層：比對接入網路與遠端線路

節點名稱中的地區資訊通常無法反映完整傳輸路徑。連線可能先經過入口伺服器或中繼，再從另一個出口連至目標。用戶端的連線面板可以確認選用的出站節點，但未必會顯示伺服器端的所有中繼路徑。

交叉測試，縮小問題範圍

1. 網路相同、切換節點：固定使用家用網路，只切換節點。若某一組入口都慢、其他入口正常，記錄這些節點的共同特徵。
2. 節點相同、更換網路：維持節點與目標不變，從家用寬頻切換至手機熱點。先暫停大量流量工作，以免消耗過多行動數據。
3. 條件相同、更換時段：分別在離峰時段與晚間重測。若只有晚間速度下降，較應留意接入網路、入口或中繼線路是否壅塞。

若節點 A 在家用網路下速度慢、使用手機熱點時正常，而節點 B 在兩種網路下都正常，問題較可能出在「家用網路連往 A 的路徑」，不能據此認定 A 的伺服器頻寬不足。若所有節點在兩種網路下都慢，但直連下載正常，請再檢查用戶端、本機代理鏈或測試目標是否有限制。

分別看 Ping、路由追蹤與下載速度

對代理入口執行 Ping 或路由追蹤，只能取得部分網路線索。中間路由器可能限制 ICMP 回應；若某一跳顯示封包遺失，但後續終點沒有相同程度的遺失，通常不能直接判定該節點正在丟棄轉送流量。一般路由追蹤也無法顯示加密代理連線內部的伺服器中繼路徑。

回報線路問題時，請附上時間與時區、接入電信業者、節點名稱、目標網域、三輪測試結果及切換網路後的結果。不要只提供延遲清單。分享記錄前，請刪除訂閱網址、權杖、節點密碼及個人瀏覽記錄。

第三層：排除系統代理、TUN 與本機衝突

先確認本機監聽連接埠

系統代理通常會將遵循系統設定的應用程式導向本機 HTTP 代理；TUN 則透過虛擬網卡與路由接管流量。特定設定下兩者可以同時運作，但排查時應分開測試，避免同時變更入口和路由。以下以實際設定中有 mixed-port: 7890 為例；7890 並非所有用戶端的固定連接埠。

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

在 Windows PowerShell 中執行下列命令，先確認連接埠正在監聽，再明確指定代理發出請求。此請求用來檢查連線路徑與回應時間，不適合測量大型檔案的頻寬。

Get-NetTCPConnection -LocalPort 7890 -State Listen

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/

命令中的連接埠請與用戶端實際使用的連接埠一致。這裡的 time_connect 主要反映連上本機代理所需的時間，不能當作節點往返延遲；time_starttransfer 則包含後續代理協商、TLS 與伺服器回應等階段。請比較相同請求的變化，不要將單一欄位直接歸因於 DNS。

依序對系統代理與 TUN 進行 A/B 測試

1. 關閉 TUN，只啟用系統代理，使用明確支援 HTTP 代理的瀏覽器或上述命令進行測試。
2. 記錄結果後關閉系統代理，再啟用 TUN，重新連線至相同目標，並確認連線面板確實顯示該請求。
3. 若只有 TUN 速度慢，請檢查是否同時啟用了其他 VPN、網路加速器或虛擬網卡工具。逐一暫停後重測，不要一次關閉多項安全功能。
4. 若 TUN 無法啟動，請先處理服務權限、虛擬網卡或建立路由時發生的錯誤。啟動失敗與傳輸速度偏低是兩種不同問題。

mihomo 的 TUN 堆疊選項包括 system、gvisor 和 mixed，可用性與行為會因平台及核心版本而異。mixed 通常會搭配 system TCP 與 gVisor UDP。沒有一種堆疊適用於所有裝置並且「速度最快」；每次只變更一個選項，重新啟動相關核心後，再用相同工作重測。

DNS 與 UDP：分辨網頁開啟慢、下載慢和影音卡頓

首次開啟速度慢，先檢查 DNS 解析

若首次連線停頓數秒，重新整理後便立即恢復，但檔案開始下載後速度正常，應優先檢查 DNS 解析逾時及建立連線的階段。查看記錄是否持續出現 DNS 逾時，以及不同解析器是否將目標網域解析至差異很大的 CDN 位址。瀏覽器快取和連線重複使用也可能讓「第二次比較快」，不能只憑這種現象就認定是 DNS 故障。

enhanced-mode: fake-ip 透過虛擬位址對應協助辨識網域，不會直接增加節點頻寬。nameserver-policy 用來為指定網域選擇解析器，並非出站策略群組。調整時也要確認解析器是否可連線、回傳位址是否適合目前的出口，以及 DNS 請求實際經過的路由。

• 瀏覽器的安全 DNS 可能使用自己的 DoH 通道，繞過系統 DNS。診斷時請記錄其狀態，必要時可短暫關閉作為對照，測試完成後再恢復。
• TUN 的 dns-hijack 常用來接管傳統的 53 埠請求，但不能據此認定所有 DoH、DoT 流量都會被接管。
• 切換 fake-ip 與真實位址解析模式後，請依用戶端支援的方式清除相關 DNS 快取並重新建立測試連線，避免舊位址繼續影響結果。

影音卡頓時，檢查 UDP 與 QUIC

網頁和下載正常，但影音、語音或遊戲異常時，應另外檢查 UDP。瀏覽器可能使用以 UDP 為基礎的 QUIC，節點和伺服器端也必須支援相應的轉送路徑。請透過用戶端連線面板確認是否有 UDP 請求，再以用戶端或瀏覽器支援的方式暫時停用 QUIC 作為對照，觀察改用 TCP 後是否有所變化。

若停用後恢復正常，只能說明 UDP 路徑值得進一步檢查，不能因此推論所有 UDP 都應長期封鎖。同樣地，不要把停用 IPv6 當成通用的加速方法。先確認 AAAA 解析結果、IPv6 預設路由和代理接管狀態是否一致，再決定是否暫時限制位址家族進行測試。

依據測試結果縮小範圍，並保留可還原的設定

完成三層對照後，將問題縮小到最可能的範圍。下列對應關係可用來決定下一步，不代表能取代伺服器端或網路端的進一步診斷。

保留原始設定或匯出備份，記錄每次修改的欄位、時間與結果。若問題是更新後才出現，先還原該項設定確認，再考慮更新用戶端或核心。排查完成後，恢復日常使用的規則模式、必要的安全設定及記錄層級，避免長期使用臨時測試設定。