Clash 網速慢怎麼排查：從節點、線路到本機設定逐層檢查

先固定測試條件：分辨延遲、吞吐量與網頁載入時間

排查時先確認流量路徑，再比較節點與線路，最後檢查本機流量接管和 DNS。Clash 面板顯示的毫秒數不等於下載速度。節點延遲通常是對指定測試位址發出一次請求所得的結果，也會受到連線重複使用、目標網站和測試方式影響，不能直接代表大檔案的傳輸能力。

先把「慢」描述成可重現的現象，例如「同一部影片以 1080p 播放時經常緩衝」、「網頁第一次開啟要等 5 秒，重新整理就很快」，或「下載前幾秒正常，之後速度持續下降」。這些情況的檢查重點不同，不宜同時修改規則、DNS 和 TUN。

建立一組可重複測試的紀錄

• 記下用戶端版本，以及實際核心的名稱與版本。用戶端介面版本不等於 mihomo 核心版本。
• 固定一個下載檔案、一個網頁和一個節點，暫停雲端硬碟同步、系統更新及其他測速工作。
• 每輪測試 30～60 秒，重複三次；記下測試時間、網路類型、節點、命中規則和持續傳輸速度。
• 留意單位換算：100 Mbps 理論上相當於 12.5 MB/s，實際應用程式的吞吐量還要扣除協定負擔。

第一層：確認節點能否持續傳輸

開啟用戶端的「代理」或「代理群組」頁面，先選定一個具體節點。自動選擇群組可能在測試期間切換成員，讓兩次結果看似使用同一策略群組，實際上卻走了不同出口。記下最後使用的節點名稱，比只記「自動選擇」更有用。

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

假設節點 A 的測試延遲為 45 ms、節點 B 為 120 ms，仍不能據此判定 A 播放影片的體驗較好。A 可能有頻寬限制或出口壅塞，B 則可能有更穩定的持續吞吐量。這些數字僅用來說明比較方式，並非本站實測結果。

1. 在同一個手動選擇群組中選取節點 A，連線至固定目標，記錄三次持續傳輸速度。
2. 只切換至節點 B，不改變模式、不更換 DNS，重複相同測試。
3. 再換一個來源獨立的下載目標。如果只有某個網站速度慢，優先考慮目標 CDN、帳號限速，或出口與該網站之間的互連狀況。
4. 檢查訂閱服務的剩餘流量、到期日和裝置數量限制。設定能匯入，不代表伺服器端仍允許正常使用。

不要同時對所有節點進行大量流量測速。並行測速會占用本機頻寬，也可能耗掉訂閱流量。節點清單中的連線測試適合快速篩除無法連線的項目；要比較吞吐量時，逐一測試更容易得到可解讀的結果。

更換協定時，保持伺服器條件一致

協定支援情況取決於核心、節點設定和伺服器端。只有服務商提供相應連線入口，才能比較不同協定；不能任意把訂閱中的類型欄位改成另一種協定。較公平的比較方式，是選擇同一服務商、相近地區、相同目標和時段，再比較其提供的不同入口。

如果某個使用 UDP 的入口在目前網路環境下表現異常，另一個 TCP 入口卻很穩定，這只能作為目前網路路徑存在差異的線索。原版 Clash、Clash Meta 和 mihomo 支援的協定並不完全相同；遇到「不支援的代理類型」時，應先確認核心，而不是反覆修改密碼或節點名稱。

第二層：分辨本機連線、跨網線路與出口壅塞

節點可以連線，但速度在晚上明顯下降，常見原因是某一段網路壅塞。完整路徑至少包含裝置到路由器、本地電信業者到節點，以及節點出口到目標網站。只測節點伺服器的延遲，無法涵蓋整條路徑。

用兩組對照縮小問題範圍

• 同一裝置更換網路：電腦分別連上家用寬頻和手機熱點，節點與目標保持不變。手機熱點正常、家用寬頻異常時，優先檢查寬頻路徑、路由器和 Wi-Fi。
• 同一網路更換時段：在離峰和晚間各測三次。如果多個節點都只在晚間尖峰時段變慢，接著比較不同服務商或不同接入線路。
• 同一出口更換目標：只有一個目標速度慢、其他目標正常時，檢查目標服務的區域導流、出口 IP 限制和 CDN 路徑。
• 同一網路改用有線連線：有線連線穩定、無線連線不穩時，先處理無線訊號和頻道干擾；切換節點無法解決無線鏈路的封包遺失。

Windows 可執行 ping -n 20 192.168.1.1，macOS 或 Linux 可執行 ping -c 20 192.168.1.1，觀察到本機閘道的連線穩定性。此處假設閘道位址為 192.168.1.1，實際位址請從系統網路設定查詢。若閘道不回應 ICMP，不能只憑逾時判定網路中斷。

tracert 或 traceroute 可提供路徑線索，但一般命令的流量不一定會經過應用程式代理，也不一定使用和影片相同的傳輸方式。中間路由器可能限制 ICMP 回應，因此某一跳沒有回應、後續跳數卻正常，不代表該節點正在丟棄應用程式流量。

第三層：檢查規則命中與應用程式接管

進入用戶端的「連線」頁面，部分介面稱為「活動連線」。清除篩選條件後，重新開啟目標網頁。重點查看目標網域或 IP、命中規則、策略鏈和最終出站。在規則模式下，規則會依序比對；一般規則清單中，前面的符合項目會影響後續規則是否有機會生效。

