Clash 網速慢
分層排查

先分辨：連線慢、下載慢，還是只有特定網站慢

Clash 面板顯示的延遲，只代表對指定網址進行單次探測的結果，不等於下載頻寬，也無法代表所有網站的連線品質。延遲 80 ms 的節點，可能因出口壅塞而速度很慢；延遲 180 ms 的節點，持續下載時反而可能更穩定。先描述實際狀況，再決定排查方向。

測試前先暫停雲端硬碟同步、遊戲平台更新及其他大量傳輸作業。固定同一台裝置、同一個網路和同一個目標網址，每組至少測試 3 次。記下測試時段、規則模式、實際使用的節點、下載速度與錯誤訊息；測速時連續切換節點會讓不同連線走不同出口，結果不易比較。

第一層：確認本機監聽連接埠與實際流量路徑

不要把範例連接埠當成目前使用的連接埠

開啟用戶端的連接埠設定，確認目前的 HTTP、SOCKS 或混合連接埠。常見範例是 7890，但有些用戶端使用其他數值。HTTP 連接埠不能直接當作 SOCKS 連接埠使用；mixed-port 才會在同一個監聽連接埠接受 HTTP 與 SOCKS 代理要求。

以下是用來說明監聽設定的 mihomo 設定片段，不是包含節點、策略群組與規則的完整訂閱。圖形介面用戶端可能會產生執行設定，建議先在用戶端設定中修改，以免訂閱更新時覆蓋手動變更。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

• mixed-port: 7890：本機應用程式可連線至 127.0.0.1:7890 使用代理。
• allow-lan: false：不對區域網路開放代理入口；排查本機網速時不需要啟用。
• mode: rule：由規則選擇策略，不代表所有連線都會經過代理。
• log-level: info：保留一般排查所需的資訊，避免長時間輸出大量除錯紀錄。

先發出一個明確指定代理的要求

Windows PowerShell 請使用 curl.exe，避免某些環境將 curl 解讀成其他命令。以下要求只用來確認 HTTP 代理入口與 HTTPS 通道是否正常，不適合測量大型檔案的下載速度。若實際連接埠不是 7890，請先替換命令中的連接埠。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com/

macOS、Linux 可將命令中的 curl.exe 改成 curl。同時在用戶端的「連線」頁面篩選 example.com，確認該連線符合的規則、策略群組與最終出口。明確指定本機代理只能證明要求進入核心；規則仍可能將目標指派給 DIRECT。

若出現無法連線至本機連接埠的訊息，先確認核心是否已啟動、連接埠是否遭占用，不要急著更換遠端節點。Windows 可執行下列命令查看監聽狀態與 PID；若沒有輸出，通常表示該連接埠沒有 TCP 監聽。出現 PID 後，請在工作管理員的「詳細資料」中確認所屬程序。

netstat -ano | findstr LISTENING | findstr :7890

第二層：確認節點負載與策略群組選擇

節點名稱通常只是服務提供者的標示，不能據此確認實際位置或傳輸線路。排查時先在策略群組中固定選取一個節點，再查看連線詳細資料。若測試群組使用 url-test、fallback 或 load-balance，新連線可能自動切換或分配出口，不能只看策略群組名稱就當作固定節點。

1. 在目前符合條件的策略群組中選定節點 A。若使用自動群組，可暫時改用既有的手動選擇群組；請先備份設定，不要直接覆寫整份訂閱。
2. 關閉原有下載工作，再重新建立連線。切換節點通常不會將已建立的 TCP 連線移轉至新出口。
3. 使用同一個下載來源測試 3 次，每次觀察約 30 秒；記錄速度穩定後的數值，不要只記錄剛開始的峰值。
4. 使用節點 B 重複相同步驟。優先選擇與 A 不同線路或不同服務提供者的節點，而不是只換成名稱相似的節點。
5. 換個時段再次測試。夜間變慢、白天正常，是容量不足或路徑壅塞的線索，但還不能單憑這點認定伺服器負載過高。

如何判斷是「節點慢」，而不是「測試來源慢」？

若節點 A 連線至兩個獨立下載來源都很慢，而 B 在相同裝置與網路下都正常，可優先懷疑 A 的入口、出口或資源限制。若所有節點只有連線至某個下載來源時才慢，則應優先檢查該網站的單一連線限速、帳號限制與 CDN 調度。公共測速網站的多連線成績，也不能直接代表瀏覽器下載單一檔案的速度。

第三層：區分本機網路與遠端線路問題

「直連正常、代理很慢」仍有多種可能：本地電信業者到節點入口的路徑壅塞、節點出口到目標網站的品質不佳，或代理協定所使用的連線受到限制。使用同一台裝置切換不同網路，是區分這些因素的有效方法。

Windows 可先用 ipconfig 查看目前的預設閘道，再對實際閘道位址執行 ping -n 30；macOS、Linux 可使用 ping -c 30。不要直接把範例閘道位址當成自己的路由器位址。若閒置時區域網路延遲仍明顯波動，或持續發生封包遺失，應先檢查 Wi-Fi 頻道、裝置距離、網路線與路由器負載。

對節點入口執行 Ping 或路由追蹤，只能作為旁證。部分伺服器不回應 ICMP，中間路由器也可能限制探測封包；某一跳顯示封包遺失，但後續節點與最終目標正常，並不代表轉送資料真的遺失。不要只憑一張路由追蹤圖就判定節點故障。

只有上傳或下載時速度變慢

若閒置時網路正常，但上傳檔案後網頁和語音通話都變卡，可能是上行頻寬用滿造成封包排隊。先將上傳速度限制在可用上行頻寬的約 80%～90%，再重複測試。這個範圍只是排查起點，並非固定的最佳值；支援佇列管理的路由器也可以進一步調整。不要同時修改用戶端、路由器和節點，否則很難找出是哪項變更改善了結果。

