Clash 網速慢的分層診斷：逐一檢查節點品質、線路路由與本機設定

先釐清慢在哪裡：開啟速度、傳輸速度，還是連線不穩

Clash 網速慢不一定是單一問題。網頁點開後要等好幾秒，但檔案下載很快，通常應先檢查 DNS、建立連線的時間和目標服務的回應；下載一開始很快，之後卻降速，則較值得檢查線路壅塞、節點限速和封包遺失；只有特定應用程式速度慢，就先確認流量是否經過代理，以及命中了哪條規則。釐清症狀，比直接開啟 TUN 或更換 DNS 更有效。

本文所說的 Clash，指客戶端及其代理使用流程；實際支援哪些設定，取決於目前執行的核心。使用 mihomo 的客戶端與舊版 Clash 客戶端，在 DNS、TUN 和協定支援上可能有所不同。開始排查前，請在客戶端的「關於」或核心資訊頁記下客戶端與核心版本，不要只憑應用程式名稱判斷支援範圍。

建立可重現的測試紀錄

• 固定網路：使用同一台電腦和同一台路由器，優先接網路線或在路由器附近使用 Wi-Fi；暫停雲端硬碟同步、系統更新和其他下載。
• 固定測試目標：使用同一個網頁和同一個檔案來源。不同測速網站的伺服器和連線數不同，結果不能直接比較。
• 固定代理策略：記下規則模式、實際代理群組和節點名稱；測試期間不要讓自動選擇群組切換節點。
• 固定測試時間：連續傳輸約 30 秒，記錄速度穩定後的數值，重複測試 3 次；不要只記下第一秒的峰值。
• 記錄測試資訊：至少記下測試時間、系統代理或 TUN 狀態，以及延遲和傳輸速度的單位。

節點層：延遲低，不代表下載頻寬高

客戶端顯示的節點延遲，通常是核心透過該節點請求指定 URL 後測得的時間，會受測試目標、連線重複使用、節點出口和服務回應影響。這不是節點頻寬測試，也不一定等同 ICMP ping。訂閱中標示的「倍率」、「高速」等名稱，同樣不能取代實際傳輸測試。

在相同條件下比較 2 至 3 個節點

1. 開啟實際承載目標請求的代理群組，暫時手動選取節點 A。如果目前策略指向巢狀代理群組，也要確認最後實際使用的是哪個節點。
2. 向同一個延遲測試 URL 發出請求，連續測試 3 次，留意延遲波動和逾時情況，不要只看最低值。
3. 使用同一個檔案來源傳輸約 30 秒；結束上一輪下載後，再測試節點 B。
4. 查看客戶端的連線清單，確認這些請求確實經過選定的節點，避免規則將測速網域分流到其他策略。

以範例來看，A 可能較適合頻繁的小型請求，B 則較適合持續下載。不過，目標網站的出口路由各不相同，換一個服務測試，結果可能正好相反。若只有一個節點速度慢，而其他節點在同一時段正常，應優先檢查該節點的負載、限速或通往目標網站的路徑，不必立刻修改本機設定。

自動測速群組的適用範圍

url-test 主要依指定 URL 的延遲選擇節點；fallback 通常依序使用可用節點。兩者都不保證選到傳輸量最大的節點。排查時先手動固定節點，確認問題後再恢復自動策略。不要把測速間隔縮短到幾秒：頻繁探測會增加請求量，也會讓測試結果更難反映實際使用情況。

線路層：尖峰時段壅塞、本機網路與目標出口

代理連線會經過本機網路、電信業者、節點入口、節點出口和目標服務。客戶端顯示的單一延遲數字，無法指出是哪一段發生壅塞。如果每天晚上變慢、白天恢復，而且多個節點都變慢，應先比較不同時段和入口線路，而不是不斷更新訂閱。

透過三組比較縮小問題範圍

• 直連與代理：先測試可直接連線的常用網站。兩者都慢，優先檢查 Wi-Fi、路由器負載或寬頻；直連正常但代理普遍慢，再檢查代理入口和電信業者路徑。
• 寬頻與手機熱點：在同一台裝置、使用同一個節點，改連手機熱點測試。熱點速度明顯較快，表示原本的網路或電信業者路徑較可疑；也要留意行動訊號和熱點本身的波動。
• 不同目標服務：使用同一個節點連線到兩個服務。只有其中一個服務速度慢，可能與該服務的 CDN、出口路徑、限速或帳號狀態有關，不能直接判定整個節點無法使用。

