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

Clash 網速慢，不一定是節點頻寬不足。網頁首次開啟要等很久、影片開始播放後不斷緩衝、下載速度持續偏低，背後原因可能分別是網域解析、線路壅塞或本機流量接管異常。先釐清症狀，再逐層檢查，比一次改動 DNS、節點和 TUN 參數更容易找出問題。

開始前：建立可重複的測速基準

先暫停雲端硬碟同步、系統更新和其他大型檔案下載，固定使用同一台裝置、同一個網路及同一個目標網址。使用規則模式時，也要在連線詳細資訊中確認目標實際套用的規則、策略組和節點。若測試流量沒有經過預期節點，就不能據此判斷該節點的效能。

1. 記錄環境：記下用戶端版本、核心版本、作業系統版本、目前網路類型、節點名稱，以及系統代理和 TUN 是否啟用。核心版本可在用戶端的「關於」頁面或啟動記錄中查詢。
2. 固定策略：在用戶端的代理或策略組頁面手動選定節點，避免自動策略組在測試途中切換線路。若設定不允許手動固定節點，請記下每次連線實際選用的節點。
3. 分項測量：記錄網頁首次回應時間、持續下載速度和失敗次數；每項測試重複 3 次，每輪間隔約 30 秒，不要把單次峰值當成穩定速度。
4. 統一單位：100 Mbps 理論上約為 12.5 MB/s，實際速度還會受到通訊協定額外負擔影響。用戶端顯示的 MB/s，不能直接和寬頻方案標示的 Mbps 比較。

第一層：節點品質與實際吞吐量

節點延遲不等於下載速度

用戶端的延遲測試通常會向指定 URL 發出請求，反映的是該探測路徑的回應狀況，不代表持續傳輸能力。顯示 60 ms 的節點，可能因出口頻寬由多人共用而下載緩慢；顯示 160 ms 的節點，也可能有更穩定的持續吞吐量。使用 url-test 的策略組同樣不是自動頻寬測速工具。

先選同一地區的 2 至 3 個節點，下載同一項資源，每個節點測試 3 次。測速網址、連線數和測試時間都要一致。若只有單一節點明顯較慢，優先處理節點問題；若所有節點都慢，再確認它們是否共用入口或中轉線路。

指定代理連接埠重新測試

桌面版可使用 curl 明確指定 HTTP 代理，排除命令列程式未讀取系統代理設定的可能。以下以已確認正在監聽的本機 HTTP 或 mixed 連接埠 7890為例；7890 並非所有用戶端的預設值，務必先確認目前使用的連接埠。此命令會從公開測試端點下載約 10 MB 資料，請留意流量用量。

# macOS / Linux；本機需已安裝 curl
curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --max-time 60 --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' 'https://speed.cloudflare.com/__down?bytes=10000000'

# Windows PowerShell；明確呼叫 curl.exe
curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 60 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n" "https://speed.cloudflare.com/__down?bytes=10000000"

speed_download 的單位是位元組每秒；例如輸出 2500000 B/s，換算後約為 2.5 MB/s。這只是數值示例，並非本站實測結果。小型檔案容易受到交握過程影響，結果僅適合初步比較；也應使用實際受影響的網站複查，不能只根據單一測速服務判斷所有服務的速度。

第二層：入口、中轉與出口線路

節點名稱不同，不代表網路路徑完全獨立。兩個標示不同地區的節點，仍可能共用同一個接入入口或中轉資源。如果多個節點同時變慢，只更換地區可能無法改善。

交叉比對時段與網路

• 比較時段：例如在 10:00 和 21:00 測試同一個節點及同一項資源。若只有晚間速度持續下降，應優先懷疑尖峰壅塞，而不是立刻修改本機 DNS。
• 比較接入網路：讓同一台裝置分別連接家用寬頻和手機熱點。測試熱點前請確認流量額度，並關閉背景下載。若只有家用網路異常，再檢查路由器、電信業者線路和 Wi-Fi。
• 比較入口：若服務提供者明確標示不同入口或線路類型，可在相同目標地區下進行比較。不要只憑名稱中出現「專線」等字眼，就認定效能一定較好。
• 比較目標：使用同一節點連線到兩個不同網站。若只有一個網站很慢，也可能是目標網站的 CDN、帳戶限速、出口地區或網站本身的負載所致。

從本機對節點伺服器執行 ping，只能提供有限的連線狀況線索。有些伺服器不回應 ICMP，有些中間路由器則會降低 ICMP 回應的優先順序。若中間某一跳顯示封包遺失率高，但後續節點與最終目標正常，不能據此認定一般服務流量也在該處遺失。請結合實際 HTTPS 請求與持續傳輸結果判斷。

若同一節點在兩種接入網路下都很慢，而另一條獨立線路正常，可暫時改用較穩定的線路，並向服務提供者提供測試時間、接入電信業者、節點名稱和測試結果。請勿傳送完整訂閱網址、節點密碼或含有驗證資訊的設定檔。

第三層：DNS 與 TUN 本機設定

先分辨解析延遲與傳輸緩慢

DNS 異常常見症狀包括首次造訪時等待過久、間歇性解析失敗，或網域名稱解析到不合適的位址；但通常無法解釋已建立的下載連線長時間維持極低速度。先查看用戶端記錄是否反覆出現 DNS 逾時、上游無法連線或解析失敗，再決定是否調整解析設定。

使用 mihomo 時，請檢查最終生效設定中的 dns.enable、dns.enhanced-mode、dns.nameserver，以及啟用 TUN 時的 tun.dns-hijack。這些是檢查項目，不代表必須全部改成某個固定值。圖形介面用戶端可能會透過覆寫或合併設定產生執行檔，直接修改訂閱快取檔案，可能在下次更新時失效。