用 curl 分別查看等待時間與傳輸速度

選用允許下載、大小已知且能持續傳輸一段時間的 HTTPS 檔案，比反覆重新整理網頁更容易比較。不要用幾 KB 的頁面推算頻寬，也避免使用需要瀏覽器登入、驗證碼或短效簽章的網址。以下命令適用於 macOS、Linux 常見的 shell；互動輸入已確認可用的下載網址，檔案不會儲存至磁碟。

printf '請輸入測試檔案的 HTTPS 網址：'
IFS= read -r test_url
curl --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  --location \
  --connect-timeout 10 \
  --max-time 30 \
  --output /dev/null \
  --write-out '\nhttp=%{http_code}\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$test_url"

• http：先確認收到的是正常內容，而不是 403、429 或錯誤頁面。206 可能代表伺服器回傳部分內容。
• first_byte：從送出要求到收到第一個位元組的時間，包含前面的連線與交握過程，並非單獨的 DNS 查詢耗時。
• total：這次要求的總耗時，會受到重新導向、伺服器等待與實際傳輸時間影響。
• speed：這次傳輸回報的平均下載速度，單位為位元組／秒；應搭配有效內容大小與測試時間一起判讀。

大型檔案若未能在 30 秒內傳輸完成，命令可能因逾時而結束，這是 --max-time 30 的預期限制；應一併參考已下載的位元組數，不要把所有逾時都當成線路中斷。若測試檔案幾秒就傳完，請改用更大的檔案，或註明這只是短時間樣本。

透過 HTTP 代理存取 HTTPS 目標時，目標網域通常會由代理鏈路負責解析。curl 顯示的本機 DNS 計時，不能直接代表 mihomo 內部解析目標網域所花的時間。首位元組耗時偏長時，應搭配核心紀錄、規則命中情況與實際 DNS 設定一起分析，不能只看單一計時欄位。

本機設定：分別檢查系統代理、TUN 與 DNS

先選擇一種接管方式，建立基準

系統代理主要影響會讀取系統設定的應用程式。終端機、部分遊戲與使用自有網路堆疊的軟體可能不會套用這項設定。TUN 則透過虛擬網卡與路由接管符合條件的 IP 流量，但仍會受到規則、排除項目、權限與平台實作方式影響，並不代表所有連線都會經過遠端代理。

1. 暫停其他 VPN、網路加速器與代理軟體，檢查是否有重複的系統代理或虛擬網卡接管設定。
2. 先關閉 TUN，使用前述 curl 明確指定代理的命令建立基準；這個步驟不依賴應用程式讀取系統代理設定。
3. 接著啟用系統代理並測試瀏覽器。Windows 11 可在「設定」→「網路和網際網路」→「Proxy」檢查系統設定，並確認瀏覽器代理擴充功能是否覆寫了該設定。
4. 需要讓不支援代理的應用程式也經過代理時，再啟用 TUN；確認用戶端服務已安裝、已授予所需權限，並以新連線進行比較。

若只有啟用 TUN 後速度變慢，應優先檢查路由衝突、DNS 劫持設定與虛擬網卡狀態。不要一開始就調整 MTU。只有在「小型要求正常，大型回應或特定連線反覆卡住」等狀況可穩定重現，且已排除其他因素後，才適合進一步檢查路徑 MTU；調整前先記下原值，每次只修改一項。

設定 DNS 別抱著「越多越快」的想法

mihomo 的 dns.nameserver、dns.proxy-server-nameserver 與 dns.nameserver-policy 處理的對象各不相同。解析節點伺服器網域與解析目標網站網域也是兩回事。修改時應以目前核心文件與訂閱設計為準，避免解析節點所需的 DNS 又依賴尚未建立的代理鏈路。

使用 fake-ip 時，用戶端取得對應位址可能是正常機制，不能直接判定為解析錯誤。若只有少數應用程式不相容，可評估針對相關網域設定 fake-ip-filter，而不是立刻關閉整個 DNS 模組。IPv6 也應透過比較有、無 IPv6 路徑的測試來定位問題，不建議將關閉 IPv6 當成所有網速問題的通用解法。

設定無法載入時，先查看核心錯誤訊息，再進行測速。使用 mihomo 命令列的使用者，可在設定檔所在目錄執行下列檢查；圖形介面用戶端則使用內建的設定檢查與紀錄功能。語法檢查通過只代表設定可以解析，不保證節點可用或規則符合預期。

mihomo -t -f config.yaml

最後整理：以最少變更得出可重現的結論

有效的排查應能說明「改變哪個條件後，哪項指標也跟著改變」。例如，同一台裝置、同一個節點、同一個檔案，在家用寬頻下很慢、手機熱點下正常，應優先追查網路連線至節點入口的路徑；同一網路下節點 A 連線至兩個目標都很慢、節點 B 正常，則應優先聯絡服務提供者檢查 A 的線路與資源。

• 只有瀏覽器很慢：檢查代理擴充功能、網站快取，以及該網站實際命中的規則，不必先重新安裝整個用戶端。
• 所有節點都很慢：確認直連基準、本機監聽、背景流量與其他網路軟體，再檢查是否有共同的服務提供者限制。
• 只有自動策略群組很慢：固定節點重新測試，並檢查探測網址、切換行為與新連線實際使用的出口。
• 更新訂閱後變慢：比較策略群組、規則順序與節點變化，並保留備份；不要只比較訂閱檔案大小。
• 需要他人協助：提供作業系統版本、用戶端版本、核心版本、測試時段、網路連線、重現步驟與已移除敏感資訊的紀錄。