例如，同一個節點在 10:00 的穩定速度為 7.5 MB/s，到了 21:00 降至 0.8 MB/s，而本機直連下載仍有 10 MB/s。這些紀錄足以支持進一步調查尖峰時段的代理路徑或節點負載，但不能單憑此結果判定是電信業者限速。再補上另一個入口節點和手機熱點的結果，才能提高判斷的可靠性。

封包遺失與路由工具的限制

持續 ping 閘道器，可檢查本機連線是否明顯不穩；ping 遠端 IP 或執行 traceroute，則只能協助觀察部分路徑。中間路由器可能降低 ICMP 回應的優先順序，某一跳沒有回應，不代表業務流量就在此處遺失。一般 traceroute 也不會自動呈現「本機經代理節點再到目標」的完整路徑，因此不應將它視為代理通道的完整路徑報告。

本機層：先確認系統代理、規則與實際連線

系統代理通常只會影響願意讀取系統代理設定的應用程式，不會自動接管所有 TCP、UDP 流量。終端機、遊戲和部分獨立網路元件可能不理會系統代理。TUN 則透過虛擬網路介面和路由攔截符合條件的流量，涵蓋範圍較廣，但也會增加路由、權限和 DNS 之間的相互影響。

依連線紀錄確認流量去向

1. 在客戶端確認目前使用規則模式，再開啟發生問題的網頁或應用程式。
2. 開啟客戶端的連線清單，核對目標網域或 IP、匹配規則、策略鏈和傳輸量。客戶端介面可能標示為「連線」或「Connections」。
3. 如果請求命中 DIRECT，請檢查前面的網域規則、規則集或區域網路規則是否符合預期。
4. 如果請求命中代理，卻使用了其他節點群組，請檢查規則指定的策略群組，不要只修改主畫面上最醒目的群組。
5. 如果連線清單中沒有對應項目，先檢查應用程式本身的代理設定、代理略過清單，以及流量是否確實進入目前執行的核心。

規則會依順序比對，前面的規則一旦命中，通常就不會再比對後面的規則。排查時可暫時切換至全域模式，選擇同一個節點再比較。如果全域模式恢復正常，應著重檢查規則和策略群組；全域模式會改變其他應用程式的流量去向，測試結束後請恢復原本模式。

透過明確指定代理的請求，排除應用程式設定差異

以下指令適用於本機 HTTP 混合代理連接埠為 7890 的情況。先查看執行中的設定是否有 mixed-port；如果實際連接埠不同，請修改指令中的連接埠。macOS、Linux 可使用 curl；Windows PowerShell 建議使用 curl.exe，避免舊版環境中的命令別名差異。

curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

這個 204 請求用來觀察連線和回應時間，不會測試下載頻寬。透過本機 HTTP 代理時，time_connect 主要反映連上本機代理連接埠所需的時間，不能當作節點往返延遲；TLS 和首位元組計時則從請求開始累計，也不是各階段的個別耗時。若指令結果正常，但瀏覽器仍然很慢，下一步請檢查瀏覽器代理設定、擴充功能、內建安全 DNS 和快取。

DNS 層：解析緩慢、Fake-IP 與瀏覽器安全 DNS

DNS 較常影響首次開啟網頁和網域分流，通常不會直接提高已建立連線的大型檔案傳輸速度。網頁第一次開啟要等 3 秒，重新整理後就很快，可能與 DNS 解析、連線重複使用或快取有關；不能只憑這個現象就判定 DNS 故障。應配合記錄檢查是否出現解析逾時，以及連線取得的網域是否符合預期。

先確認實際採用的解析路徑

• 檢查執行中的設定，包括 dns.enable、enhanced-mode、上游解析器和相關策略，而不要只查看訂閱檔案的原始內容。
• 瀏覽器啟用 DNS over HTTPS 時，可能會透過瀏覽器自己的通道解析網域；可先暫時關閉作為比較，再決定最後要使用哪一條解析路徑。
• 確認上游解析器本身可以連線。若設定使用無法連線的解析服務，可能會增加等待時間或觸發備援。
• 若解析器使用網域名稱，請留意用來解析該網域的引導 DNS 設定，避免解析依賴形成循環。

