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

開始前：分辨網頁開啟慢、下載慢與連線中斷

「Clash 網速慢」可能代表三種不同情況：網頁第一次開啟要等很久、下載速度一直偏低，或影片播放一段時間後就卡住。這些問題分別較可能與 DNS 解析及建立連線的耗時、持續傳輸能力，以及連線穩定度有關。先描述清楚症狀再調整設定，能避免做白工。

• 第一次開啟很慢，之後正常：優先檢查 DNS、建立連線所需時間與目標網站的回應，不要直接認定是節點頻寬不足。
• 大型檔案下載一直很慢：先比較不同節點和電信業者線路，也要確認伺服器是否限制單一連線的速度。
• 速度忽快忽慢、頻繁重新連線：檢查 Wi-Fi、封包遺失、節點負載，以及背景網路切換。
• 只有某個應用程式很慢：先確認該應用程式是否有走代理，以及實際命中哪一條規則。

固定測試條件

先暫停雲端硬碟同步、系統更新和其他下載。使用相同的測試目標、裝置與測試時間，每次只變更一個條件。建議每組測試做 3 次，每次觀察約 30 秒；若使用計量型網路，請先確認測試流量在可接受範圍內。

記下目前使用的用戶端名稱、核心類型、代理模式，以及系統代理和 TUN 的啟用狀態。Clash 是常見的用戶端生態系名稱，mihomo 則是由原 Clash.Meta 延續發展的核心。不同用戶端和核心支援的設定不盡相同，選單名稱也可能不同。

第一層：檢查節點品質，先看持續傳輸速度，再看延遲

代理頁面的延遲測試通常會透過指定 URL 探測節點是否可用，以及請求所需時間。結果會受測試網址、連線重用方式和用戶端實作影響，不能當成節點連線所有網站的速度排名。延遲顯示 60 ms 的節點，下載速度不一定比 180 ms 的節點快。

用兩個節點交叉比較

1. 進入用戶端的「代理」頁面，找到目標網站實際使用的策略組。若策略組內還有巢狀策略組，請繼續展開，確認最後使用的節點。
2. 選擇節點 A，重新建立目標連線，記錄首次回應時間、穩定下載速度，以及是否發生停頓。
3. 切換到節點 B，再建立新連線並以相同條件重測。既有連線可能仍會使用原本的出口，因此不能只切換節點，就盯著原來的下載工作看結果。
4. 切回節點 A 再測一次，排除目標伺服器剛好波動而造成的誤判。

例如，A 的探測延遲是 70 ms，但穩定下載速度只有 1.2 MB/s；B 的延遲是 160 ms，穩定下載速度卻有 7 MB/s。下載大型檔案時，B 會是較合適的選擇；互動式請求則還要看實際回應時間與延遲抖動。節點名稱中的地區和倍率只能作為選擇參考，不能證明實際網路路徑或可用頻寬。

節點層可以確認什麼

• 同一時間、同一網路下，只有一個節點速度慢：優先懷疑該節點的負載、入口、出口或對應路徑。
• 多個節點連線到同一網站都很慢，其他網站則正常：接著檢查目標服務、出口地區和規則，不要馬上重新安裝用戶端。
• 更新訂閱後速度有所變化：檢查節點是否遭到替換，以及策略組是否重新選擇。更新訂閱本身不會增加頻寬。

第二層：檢查電信業者線路，比較不同網路與時段

節點到本機的網路路徑會經過本地網路、電信業者網路與節點入口。節點名稱相同，不代表固定寬頻和行動數據會走相同路徑。夜間壅塞、跨網互連，以及中間路由變動，都可能導致速度下降。

依照以下順序逐步縮小範圍

1. 先排除本地無線網路問題：靠近路由器，或改用有線網路重測。訊號良好的 5 GHz Wi-Fi 通常更適合高速傳輸，但隔牆後的涵蓋範圍未必比 2.4 GHz 好。
2. 再更換連線網路：使用同一台電腦和同一個節點，改連手機熱點。請留意行動數據費用，並暫停電腦上的背景更新。
3. 最後比較不同時段：分別記錄白天和晚上的相同測試結果，不要直接比較不同日期或不同節點的數據。

