Clash 網速慢怎麼排查：節點品質、線路路由與本機設定三層診斷

先固定測試條件：分別記錄延遲、首位元組時間與下載速度

Clash 面板顯示的延遲不等於頻寬。一次 URL 延遲測試，反映的是透過該節點連線至指定測試網址所需的回應時間；實際計時範圍取決於用戶端與核心的實作方式。這項數據無法證明大型檔案的下載速度，也不代表瀏覽所有網站的體驗。若遇到「節點延遲只有 80 ms，影片卻一直緩衝」，就該分別觀察連線建立、首位元組時間與持續傳輸速度，而不是只按延遲排序。

本文適用於使用 Clash 或 mihomo 核心的用戶端。Clash Meta 是 mihomo 曾使用的名稱；不同核心版本支援的協定、DNS 欄位及 TUN 選項不盡相同。開始排查前，先記下用戶端與核心版本，並備份目前的設定。排查期間請固定訂閱、測試網址和用戶端版本，不要同時更新核心、更換 DNS 或切換節點。

建立可重現的測試紀錄

• 固定環境：使用同一台裝置、同一個網路和同一個下載網址。暫停雲端硬碟同步、系統更新及其他大量傳輸工作。
• 固定策略：在實際套用的代理群組中選定一個節點，避免自動測速或負載平衡群組在測試期間切換節點。
• 固定次數：每種條件連續測試 3 次，記錄中位數；持續下載至少觀察 30 秒。測試可能會耗用較多流量。
• 固定指標：記錄測試時間、目標網域、規則、代理鏈、延遲、下載速度，以及傳輸途中是否停頓。

表格數值僅示範如何記錄與判讀，並非本站實測結果。請留意單位：8 MB/s 約等於 64 Mbps，實際速度還會受到協定額外負載影響。寬頻標示 100 Mbps，不代表下載工具會顯示 100 MB/s。

第一層：檢查節點品質，分辨單一節點問題與目標網站限速

先從同一份訂閱中挑選 2～3 個節點，測試同一個目標。節點名稱標示的地區不一定是入口位置，也不保證出口路徑與名稱相符。挑選備用節點時，優先比較入口或線路不同的節點，而不只是名稱不同、實際共用同一入口的節點。

延遲測試逾時，不代表節點完全無法使用

測試網址無法連線、目標拒絕存取或 TLS 交握失敗，都可能造成逾時。先檢查測試 URL，再用瀏覽器開啟實際使用的網站。反過來說，測速網址能快速回應，只能證明這次特定請求成功，無法保證影片分段、下載網域和登入介面都正常。

1. 在用戶端的「代理」頁面手動選取節點，接著到「連線」頁面確認新請求確實經過該節點。頁面名稱請以目前使用的用戶端版本為準。
2. 使用同一個 HTTPS 檔案網址測試 3 次，再換另一個獨立網站測試。若只有單一網站速度慢、其他網站正常，優先檢查網站限速、CDN 或出口互連。
3. 分別記錄晚間尖峰與離峰時段的結果。若同一個節點只有晚間持續降速，應優先檢查節點容量或共用線路壅塞，而非本機設定。
4. 切換節點後，請重新建立測試連線。既有的 HTTP/2、HTTP/3 或下載連線可能仍沿用原本的路徑；必要時只關閉相關測試連線。

使用明確指定代理的請求，排除瀏覽器因素

以下 Windows PowerShell 指令會透過本機 HTTP 代理連線至範例網站，供你觀察首位元組時間與總耗時。7890 是範例連接埠，執行前必須換成用戶端顯示的 HTTP 或 mixed 監聽連接埠；並非所有用戶端都預設使用這個連接埠。這個小型網頁請求只用來檢查連線過程，不能用來評估最高頻寬。

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

