第一層：先建立可重複的速度基準
Clash 顯示的節點延遲、網頁開啟時間與下載速度，是三種不同的指標。延遲測試通常只測量一次 HTTP 請求或 TCP 連線的回應時間，可以反映節點是否可連線，卻不能直接代表持續傳輸量。一個延遲 80 毫秒的節點可能頻寬不足；另一個延遲 180 毫秒的節點，下載大型檔案時反而可能維持更高速度。因此，開始排查時不要只盯著節點清單中的毫秒數。
先固定裝置、網路與測試目標。關閉正在同步檔案、更新系統、下載遊戲或上傳照片的程式，再選擇一個穩定的網站與一個容量足夠大的測試檔案。每輪測試至少持續數十秒，並記錄首屏載入時間、穩定下載速度，以及是否在途中停頓。短時間測速容易受到快取、連線預熱與伺服器限速影響。
- 暫時關閉 Clash 的系統代理或 TUN 模式，測量目前網路的直連表現。
- 啟用 Clash，固定一個節點與一種代理模式，使用相同目標重新測試。
- 更換同一地區的另一個節點，再執行一輪相同測試。
- 分別記錄延遲、下載速度、上傳速度、丟包情況與網頁解析時間。
如果直連本身已明顯變慢，應先檢查本地寬頻、行動網路或 Wi-Fi，而不是立即修改 Clash 設定。如果只有代理連線變慢，則繼續定位節點、入口線路、出口線路與用戶端設定。若只有某個網站變慢，而其他代理流量正常，問題也可能出在目標網站、路由策略，或該網站與出口位址之間的連線品質。
第二層：區分節點延遲、頻寬與負載
節點是最常見的速度瓶頸，但「節點可用」只代表能夠建立連線。節點的實際速度還取決於伺服器頻寬、同時連線負載、協定實作、電信業者入口品質，以及出口到目標網站的路由。尖峰時段變慢、凌晨恢復，通常更接近負載或線路壅塞；全天穩定偏慢，則需要檢查節點限速、路徑品質與裝置處理能力。
不要把延遲測試當成完整測速
Clash 用戶端通常會透過一個測試網址計算節點延遲。結果會受到測試網址、連線重用、DNS 快取與逾時設定影響。延遲低但傳輸量低，可能是節點頻寬不足；延遲偶爾突然升高，可能是線路抖動；大量節點同時顯示逾時，則應檢查訂閱、網路權限、DNS 或伺服器狀態，而不是逐一反覆點擊節點。
選擇節點時，可以先依地區分組，再在同一地區比較至少三個節點。測試應涵蓋網頁、小型檔案與持續下載。播放影片時還要觀察緩衝是否穩定，因為瞬間峰值很高，不代表長時間傳輸穩定。若用戶端支援 URL Test、Fallback 或負載平衡策略組，也應了解它們的選擇依據：URL Test 傾向選擇測試回應較快的節點，Fallback 著重故障切換，負載平衡則可能讓不同連線經過不同節點。
檢查策略組是否真的選中了目標節點
設定中常有多層策略組，例如應用程式規則先進入「國外網站」，該組再引用「自動選擇」，最後才指向具體節點。介面上切換了某個組，不代表目前請求一定會經過它。開啟連線記錄或日誌，確認目標網域命中了哪條規則、進入哪個策略組，以及最後使用哪個節點。
目標網域 → 規則匹配 → 策略組 → 子策略組 → 具體節點如果流量命中 DIRECT，測速結果實際上就是直連；如果命中 REJECT，請求會被主動拒絕；如果命中自動策略組，用戶端可能在背景重新選擇節點。排查期間可以暫時固定策略組中的具體節點，避免自動切換干擾結果。測試完成後再恢復原有策略。
第三層：判斷入口線路與出口線路是否壅塞
代理連線至少包含三段路徑：裝置到本地電信業者、電信業者到代理節點、代理節點到目標網站。任何一段都可能造成速度下降。節點距離較近，只能表示地理位置可能更接近，不能保證電信業者之間的互連路徑更短。不同寬頻或行動網路存取同一個節點時，表現可能完全不同。
最實用的判斷方式是交叉測試。保持節點不變，將裝置從家用 Wi-Fi 切換到手機熱點；或者保持網路不變，切換到另一個地區、另一種入口類型的節點。如果換網路後同一節點恢復正常，問題更可能出在本地電信業者到節點的路徑；如果換節點後恢復，則原節點的負載或路由更值得懷疑。
- 白天正常、晚上變慢：優先考慮尖峰時段壅塞、共享頻寬負載與電信業者互連壓力。
- 網頁快、下載慢：檢查節點的持續頻寬、目標網站限速與單一連線效能。
- 下載快、影片頻繁緩衝：檢查串流媒體目標的出口路由、策略匹配與連線穩定性。
- 第一次開啟很慢、之後正常：重點檢查 DNS、TLS 建立連線與首次路由選擇。
- 速度週期性降到零：檢查丟包、無線干擾、節點重啟、連線切換與裝置休眠策略。
命令列中的 ping 只能提供有限參考。有些伺服器會降低 ICMP 回應優先級，甚至完全不回應，但 TCP 與 UDP 服務仍可能正常運作。路由追蹤可以協助觀察路徑在哪一段出現明顯變化，卻不能只憑某一跳沒有回應就判定故障。更可靠的結論來自不同時段、不同網路與不同節點的對照結果。
第四層：檢查 DNS 解析與連線等待
DNS 問題經常被誤認為網速慢。典型表現是輸入網址後長時間一片空白，但頁面開始載入後速度正常；某些網域可以開啟，另一些網域卻持續逾時；切換網路後立即恢復。此時瓶頸可能發生在網域解析階段，而不是代理節點的資料傳輸階段。
Clash 或 mihomo 設定可以接管 DNS，並依執行模式使用一般 DNS、加密 DNS、Fake IP 或 Redir Host 等機制。不同用戶端顯示的開關名稱可能不同，最終行為仍由核心設定與用戶端產生的設定共同決定。修改前應先查看目前設定是否啟用了 DNS、監聽位址、預設解析器與上游伺服器。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query上面的片段只用來說明欄位關係，範例位址不能直接視為可用服務。實際排查時，應使用能穩定連線的解析器，並確認系統或路由器沒有將 DNS 請求強制轉送到其他位置。若上游加密 DNS 本身需要先解析網域，還要確保 bootstrap 或預設解析路徑能正常運作。
Fake IP 模式下的常見誤判
Fake IP 會為網域回傳保留位址，再由核心將該位址映射回原網域並執行規則匹配。這種方式有利於統一接管網域流量，但部分區域網路裝置、特殊應用程式或依賴真實位址的服務，可能需要加入過濾清單。若只有印表機、路由器管理頁面、區域網路儲存裝置或少數應用程式異常，應檢查 fake-ip-filter 與區域網路繞過規則，而不是直接認定節點變慢。
系統中也可能殘留舊的 DNS 快取。切換設定後，可以重新啟動相關應用程式，必要時清除系統 DNS 快取，再重新測試。瀏覽器也可能啟用自己的安全 DNS，讓瀏覽器與其他程式使用不同的解析路徑。排查時應確認系統、瀏覽器與 Clash 分別由誰負責解析，避免多個元件同時改寫 DNS。
第五層：對照系統代理、規則模式與 TUN 模式
系統代理通常透過作業系統的代理設定，通知應用程式將 HTTP 或 HTTPS 請求交給 Clash。遵循系統代理的瀏覽器與桌面程式可以被接管，但部分遊戲、命令列程式、商店應用程式，以及自行實作網路堆疊的軟體，可能會忽略這項設定。TUN 模式則會建立虛擬網路介面，在更低層接管更多 TCP、UDP 與 DNS 流量，涵蓋範圍更廣，同時也更依賴權限、路由表與作業系統網路元件。
如果瀏覽器速度正常，而遊戲、終端機下載工具或特定應用程式很慢，先確認該應用程式是否已進入代理。可以在 Clash 的連線清單中觀察請求是否出現，並查看目標位址、協定、規則與最後使用的節點。連線清單沒有紀錄，通常表示流量沒有進入核心；有紀錄但使用 DIRECT，表示規則選擇了直連；有紀錄且經過節點，才適合繼續分析節點與線路。
規則模式與全域模式的對照方法
規則模式會依網域、IP、程序或規則集，決定 DIRECT、REJECT 或某個策略組。全域模式通常會將大多數流量交給指定的代理策略。排查某個網站時，可以短暫切換到全域模式進行對照：如果全域模式恢復正常，而規則模式很慢，應檢查規則命中、策略組與 DNS；如果兩種模式都慢，節點或線路更值得懷疑。
全域模式只適合暫時定位問題，不應取代規則修復。測試結束後恢復規則模式，並在日誌中找出造成差異的具體規則。也要留意設定底部的 MATCH 規則，因為未被前面規則命中的請求最後會落到這裡。
TUN 模式速度下降時該檢查什麼
- 確認用戶端具備建立虛擬網卡與修改路由所需的系統權限。
- 檢查其他 VPN、虛擬機網卡、遊戲加速工具與安全軟體是否同時修改路由。
- 確認 MTU 設定是否適合目前網路；過大的封包可能觸發分片或遭到丟棄。
- 觀察 UDP 是否穩定；部分網路環境對 UDP 的限制會影響 QUIC、遊戲與即時通訊。
- 比較關閉 TUN、只啟用系統代理後的速度，判斷問題是否與虛擬介面有關。
部分瀏覽器會優先使用基於 UDP 的 HTTP/3。若線路對 UDP 的支援不穩定，可能出現網頁建立連線緩慢、影片卡頓或測速結果波動。可以透過連線日誌確認協定，再進行短時間對照測試。不要一次永久關閉多個網路功能；先確認是哪項變更真正影響結果。
第六層：排除裝置效能、無線網路與背景程式
代理核心需要執行加密、解密、規則匹配、DNS 處理與連線轉送。現代桌面裝置通常能應付日常流量，但低功耗路由器、舊手機、資源受限的伺服器，或同時承載大量連線的裝置，可能出現 CPU 使用率接近上限的情況。此時更換節點未必能改善速度，因為瓶頸位於本地處理能力。
測速期間開啟工作管理員或系統監視工具，觀察 Clash 用戶端、核心程序、瀏覽器與安全軟體的 CPU、記憶體、磁碟及網路使用量。若速度下降時某個核心持續滿載，可以減少不必要的複雜規則、關閉過多日誌、減少並行連線，或在效能更充足的裝置上進行對照。
Wi-Fi 也是常見變數。2.4 GHz 頻段容易受到鄰近網路、藍牙裝置與家用電器干擾；距離路由器較遠時，裝置可能不斷重傳資料。優先使用網路線或穩定的 5 GHz、6 GHz 網路進行基準測試。如果有線正常、無線很慢，應先調整頻道、距離與路由器位置，而不是修改代理協定。
背景程式會佔用上行頻寬，而上行飽和又會推高下載延遲。雲端硬碟同步、照片備份、視訊會議與種子上傳，都可能造成這種情況。即使下載頻寬仍有餘裕，排隊延遲也會讓網頁與互動請求顯得遲緩。暫停背景工作後等待一段時間，再執行相同測試。
設定規模與日誌層級
大型規則集與頻繁更新的訂閱會增加載入時間，但正常設定不應讓每個請求都產生明顯延遲。如果用戶端啟動後長時間卡頓，請檢查規則集是否重複、設定是否多次引用同一項資源，以及日誌層級是否設得過高。除錯日誌適合短時間定位問題，持續記錄大量連線資訊會增加磁碟寫入與介面渲染壓力。
訂閱更新後突然變慢，還要核對策略組名稱與節點名稱是否發生變化。用戶端可能退回策略組預設項目，自動測試也可能選中了另一個節點。更新前後分別查看最終設定與目前選取項目，比反覆匯入訂閱更容易發現差異。
依序執行的十分鐘排查流程
速度問題適合由外而內逐層縮小範圍。以下流程不要求立即修改 YAML，先透過對照確認問題屬於哪一層，再處理對應設定。
- 測試直連：關閉代理後測試目前網路，確認基礎網路沒有明顯異常。
- 固定節點：關閉自動選擇，指定一個節點並記錄延遲與持續下載速度。
- 更換節點：分別選擇同地區與不同地區的節點，比較尖峰與非尖峰時段的表現。
- 查看連線：確認目標請求已進入 Clash，並記錄命中規則、策略組與最後使用的節點。
- 切換網路：使用手機熱點或另一條寬頻測試同一節點，判斷入口線路是否有問題。
- 檢查 DNS：觀察問題發生在解析階段還是傳輸階段，核對系統與用戶端的解析路徑。
- 對照模式：比較規則模式與全域模式、系統代理與 TUN 模式的結果。
- 檢查資源：觀察 CPU、記憶體、無線訊號與背景上傳是否成為瓶頸。
- 重新載入設定：確認設定解析成功，策略組選擇與訂閱更新結果符合預期。
- 恢復設定：撤銷僅用於測試的全域模式、除錯日誌與暫時 DNS 變更。
最終紀錄應包含測試時間、網路類型、用戶端版本、核心類型、代理模式、節點名稱、目標網站與速度結果。若需要向節點服務商或用戶端專案提交問題，這些資訊比「感覺很慢」更有診斷價值。涉及設定內容時，應先移除訂閱網址、驗證資訊、節點憑證與個人網路資訊。
排查結論：先定位慢在哪一段
Clash 速度變慢不等於節點延遲高。完整連線由本地網路、DNS、規則匹配、代理入口、節點處理、出口路由與目標網站共同組成。先測試直連基準，再固定節點，接著透過更換網路、更換節點與更換模式逐層對照，通常就能快速區分節點負載、電信業者線路、DNS 等待與裝置瓶頸。
如果所有節點在同一網路下都很慢，而切換網路後恢復正常，優先處理本地網路與電信業者路徑；如果只有少數節點變慢，重點檢查節點負載與出口線路；如果網頁首次開啟很慢但下載穩定，檢查 DNS；如果只有特定應用程式異常，確認系統代理或 TUN 是否真的接管流量。依層記錄、逐項修改，完成後恢復暫時設定，可以避免把單純問題擴大成多項設定衝突。
選擇對應平台的安裝包
前往下載中心確認作業系統與架構，再依使用文件完成安裝、匯入訂閱與基本連線檢查。