假設同一節點在家用寬頻下只有 0.8 MB/s，改用手機熱點後達到 6 MB/s，這表示應優先檢查接入網路或沿途路徑，但還不能據此斷定某家電信業者刻意限速。改用熱點同時改變了接入方式、出口和路由，還需要進一步交叉比較。

可以使用系統的 ping 或路由追蹤工具檢查基本網路狀況，但這些工具的 ICMP 流量不一定會經過 HTTP 系統代理。節點入口也可能不回應 ICMP。單次逾時或中間某一跳延遲偏高，無法單獨證明代理連線有封包遺失；應搭配終點表現和實際服務傳輸狀況判斷。

第三層：檢查規則命中，確認速度慢的連線使用哪個出口

Clash 規則模式會依序比對連線，通常由第一條符合的規則決定使用的策略。訂閱中有節點，不代表所有應用程式都會使用該節點。目標可能命中 DIRECT，也可能進入與手動選擇不同的策略組。

從連線紀錄查看實際路徑

1. 開啟用戶端的「連線」頁面，再送出一次目標請求。若是長連線，先關閉對應頁面或暫停工作，再重新測試。
2. 依網域、目標 IP 或處理程序篩選，查看命中規則、策略鏈和最後使用的節點。部分用戶端需要展開連線詳細資訊才能查看完整內容。
3. 除了網頁主要網域，也要檢查資源網域。網頁能開啟，但圖片或影片載入很慢，可能是資源網域走了另一條規則。
4. 若連線頁沒有紀錄，先確認應用程式是否使用系統代理或由 TUN 接管。沒有紀錄也可能是因為連線結束得太快，或受到介面篩選條件影響。

確認目標確實進入用戶端後，可以暫時切換到全域模式，並明確選擇一個節點，重新建立連線進行比較。如果相同資源的速度明顯改善，應優先檢查原本的規則、策略組和出口差異。全域模式不會自動接管原本繞過用戶端的應用程式，也不能只憑一次改善就斷定規則檔案損壞。

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

以下 Windows PowerShell 指令假設用戶端實際使用的 HTTP 或混合代理連接埠為 7890。請先在用戶端設定中確認；若實際連接埠是 7897，請修改指令。此請求用於觀察各階段耗時，不適合測量最高下載速度。

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

這裡的 time_connect 主要反映與本機代理建立連線所需的時間，不能視為連到遠端網站的延遲。TLS、第一個位元組和總耗時都是從請求開始累計的數值，不能直接相加。指令成功但瀏覽器仍很慢時，請繼續檢查瀏覽器擴充功能、個別代理設定和請求協定差異。

第四層：檢查 DNS 解析，分辨等待解析與傳輸瓶頸

DNS 較常影響首次連線、網域分流與目標位址選擇，而不是已建立連線後的持續下載速度。如果檔案已穩定傳輸數分鐘，速度仍然偏低，單純更換 DNS 通常無法解決頻寬問題。

先確認由哪一方處理 DNS 解析

檢查目前設定檔中的 dns 區段、TUN 的 DNS 劫持設定，以及瀏覽器是否啟用了安全 DNS。系統 DNS、瀏覽器 DoH 和核心 DNS 可能走不同路徑。啟用系統代理不代表所有系統 DNS 查詢都會進入 Clash。

• Fake-IP 模式：通常會為網域回傳映射位址，再由核心將連線與原始網域關聯。常見設定會使用 198.18.0.0/16，實際範圍仍應以 fake-ip-range 設定為準。
• Redir-Host 模式：回傳實際解析出的位址。解析結果，以及後續的網域關聯和規則比對方式，仍取決於核心與流量接管方式。
• 自訂上游 DNS：檢查上游 DNS 是否可連線，以及解析請求是否形成循環依賴。不要只因為某個公共 DNS 很有名就選用它。

在 Windows 上可使用 Resolve-DnsName example.com 查看系統路徑取得的結果，但這不代表瀏覽器獨立 DoH 的解析結果。Fake-IP 生效時，看到設定範圍內的映射位址並不表示 DNS 故障；也不應把這個位址當成目標伺服器來評估線路延遲。