簡短比較規則模式與全域模式

1. 在「代理」頁面記下目前策略群組選用的節點。
2. 記下規則模式下目標連線的實際出站，確認沒有意外命中 DIRECT，也沒有選到另一個群組中的慢速節點。
3. 暫時切換至全域模式，並在全域策略中選擇相同節點。
4. 關閉目標應用程式的舊連線，再重新發出請求。切換模式後，既有連線不一定會立即改走新的路徑。
5. 測試後切回規則模式。如果全域模式正常、規則模式異常，優先修正規則和策略選擇。

全域模式不會自動接管裝置的所有流量。它決定的是流量進入核心後如何選擇出站；應用程式是否進入核心，仍取決於系統代理、應用程式本身的代理設定或 TUN 接管。瀏覽器正常、遊戲或命令列工具異常時，先檢查流量入口，不要先認定節點失效。

使用明確指定的代理，排除系統代理設定差異

以下使用本機 HTTP 或 mixed 代理連接埠 7890，請求一個小型網頁。先確認用戶端實際使用的連接埠；SOCKS 專用連接埠不能直接套用這個命令。Windows PowerShell 請使用 curl.exe，避免某些環境將 curl 解讀為其他命令；macOS 和 Linux 則使用 curl。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows 請將命令開頭改為 curl.exe，並把 /dev/null 改為 NUL。範例網址只適合確認請求是否完成，不適合用來測量頻寬。使用明確代理時，time_connect 主要反映連上本機代理所需的時間；首位元組時間還包括代理通道建立、遠端連線和伺服器回應，不能直接稱為「節點延遲」。

DNS 排查：首次開啟緩慢與解析路徑不一致

網頁第一次開啟較慢、重新整理後明顯變快時，DNS 是其中一個檢查方向，但 TLS 連線建立和網頁快取也可能造成類似現象。先在「日誌」頁面暫時將日誌層級調為 debug，重現一次問題，再搜尋目標網域是否有解析失敗、逾時或重複請求。完成後請恢復原本層級，避免大量日誌影響排查。

分辨系統解析與核心解析

系統執行 nslookup example.com 的結果，不一定等於 mihomo 內部使用的結果。瀏覽器可能啟用安全 DNS，核心可能啟用 fake-ip，TUN 也可能設定 DNS 劫持。應先確認由哪一層解析請求，再決定要在哪一層調整。

• 使用 fake-ip：常見的 198.18.0.0/16 是映射位址範圍，看到範圍內的位址不代表解析異常；應繼續檢查映射與連線是否正常。
• 啟用 DoH：必須能連線至解析器位址，解析器的連線路徑也必須暢通。不要讓代理節點網域的解析反過來依賴尚未建立的代理連線。
• 涉及 IPv6：檢查系統 IPv6 連線能力、目標 AAAA 記錄和流量接管設定。只在明確的對照測試中暫時關閉某一層的 IPv6，測試後再恢復。
• 修改訂閱設定：優先使用用戶端支援的覆寫或擴充機制；直接編輯訂閱產生的檔案，可能會在下次更新時被覆蓋。

不要一次照抄整套 DNS 設定。使用不同核心和版本時，必須確認 nameserver、proxy-server-nameserver 等欄位是否支援。更換解析器後，應重新建立目標連線；只重新整理網頁，未必能清除系統、瀏覽器和核心中的所有快取。

TUN 與本機效能：只在流量接管路徑異常時調整

TUN 透過虛擬網路介面接收流量，適合處理不遵循系統代理設定的應用程式，但它不是加速開關。如果明確指定代理時一切正常，啟用 TUN 後所有應用程式都變慢，應優先檢查路由、DNS 接管，以及與其他網路軟體的衝突。

依序檢查四個項目

1. 權限與服務：確認已具備用戶端要求的服務模式或管理員權限，並檢查日誌中是否有建立介面或新增路由失敗的訊息。
2. 重複接管：暫時退出其他 VPN 或代理用戶端，只保留一個流量接管入口後再測試。不要長期停用系統防火牆。
3. 程序資源占用：在 Windows「工作管理員」或 macOS「活動監視器」檢查用戶端和核心程序。如果傳輸期間某個核心持續滿載，再比較日誌層級、規則數量和核心版本。
4. MTU 與 UDP：如果小型網頁正常、大量傳輸卻卡住，或只有使用 QUIC 的應用程式異常，再檢查路徑 MTU、UDP 轉送能力及相關日誌。不要把某個固定 MTU 值當成適用所有網路的通用解法。

如果瀏覽器支援相關設定，可暫時關閉 QUIC，完全退出後重新啟動，觀察 TCP 路徑是否改善。若有改善，只能表示 UDP 路徑值得進一步檢查，不能證明某種協定一定比較快。測試完成後請恢復原設定，避免把暫時的診斷措施留作長期設定。

結尾：依據測試結果處理，勿連續疊加設定

需要回報問題時，請提供用戶端與核心版本、作業系統、網路類型、發生時間、重現步驟和已移除敏感資訊的日誌。分享前請移除訂閱網址、存取權杖、節點密碼及管理介面金鑰；不要直接公開整份設定。

選擇用戶端可參考選型指南；系統代理和 TUN 的基本設定請見使用說明。最終目標是找出可重複驗證的差異：是哪個節點、哪段網路、哪條規則或哪種接管方式導致速度變慢。確認原因後，只保留必要的變更，再用一開始的測試目標重新測試。