這裡的 time_connect 主要反映連線至本機代理所需的時間，不能視為遠端節點延遲。透過 HTTP 代理連線至 HTTPS 時，後續計時還包含代理通道與目標網站 TLS 交握等階段。macOS 和 Linux 可使用 curl，並將 NUL 改為 /dev/null。若指令執行正常、瀏覽器卻卡頓，應接著檢查瀏覽器擴充功能、快取和安全 DNS，不要立刻更換訂閱。

第二層：檢查線路路由，先確認規則，再比較網路入口

「已選好節點」不代表所有應用程式都會使用它。規則模式下，連線會先依規則比對，再交由對應策略或代理群組處理。若只在總開關中選了某個節點，但目標請求實際命中另一個群組，測速結果就沒有比較價值。尤其要留意下載網域、影片分段網域和網頁主網域可能分別命中不同規則。

核對連線紀錄中的三個欄位

• 目標：檢查網域、目標 IP 和應用程式是否符合目前的測試工作，避免看錯背景更新請求。
• 規則：查看命中的規則類型與內容，例如 DOMAIN-SUFFIX、GEOIP 或最後套用的 MATCH。
• 代理鏈：確認最終使用的是預期節點，而不是 DIRECT、其他策略群組，或自動群組剛選出的另一個節點。

可以暫時切換至全域模式，並在全域群組中手動選定同一個節點進行比較。若全域模式明顯恢復正常，而規則模式持續變慢，優先檢查群組選擇與規則順序。全域模式只會改變已進入核心的流量處理方式，不會自動接管未使用系統代理的程式，也不能取代 TUN。測試後請切回規則模式，避免改變日常連線路徑。

交叉測試家用寬頻與手機熱點

保持節點和測試目標不變，將電腦從家用寬頻切換至手機熱點。若熱點連線穩定、家用寬頻卻很慢，問題可能出在本機無線連線、路由器、網路接取，或電信業者到節點入口的路徑。接著改用網路線取代 Wi-Fi：若有線連線恢復正常、無線仍然很慢，應優先處理無線干擾與訊號問題，不必繼續修改代理規則。

Windows 可先執行 ipconfig 找出目前的預設閘道，再執行 ping -n 30 192.168.1.1；此處的 IP 僅為範例，必須換成實際閘道。若本機閘道已出現明顯封包遺失，或反覆抖動且延遲達數十毫秒，應先暫停調整代理設定。不過，部分路由器會降低 ICMP 回應的優先順序，不能只憑一次 ping 結果就判定線路故障。

第三層：檢查本機設定，確認系統代理、TUN 與連接埠

系統代理需要應用程式主動使用作業系統的代理設定。部分命令列工具、遊戲和採用自有網路堆疊的程式不會遵循這項設定。TUN 會透過虛擬網卡和路由規則接管符合條件的 IP 流量，但仍可能受路由排除項目、權限和其他 VPN 影響。支援的用戶端可以同時啟用兩者；遇到異常時，應逐項關閉以隔離問題，而非預設兩者必然衝突。

逐項測試流量接管方式

1. 先測試明確指定代理：使用前面的 curl 指令直接連線至本機代理連接埠，排除系統代理開關是否生效的影響。
2. 接著測試系統代理：暫時關閉 TUN，開啟系統代理，再用支援系統代理的瀏覽器存取同一個目標。Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」，確認手動代理的位址與連接埠。
3. 最後測試 TUN：暫時關閉系統代理，依照用戶端要求安裝服務或授予權限後，再開啟 TUN。確認測試連線出現在核心的連線清單中，再比較速度。
4. 隔離其他流量接管程式：逐一結束其他 VPN、代理用戶端和網路加速工具。若是受企業安全政策管理的裝置，請先聯絡管理員，不要直接移除驅動程式或停用防護。

檢查連接埠衝突與資源使用情形

若用戶端記錄顯示監聽失敗，先確認連接埠是否已被使用。在 Windows 執行 netstat -ano | findstr :7890，查看是否有本機位址的連接埠正好是 7890 的 LISTENING 項目，再依 PID 到工作管理員確認是哪個程序。不要看到符合的項目就直接結束程序；它也可能是其他連線或相近的連接埠。變更用戶端監聽連接埠後，也要同步更新系統代理和明確指定代理的指令。