• 檢查上游是否可連線：加密 DNS 同樣需要可用的網路路徑。若加密 DNS 依賴代理，而代理伺服器的網域名稱又必須透過同一條解析路徑解析，可能造成啟動依賴問題；請依核心文件區分一般網域與代理伺服器網域的解析設定。
• 保留模式語意：fake-ip 會回傳用於映射的虛擬位址，不代表解析錯誤。看到 198.18.0.0/16 範圍內的回傳值時，不要立刻更換 DNS；實際使用的位址池以生效設定為準。
• 確認瀏覽器行為：瀏覽器的安全 DNS 可能會使用獨立的 HTTPS 解析請求，不一定會受到傳統 53 連接埠攔截影響。可暫時關閉瀏覽器安全 DNS 進行一次對照測試，完成後請還原原設定。
• 避免同時修改多處：每次只調整一項解析來源，重新建立連線，再比較首次造訪所需時間。不要同時修改系統、瀏覽器、路由器和用戶端的 DNS。

以系統代理與 TUN 進行單變因對照

系統代理仰賴應用程式支援並讀取代理設定；TUN 則透過虛擬網卡和路由接管流量，兩者涵蓋範圍不同。選用明確支援 HTTP 代理的瀏覽器，或使用前述 curl 命令：先關閉 TUN，確認明確指定代理的請求可正常運作，再測試 TUN 接管流量的情況。測試時請確認兩次連線最後使用的是同一個節點。

1. 先儲存目前設定，並中斷其他 VPN、遊戲加速器或網路過濾工具的連線，避免多個虛擬網卡同時爭用路由。
2. 關閉 TUN，使用已確認的本機代理連接埠測試同一個 HTTPS 資源，並記錄速度和錯誤訊息。
3. 啟用 TUN，以一般網路請求重新測試，並在連線詳細資訊中確認流量已被接管；單靠明確指定代理的命令，無法證明 TUN 正常運作。
4. 若只有 TUN 出現異常，再檢查權限、路由、DNS 接管和用戶端記錄，不要先更換所有節點。

第四層：系統負載與本機網路

確認裝置是否已達資源上限

Windows 可按 Ctrl + Shift + Esc 開啟工作管理員，在「處理程序」和「效能」查看 CPU、網路與磁碟使用情況；macOS 可開啟「活動監視器」，查看「CPU」和「網路」。測試時請觀察用戶端核心處理程序，不要只看介面處理程序。若單一核心持續接近滿載，整體 CPU 使用率仍可能不高。

效能較弱的路由器、舊款手機或虛擬機，在加密傳輸或連線數較多時，更容易遇到效能瓶頸。先暫停多執行緒下載，再以單一連線重新測試；若速度變化時 CPU 使用率也明顯下降，應先減少並行連線數，或改用效能較合適的裝置，而不是繼續增加規則和功能。

排除 Wi-Fi、背景流量與連接埠衝突

• Wi-Fi：靠近路由器重新測試；情況允許時改用網路線。訊號夠強時，5 GHz 網路通常較適合測試高吞吐量，但隔牆後的效果仍應實際比較。
• 背景工作：暫停雲端硬碟、備份、更新和遊戲平台下載，並確認上傳頻寬是否已用滿。上傳壅塞也會影響網頁回應和下載確認封包。
• 本機監聽：記錄中出現 address already in use 時，請先排除連接埠占用。Windows 可執行 netstat -ano | findstr :7890 查看相關連線與監聽狀態，再核對 PID；連接埠衝突屬於啟動或流量接管問題，不是節點限速。
• 安全軟體：檢查是否啟用了 HTTPS 掃描、網路過濾或流量稽核模組。請依軟體文件，短暫停用相關功能進行對照；不要長期關閉防火牆，也不要新增套用至所有程式的放行規則。

若退出用戶端後，原本能直接連線的網站同樣很慢，應先處理本機網路問題。反過來說，一般直接連線的測速結果正常，也不能證明代理線路正常：兩種流量經過的伺服器及電信業者互連路徑可能不同。

最後驗證：確認調整有效並保留記錄

完成調整後，請重新建立測試連線。切換模式或策略組，通常不代表所有既有 TCP 長連線都會立即切換；瀏覽器若沿用舊連線，測試結果可能仍來自原本的節點。可先停止目前的下載，再重新發出請求；必要時只關閉目標連線，不必清除所有應用程式的工作階段。

1. 以相同條件複測：使用同一台裝置、同一個網路、同一個目標和同一種測試方式，重複測試 3 次，比較中間值與波動幅度，不要只看最高速度。
2. 回到實際使用情境：確認原本卡頓的影片、網頁或下載工作已有改善。若測速端點變快，但實際使用情況沒有改變，表示還需檢查該服務的流量分流、目標網站或通訊協定路徑。
3. 只保留有效調整：若調整 DNS、MTU 或策略組參數後沒有改善，請及時還原，避免下次排查時出現大量無法解釋的差異。
4. 整理求助資訊：記下發生時間、用戶端與核心版本、網路類型、是否啟用 TUN、兩組對照結果及精簡後的錯誤記錄。分享記錄前，請移除訂閱網址、驗證欄位和個人瀏覽記錄。

排查 Clash 網速慢，最有效的順序是先固定測試條件，再檢查節點吞吐量、線路變化、本機 DNS 與 TUN，最後確認系統環境。延遲數值只是線索；只有可重現、可對照且可還原的測試結果，才足以作為下一步調整的依據。設定欄位與規則的說明，請參閱通訊協定手冊；基本連線問題可參考常見問題。