Fake-IP 會以映射位址連結網域和連線，方便核心比對網域規則。常見的設定範圍為 198.18.0.1/16，並非網站的真實伺服器位址。應用程式取得這類位址，不代表節點異常。某些區域網路服務或特殊應用程式需要透過 fake-ip-filter 等方式處理，但不建議排除所有網域，否則可能改變預期的網域辨識行為。

不要不加判斷地在 Fake-IP 和 redir-host 之間反覆切換。每次只修改一項設定，重新建立相關連線，必要時依客戶端提供的方式清除 DNS 快取，再重做相同測試。系統解析工具的結果也不一定代表瀏覽器或代理核心的解析結果：明確指定 HTTP 代理的請求，通常會將目標主機名稱交給代理處理；在本機執行一次 nslookup，無法驗證整條解析路徑。

TUN 層：涵蓋範圍、UDP 與路由衝突

TUN 是接管流量的方式，不是頻寬加速開關。若一般網頁在系統代理下已能正常使用，開啟 TUN 不一定會更快。反過來說，不讀取系統代理的應用程式，可能要等 TUN 接管後才會真正使用代理；這類改善是流量路徑改變所致，不是 TUN 提高了節點容量。

比較兩種模式時，固定使用同一個節點

1. 備份設定，並記下節點、規則模式和 DNS 設定。
2. 先關閉 TUN，只用系統代理測試支援代理的瀏覽器，或執行明確指定代理的指令。
3. 接著依照客戶端要求啟用服務模式或授權，再開啟 TUN；確認路由和連線紀錄確實有所變化。
4. 如果只有 TUN 模式異常，請檢查其他 VPN、虛擬網卡、路由規則和 DNS 接管是否互相衝突。
5. 測試後恢復日常設定；在尚未確認流量路徑前，不要同時修改 TUN 堆疊、DNS 和節點協定。

瀏覽器的 HTTP/3 通常使用 QUIC，也就是 UDP 流量。系統 HTTP 代理和 TUN 對這類流量的處理可能不同，並取決於應用程式、核心和節點是否支援 UDP。若影片載入或部分網站異常，可暫時關閉應用程式的 QUIC 進行比較；TCP 正常但 UDP 異常時，再調查 UDP 路徑，不要直接將結論套用到所有下載情況。

MTU 調整留到最後

如果小型請求成功，但較大的傳輸反覆停頓，而且問題只出現在特定的隧道組合中，可進一步檢查路徑 MTU。一般實體乙太網路的 MTU 為 1500，但封裝可能會減少可用載荷。若已有相關證據，可暫時將 TUN 的 MTU 設為 1400 進行比較，並保留原值以便還原；1400 並非通用的最佳值。調整後沒有改善，就恢復原設定，繼續檢查封包遺失和路由。

同時觀察本機 CPU、記憶體和安全軟體的活動。如果只有這台裝置速度慢，而且傳輸時某個核心持續接近滿載，可能與加密處理、流量檢查或客戶端額外負擔有關。舊裝置不適合一邊執行多個測速工作，一邊比較協定。企業裝置的安全策略應由管理員協助檢查，不要為了測試而直接關閉防護。

逐步確認原因：每次只修改一個變數

有效的排查結果，應該指出「哪一層、在什麼條件下、哪一項比較出現變化」，而不是羅列一堆可能原因。每次修改設定後都要保留前後紀錄；如果一次改了三個選項，即使速度恢復，也無法知道是哪項設定發揮作用。

向節點服務商或客戶端維護者回報時，請附上客戶端與核心版本、作業系統、發生時間、網路類型、使用模式、目標服務、3 次測試結果，以及相關錯誤訊息片段。公開前請刪除訂閱網址、認證資料、節點密碼和存取權杖；完整設定和記錄可能包含這些資訊。

建議依序確認：請求確實經過代理、固定節點進行比較、檢查時段與網路，再處理 DNS、TUN 和本機負載。需要確認規則術語時，可查看術語表；遇到明確錯誤訊息時，可前往疑難排解。更新訂閱是為了取得設定，通常無法直接解決現有節點的線路壅塞。