下載期間也要觀察工作管理員中的 CPU、記憶體和網路使用情形。若某個邏輯處理器持續接近 100%，吞吐量可能受本機處理能力限制；即使整體 CPU 平均使用率不高，也不能完全排除單一執行緒的瓶頸。長期使用 debug 記錄等級會增加記錄量，排查完畢後可恢復日常等級。比較核心版本或 TUN 網路堆疊前，請先保留原設定和回復方式。

DNS 與協定細節：分別處理初次連線慢、影片卡頓和間歇停頓

DNS 問題常見的現象是首次開啟網站要等很久，但連線建立後下載正常；持續低速則未必和 DNS 有關。先查看連線記錄是否反覆出現解析逾時，並分辨問題發生在網域解析、連線至遠端，還是 TLS 交握階段。換成另一個公共 DNS 伺服器，不代表請求一定會經過代理，也不保證線路會更快。

檢查 Fake-IP 與 nameserver-policy 的範圍

在 mihomo 中，dns.enhanced-mode: fake-ip 會透過虛擬位址對應協助核心還原網域名稱，並不是用來提升頻寬的選項。nameserver-policy 可為符合條件的網域指定解析器；它控制的是 DNS 解析策略，不等同於實際流量的代理規則。若 DNS 上游使用網域名稱，還要確認上游位址本身的解析方式與連線可達性，避免形成相依循環。

• 瀏覽器啟用安全 DNS 時，DNS 請求可能會走與系統 DNS 不同的路徑。可暫時關閉瀏覽器的安全 DNS 進行比較，記錄結果後再恢復原設定。
• TUN 的 DNS 劫持設定只會接管規則涵蓋的 DNS 流量。常見的 53 連接埠劫持，不代表能直接改寫所有應用程式內的 DoH 請求。
• 變更 DNS 後，請重新建立測試連線。Windows 的 ipconfig /flushdns 只會清除系統解析快取，不等於清空瀏覽器、應用程式和核心的所有快取。
• IPv6 的 DNS 紀錄、系統路由與代理支援應一併檢查。只在設定中變更一個開關，無法證明應用程式的 IPv6 流量已由代理接管。

將 UDP、QUIC 與 MTU 列為後續排查項目

瀏覽器可能會使用以 UDP 為基礎的 HTTP/3。若目前節點、協定或流量接管路徑的 UDP 支援不完整，部分網站可能反覆切換協定或載入異常。應先查看用戶端記錄和瀏覽器網路資訊確認狀況，再只針對該瀏覽器或目標網站暫時改用 TCP 測試；不要為了一個網站就全域封鎖 UDP。

若小型網頁載入正常，但大型檔案、特定 HTTPS 請求或 TUN 模式頻繁停頓，且已排除節點與規則問題，可進一步檢查路徑 MTU 或通道封裝。只有在這種情況下，才考慮以原值為基礎，暫時將 TUN MTU 調整為 1400 進行比較；這是供診斷使用的候選數值，並非通用的最佳設定。若沒有改善就恢復原值，不要把任意降低 MTU 當成日常加速手段。欄位支援情況與生效方式請以目前核心文件為準，也可參考協定手冊。

整理排查結果：依現象決定下一步，別持續疊加設定

每次只變更一個條件，測試後記下「改了什麼、結果如何、是否已恢復」。確認問題後，撤銷暫時使用的全域模式、測試用 DNS 和實驗性 MTU，只保留能解釋問題的最小變更。需要回報問題時，請提供用戶端與核心版本、作業系統版本、接管模式、測試時段及已隱去敏感資訊的錯誤記錄；不要公開訂閱網址、節點密碼或控制介面金鑰。

若舊版用戶端已不適用於目前的系統，請先透過用戶端比較確認平台與核心，再依照使用指南重新建立最精簡可用的設定。更換用戶端或許能解決部分相容性問題，但不能取代節點、線路和本機設定的交叉測試。