先把「速度慢」拆解成可測量的問題
Clash 顯示的延遲、網頁開啟時間和檔案下載速度並不是同一項指標。延遲測試通常只會請求一個很小的 HTTP 資源，用來觀察建立連線與取得回應所需的時間；下載速度還會受到目標伺服器頻寬、跨境線路、TCP 壅塞控制、協定開銷和本機無線網路影響。某個節點顯示 68 ms，不代表一定能跑滿頻寬；另一個節點顯示 145 ms，也不代表觀看影片必然卡頓。
排查前先固定變因。不要同時切換節點、修改 DNS、開啟 TUN，再根據一次測速結果下結論。建議先記錄目前的網路、代理模式、節點名稱和測試時間，接著依照「直連基準—單節點延遲—單連線下載—多連線下載」的順序測試。每項至少測試 3 次，取中位數，不要只看最高值。
建立一組可重現的基準資料
- 暫停 Clash 的系統代理與 TUN 模式，在同一台裝置上測試直連網路。若 500 Mbps 寬頻直連只能達到 35 Mbps，應先檢查 Wi-Fi、網路線或電信業者網路。
- 重新啟用 Clash，選擇「規則」模式，並固定使用一個節點，不要使用會自動切換成員的策略群組。
- 關閉雲端硬碟同步、系統更新、遊戲平台下載和瀏覽器背景影片，避免這些工作佔用頻寬。
- 分別在 09:00、20:00 和 23:00 測試。晚間尖峰時段明顯下降，通常更接近線路壅塞，而不是用戶端設定錯誤。
- 記錄延遲、下載速度、上傳速度、封包遺失情況和目標網站。只有在相同測試目標下取得的資料，才適合互相比較。
| 測試項目 | 範例結果 | 主要判斷項目 |
|---|---|---|
| 直連下載 | 468 Mbps | 本機接入網路是否正常 |
| 節點延遲 | 82 / 86 / 80 ms | 連線穩定性與基本往返時間 |
| 代理單連線下載 | 6.8 MB/s | 單一連線的線路品質 |
| 代理多連線下載 | 22.4 MB/s | 節點總頻寬與並行能力 |
第一層：檢查節點品質與協定開銷
完成基準測試後，先處理最容易更換的節點層。訂閱中的地區名稱只是標籤，「香港 01」和「日本 02」無法直接說明入口位置、出口電信業者或晚間尖峰容量。真正有參考價值的是連續測試結果、不同時段的表現，以及該節點連往目標網站時實際經過的線路。
延遲要看穩定性，不只看最低值
在用戶端的代理或策略頁面執行延遲測試時，連續測試 3 至 5 次。若結果為 75、79、81 ms，穩定性通常優於 42、180、逾時、96 ms 的節點。後者雖然曾出現 42 ms，實際使用時卻可能頻繁重傳或斷線。測試 URL 也會影響結果，應維持用戶端預設網址，或固定使用能穩定回傳小檔案的 HTTPS 網址，不要在比較過程中反覆更換。
- 低於 80 ms：通常適合網頁、即時通訊和對延遲敏感的互動，但仍需確認頻寬。
- 80 至 180 ms：跨境連線的常見區間，影片與下載是否順暢主要取決於線路穩定性。
- 高於 250 ms：網頁首個封包、遠端終端機和即時操作可能明顯變慢。
- 頻繁逾時：應優先視為節點無法連線、測試目標無法連線或鏈路不穩定，而不只是「延遲高」。
流量倍率影響用量計費，不直接代表速度
節點名稱中的「0.5×」「1×」「2×」通常表示訂閱服務的流量計費倍率。下載 1 GB 資料時，2× 節點可能會計入 2 GB 用量，但倍率本身不保證速度更快。高倍率節點有時代表較昂貴的線路，有時只是資源分組方式，最終仍應以相同時間、相同目標的實測結果為準。
協定與加密會佔用 CPU
在現代桌上型處理器上，常見代理協定的處理開銷通常不是第一個瓶頸；但舊款路由器、低功耗迷你主機和入門級 Android 裝置，可能在高速傳輸時出現單核心滿載。測速期間開啟系統工作管理員或活動監視器：如果 mihomo、Clash 或用戶端核心持續接近單一 CPU 核心的上限，同時速度不再提升，就需要考慮裝置效能、協定參數和加密開銷。
- 關閉重複執行的代理核心，確認系統中只有目前用戶端正在監聽代理連接埠。
- 桌面版優先使用目前用戶端支援的穩定版 mihomo 核心，不要混用來源不明的舊核心檔案。
- 在路由器上執行時，將相同訂閱匯入桌面版重新測試。桌面版速度快、路由器速度慢，通常表示瓶頸位於路由器 CPU、記憶體或網路介面。
- 不要為了測速任意修改訂閱下發的協定欄位，例如傳輸層、伺服器名稱或 Reality 參數；這些欄位必須與伺服器端一致。
第二層：判斷入口、出口與晚間尖峰線路壅塞
節點本身可用，不代表從目前電信業者到節點入口的線路始終順暢。家庭寬頻到代理入口、入口到出口、出口到目標網站，是三段不同的鏈路。任何一段發生壅塞，都可能表現為延遲正常但下載速度低，或白天正常、晚上明顯變慢。
透過時間與網路交叉測試定位壅塞
最有效的方法不是連續切換幾十個節點，而是進行小規模對照。選擇同一地區的 2 個節點、不同地區的 2 個節點，在固定測試目標上分別記錄結果。接著將電腦從家庭 Wi-Fi 切換到手機熱點，再測試相同節點。如果家庭寬頻只有 3 MB/s、手機熱點卻達到 14 MB/s，問題更可能與本機電信業者通往入口的路徑有關；如果兩種接入網路都很慢，則應繼續觀察節點容量或出口品質。
| 現象 | 較可能的原因 | 下一步 |
|---|---|---|
| 白天 18 MB/s，晚間 2 MB/s | 晚間尖峰線路或節點容量壅塞 | 更換入口線路或避開尖峰時段重新測試 |
| 延遲穩定，單一連線慢、多連線快 | 單一連線受限或跨境封包遺失 | 更換線路並測試實際應用 |
| 所有節點同時變慢 | 本機網路、訂閱入口或上游服務故障 | 測試直連與手機熱點 |
| 只有一個目標網站速度慢 | 目標網站出口、分流或 CDN 路徑 | 核對規則命中情況與出口地區 |
地區距離不是唯一標準
實體距離較近通常有助於降低延遲，但線路品質可能改變結果。台灣使用者連線到香港節點，不一定總比東京節點快；若某條東京線路擁有更穩定的電信業者互聯，晚間尖峰表現可能更好。選擇地區時也要考慮目標服務的 CDN 調度和存取限制。用於軟體倉庫下載、影片播放和遠端辦公的最佳節點可能不同，因此可以分別建立策略群組，而不是讓所有流量長期擠在同一個節點。
第三層：核對分流規則、代理連接埠與 TUN 模式
確認節點與線路沒有明顯異常後，再檢查本機設定。常見問題通常不是代理核心「限速」，而是目標流量沒有採用預期策略、應用程式繞過系統代理、多個代理程式互相覆蓋，或 TUN 與安全軟體同時處理封包。
先查看連線記錄中的規則命中情況
開啟用戶端的「連線」或「日誌」頁面，造訪速度異常的網站，確認網域、規則名稱和最終策略。不同用戶端的選單名稱略有差異，常見路徑是「連線」→ 選擇請求 → 查看「規則」與「代理鏈」，或「日誌」→ 將層級調整為 Info 後重新提出請求。若目標網站命中 DIRECT，表示它沒有經過代理；若命中自動策略群組，還要繼續確認該群組目前選用了哪個節點。
Clash 規則會依照由上到下的順序比對，最先命中的規則生效。過於寬泛的規則若放在前面，可能覆蓋後方的精確規則。例如將區域網路與中國大陸規則放在代理規則之前通常合理，但自訂的 DOMAIN-SUFFIX 若位置錯誤，就可能讓目標網域採用錯誤策略。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- DOMAIN-KEYWORD,example,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy修改規則後應重新載入設定，並在連線頁面關閉舊連線再測試。現有 TCP 連線通常不會因策略變更而自動移轉到新節點。瀏覽器中的長連線、HTTP/2 與 HTTP/3 可能讓舊路徑繼續存在，因此必要時可完全退出瀏覽器後重新開啟。
確認連接埠沒有重複轉送
常見的本機連接埠包括 HTTP 代理 7890、SOCKS5 代理 7891，以及合併兩者的 mixed-port: 7890。實際連接埠以目前設定為準。瀏覽器擴充功能、下載工具和終端機環境變數都應指向正在監聽的連接埠，避免出現「應用程式代理到舊用戶端，舊用戶端再轉送到新用戶端」的鏈式代理。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info在用戶端中可沿著「設定」→「參數設定」尋找混合連接埠、系統代理與區域網路連線選項。若介面路徑不同，則直接查看目前設定中的 mixed-port。只有在確實需要讓其他裝置連入時才啟用區域網路連線，並確認作業系統防火牆規則與監聽位址相符。
只有需要接管更多流量時才啟用 TUN 模式
系統代理主要影響遵循作業系統代理設定的應用程式，部分遊戲、命令列程式和使用自有網路堆疊的軟體會繞過它。TUN 模式透過虛擬網路介面接管更多流量，能解決「瀏覽器正常、其他應用程式直連」的問題，但不會自然提升節點速度。相反地，驅動程式衝突、錯誤路由、MTU 不合適或重複接管都可能降低吞吐量。
- 先關閉 TUN，只啟用系統代理測速；再關閉系統代理，單獨啟用 TUN 重新測試，避免兩種路徑難以區分。
- 若啟用 TUN 後網頁正常但大檔案卡住，可檢查 MTU。常見測試範圍為 1280 至 1500，但應依照接入網路逐步調整，不宜直接照搬他人的參數。
- 暫時退出其他 VPN、網路加速器、封包擷取工具和虛擬網路卡軟體，排除路由優先順序衝突。
- 修改 TUN 設定後重新啟動核心，並確認系統路由表與 DNS 劫持功能已依照用戶端提示生效。
DNS 設定：解決解析緩慢、污染與錯誤分流
DNS 通常不會決定大檔案傳輸的持續速度，但會影響第一個頁面的開啟時間、CDN 位址選擇和依網域進行的分流。典型症狀包括：第一次開啟網站要等待數秒，重新整理後變快；同一節點存取網域很慢，直接存取已知 IP 卻正常；連線記錄中只出現 IP，網域規則沒有命中。
避免系統 DNS 與代理 DNS 互相衝突
使用 mihomo 核心時，DNS 設定可能包含 nameserver、proxy-server-nameserver、fallback、fake-ip 等項目。nameserver 用於一般查詢，代理伺服器的網域本身需要先由可用的解析器解析；如果這個步驟依賴尚未建立的代理，就可能形成解析迴圈。訂閱已提供完整 DNS 設定時，應先驗證原始設定，而不是一次加入大量公共解析器。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
proxy-server-nameserver:
- 223.5.5.5這段設定只是結構範例，不適合直接覆蓋所有訂閱。若網路支援 IPv6，但代理節點或規則未正確處理 IPv6，應用程式可能優先嘗試無法使用的位址並等待逾時。排查時可以暫時設定 ipv6: false 進行對照；確認問題後，再依實際網路能力決定是否恢復，不要長期依賴試錯開關。
Fake-IP 模式下檢查排除項目
fake-ip 會為網域回傳保留位址，並由核心在連線階段還原網域，從而提升規則比對能力。區域網路裝置探索、印表機、部分遊戲登入和依賴真實 DNS 回應的應用程式，可能需要加入排除清單。若只有某個應用程式啟動緩慢，可先查看日誌中是否出現重複 DNS 查詢、連線重試或區域網路網域被代理，再補充精確的排除項目，避免排除整個頂級網域。
本機裝置與網路：排除 Wi-Fi、瀏覽器和背景工作
如果所有節點都達不到直連基準，就需要回到裝置層排查。2.4 GHz Wi-Fi 在擁擠環境中可能只能提供數十 Mbps 的穩定吞吐量，訊號格數滿格也不代表干擾少。條件允許時，使用網路線或 5 GHz、6 GHz Wi-Fi 進行對照測試，並將裝置移到路由器附近。若網路線能達到 460 Mbps，而原位置的 Wi-Fi 只有 72 Mbps，繼續更換節點也無法解決問題。
使用系統監控確認瓶頸位置
- CPU：代理核心的單一核心持續滿載，速度隨 CPU 使用率封頂，應優先檢查裝置效能與協定處理。
- 記憶體：系統頻繁交換記憶體時，瀏覽器、下載工具和代理核心都會出現停頓。
- 磁碟：下載到傳統硬碟、加密容器或即時同步目錄時，寫入速度可能成為瓶頸。
- 背景流量：作業系統更新、相片備份和遊戲平台可能佔滿上傳頻寬，進而拖慢下載確認封包與網頁回應。
- 瀏覽器擴充功能：代理擴充功能若另行設定規則或連接埠，會覆蓋系統代理。可以使用全新的瀏覽器設定檔進行一次對照。
測速時也應關閉瀏覽器的平行下載實驗選項和第三方下載擴充功能，先用預設設定取得基準。若只有一個瀏覽器速度慢，而系統下載工具與其他瀏覽器正常，問題通常位於擴充功能、快取、HTTP/3 或瀏覽器代理覆蓋，而不是 Clash 核心。
依症狀執行的十分鐘排查順序
- 第 1 分鐘：關閉系統代理和 TUN，測試直連速度，確認本機寬頻基準。
- 第 2 分鐘：退出其他 VPN、代理用戶端和網路加速工具，只保留一個 Clash 用戶端。
- 第 3 分鐘：啟用規則模式，固定單一節點，連續測試 3 次延遲並記錄波動。
- 第 4 分鐘：使用相同目標測試單連線與多連線下載，區分延遲問題和吞吐量問題。
- 第 5 分鐘：選擇另一個地區、另一個入口的節點重新測試，不要只更換同一群組中編號相鄰的節點。
- 第 6 分鐘：開啟連線記錄，確認目標網域命中的規則、策略群組與實際節點。
- 第 7 分鐘：核對應用程式代理連接埠與
mixed-port，清除舊用戶端留下的代理設定。 - 第 8 分鐘：分別測試系統代理和 TUN，觀察是否只有 TUN 路徑變慢。
- 第 9 分鐘：檢查 DNS 日誌、IPv6 與 Fake-IP 排除項目，留意首次連線是否長時間等待。
- 第 10 分鐘：切換手機熱點或有線網路重新測試，利用不同接入網路判斷電信業者路徑與 Wi-Fi 問題。
最終記錄至少應包括測試日期、時間、接入網路、用戶端核心、代理模式、節點、延遲、下載速度和規則命中情況。若白天穩定、晚間下降，應優先處理線路；若所有節點都很慢，應優先處理本機網路和設定；若只有一個應用程式速度慢，應優先檢查該應用程式的代理方式、DNS 與連線協定。依照三層順序保留對照資料，比反覆更新訂閱或隨機切換節點更容易找出真正的瓶頸。