如何確認修改是否有效

1. 先備份現有 DNS 設定，每次只修改一個項目，例如更換無法連線的上游 DNS；不要同時切換模式和整套分流規則。
2. 依照用戶端支援的方式重新載入設定，必要時重新啟動核心，並確認日誌中沒有連線至 DNS 上游時的錯誤。
3. 在 Windows 執行 ipconfig /flushdns 清除系統快取，再重新開啟瀏覽器測試。瀏覽器和核心仍可能各自保留快取。
4. 比較首次開啟和再次開啟的差異。如果只有首次等待時間縮短，持續下載速度沒有變化，就應將結論限定在 DNS 解析或建立連線階段。

不要一遇到速度慢就大量擴增 fake-ip-filter。它用來讓特定網域不回傳 Fake-IP，通常是為了區域網路裝置探索或特定應用程式相容性等需求，不是通用的加速清單。修改前應先確認是哪個網域發生什麼不相容現象。

第五層：檢查本機設定，確認流量接管、系統資源與協定

節點、網路和規則都沒有明顯異常時，再檢查本機。此時重點不是尋找「加速開關」，而是確認是否有多重代理、資源瓶頸或應用程式層級的重試。

TUN 不是頻寬加速器

TUN 透過虛擬網路介面接管流量，適合處理不遵循系統代理設定的應用程式。它改變的是流量進入核心的方式，不會提高節點方案提供的頻寬。不同的協定堆疊、路由和 MTU 設定可能影響相容性，但沒有適用於所有裝置的固定「最快值」。

若系統代理運作正常，只有使用 TUN 時速度變慢，請先用相同的應用程式和節點重現問題，再檢查路由衝突、DNS 接管、其他虛擬網卡和核心日誌。不要一次變更 MTU、協定堆疊和 DNS 模式全部設定，否則即使問題改善，也無法判斷是哪項設定生效。

瀏覽器速度慢，也要留意 UDP 與 QUIC

HTTP/3 使用 QUIC，通常以 UDP 為基礎。如果應用程式嘗試使用的 UDP 路徑無法連通，可能會等待一段時間後才切換連線方式；節點協定、伺服器和流量接管方式都必須支援相應流量。在系統 HTTP 代理下的瀏覽器行為，也不等於由 TUN 接管時的行為。

可在瀏覽器開發人員工具的「網路」面板觀察協定和請求耗時，或暫時關閉瀏覽器中與 QUIC 相關的實驗選項進行比較，測試後再恢復。只有在找到 UDP 失敗、回退等待等證據時，才沿著這個方向排查；不要把停用 QUIC 當成所有網速問題的固定處理方式。

重新測試並記錄：將結論縮小到一項可執行的調整

每輪修改後，都用原本的測試目標和測試時間重測 3 次。保留有效的調整，還原沒有幫助的變更。一次測試只能支持有限的結論：更換節點有效，不代表一定要改 DNS；手機熱點有效，也不代表需要重新安裝用戶端。

1. 節點差異明確：保留表現穩定的節點，記錄異常節點與發生時間，並回報訂閱服務提供者。
2. 網路或時段差異明確：優先調整接入網路、無線環境或節點入口線路，不要反覆修改本機 DNS。
3. 規則出口不符預期：調整對應網域的規則或策略組，再確認主要請求和資源請求是否都符合預期。
4. 只有首次請求很慢：繼續檢查 DNS 解析、TLS 和遠端首位元組時間，不要用小型網頁請求推估頻寬。
5. 只有某種流量接管方式較慢：保留可正常使用的方式，並提供核心版本、重現步驟和已移除敏感資訊的日誌，以利進一步找出原因。

最有用的結果不是「所有參數都調過」，而是「同一個目標在節點 A 很慢，節點 B 則正常」或「問題只會在 TUN 模式下重現」。這類記錄能明確指出下一步該檢查哪一層。若尚未確認基本連線正常，可先依照連線檢查步驟建立穩定的比較環境。