Clash 網速慢排查

先分辨：網頁開啟慢、下載慢，還是連線中斷

FlClash 使用 Clash Meta（mihomo）核心處理代理連線。瀏覽網頁時，可能會經過網域解析、規則比對、連接節點、遠端請求及內容傳輸等步驟。任何一個環節變慢，都可能讓人覺得「Clash 網速慢」，但對應的處理方式各不相同。先記下具體症狀再調整設定，才不會把線路問題誤認為 DNS 問題。

先暫停雲端硬碟同步、系統更新和其他下載。固定同一台裝置、同一個網路和同一個目標檔案，確保測試條件一致。家用寬頻標示的單位通常是 Mbps，下載工具則可能顯示 MB/s；100 Mbps 理論上約等於 12.5 MB/s。實際傳輸速度還會受通訊協定負擔、無線訊號和遠端限制影響，兩種數值不能直接比較。

節點層：固定策略組，測試相同目標

延遲測試結果低，不代表下載速度一定快。用戶端的延遲檢測通常是測量對指定位址送出一次請求所需的時間，會受測試位址、快取和建立連線的過程影響，無法直接代表持續傳輸頻寬。顯示 60 ms 的節點可能很擁塞；顯示 160 ms 的節點也可能維持較高下載速度。

依 A → B → A 的順序測試

1. 開啟策略組，暫時手動選擇節點 A。若使用自動選擇或故障轉移群組，請先確認測試期間不會自動切換出站節點。
2. 連線至相同目標，下載同一個允許測試的檔案。每輪觀察約 30 秒，分別記錄開始等待時間和速度穩定後的數值。
3. 切換至節點 B，關閉測試頁面或停止下載後重新連線，再測試一次。最後切回 A，確認第一次速度慢是否只是偶發狀況。
4. 在 FlClash 的連線紀錄中確認網域、規則和出站鏈路。既有的長連線可能仍會使用原本的節點；切換策略組不會立即將所有舊連線轉移。

例如，紀錄顯示 A 兩輪速度都是約 1.2 MB/s，B 則為 8 MB/s，現階段只能判斷「在這個目標和時段，B 的路徑表現較好」。這些數值僅為範例，並非本站實測結果。A 的出口連到該網站時繞路、遠端依出口限速，或節點共用頻寬不足，都可能造成相同現象；建議再換另一個目標確認。

在規則模式下，同一網頁的主要文件、圖片和影片可能使用不同策略組。不要只看頁面右上角選取的節點。可以暫時比較全域模式和規則模式，但務必確認全域策略組實際選的是同一個節點。如果全域模式正常、規則模式卻很慢，請優先檢查速度慢的請求是否走直連、改用其他節點，或套用了不合適的規則順序。規則比對細節可參考進階設定中的規則說明。

線路層：比較時段、網路與目標網站

多個節點一起變慢，也不一定是本機設定錯誤。不同節點可能共用入口、出口或上游線路；名稱不同不代表網路路徑彼此獨立。加入第二種網路或改在其他時段測試，才能進一步縮小問題範圍。

• 比較時段：使用相同節點和目標，在 10:00、20:00、23:00 各測試一輪。如果只有晚上速度持續下降，記錄兩、三天的趨勢，再判斷是否為尖峰時段壅塞。
• 比較網路：同一台電腦從家用 Wi-Fi 切換至手機熱點。請留意行動數據費用，短時間測試即可。如果手機熱點恢復正常，但家用寬頻一直很慢，請優先檢查家用路由器、寬頻連線和相關互連路徑。
• 比較目標：至少測試兩個不同網站提供的合法下載資源。若只有特定網站速度慢，可能與該網站的 CDN 調度、帳號限速或出口 IP 位址有關。
• 比較區域網路：如果條件允許，改用網路線或移至路由器附近測試。如果直接連線和代理下載都很慢，請先檢查無線干擾及本機頻寬使用情況。

Ping 封包遺失只能當作線索。路由器可能會限制 ICMP 流量；中間節點沒有回應，也不代表實際服務中斷。代理通訊協定、UDP 轉送和一般 Ping 也可能走不同路徑。不要只因某一跳顯示星號就更改整套設定，應同時確認實際下載是否停頓、連線紀錄是否重試。

本機層：系統代理與其他網路工具

系統代理通常只會影響有讀取這項設定的應用程式，不會接管所有流量。TUN 模式則透過虛擬網卡和路由，接管符合條件的 IP 流量。瀏覽器能連線，不代表遊戲或命令列工具也已使用代理；反過來說，終端機中的代理環境變數也可能把請求送到舊用戶端的連接埠。

先確認一條可檢查的代理路徑

1. 暫停其他代理用戶端和非必要的 VPN，並記下原本的狀態。公司或機構管理的裝置，請勿自行停用組織要求的安全元件；應先確認管理政策。
2. 在 FlClash 目前使用的執行設定中確認實際監聽連接埠，不要把範例連接埠當成固定預設值。也要檢查瀏覽器擴充功能是否另有指定代理。
3. Windows 可至「設定」→「網路和網際網路」→「Proxy」確認系統代理；macOS 可至「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「Proxy」檢查。不同系統版本的名稱可能略有差異。
4. 關閉 TUN，只保留系統代理，並使用明確支援系統代理的瀏覽器重新測試。接著關閉系統代理，再單獨測試 TUN，避免兩種連線方式同時變動。

假設本機 HTTP 或 mixed 監聽連接埠確實是 7890，以下命令可讓這次請求明確使用該連線入口。Windows PowerShell 可使用 curl.exe；macOS 和 Linux 通常使用 curl。若連接埠不同，務必先修改命令；目標位址僅供觀察請求階段，不是頻寬測速資源。

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

在 Windows 上使用時，請將 /dev/null 改為 NUL。透過本機 HTTP 代理連線 HTTPS 時，time_connect 主要反映連至本機代理入口所需的時間，不能當成遠端節點延遲；首位元組時間則包含建立代理通道、TLS 交握和遠端回應等多個階段。這項命令適合比較前後變化，不適合只憑單一數值判定 DNS 故障。

TUN 層：先檢查流量接管與資源，再更換堆疊

如果系統代理速度正常，只有 TUN 模式明顯變慢，請先確認虛擬網卡已成功建立，且核心具備所需權限。Windows、macOS 和 Linux 的權限及服務機制各不相同；Android 則使用系統 VPN 授權，同一使用者空間中的其他 VPN 通常無法同時運作。

建議依照以下順序檢查

• 檢查實際連線：應用程式送出請求後，確認 FlClash 中是否出現對應的連線紀錄。如果沒有紀錄，先檢查路由接管和應用程式的略過設定，不要急著更換節點。
• 檢查 CPU：觀察下載期間核心程序的 CPU 使用率。只有在某個核心持續繁忙，且傳輸速度卡在固定上限時，才需要進一步調查裝置效能和資料處理負擔。
• 更換 TUN 堆疊：mihomo 常見的堆疊選項包括 system、gvisor、mixed；實際可用項目取決於平台、核心和用戶端版本。每次只更換一個選項，並依介面指示重新啟用 TUN 後測試；沒有一種設定能在所有平台上固定跑得最快。
• 最後檢查 MTU：如果小型請求正常，但大型下載會停頓，或只有特定網路的 TLS 連線反覆卡住，再檢查路徑 MTU。不要把修改 MTU 當成通用的加速方法。

只有在確實有 MTU 相關證據時，才可在設定支援的情況下，以 1400 作為診斷比較值。先記下原值再測試，若沒有改善就還原。降低 MTU 會增加傳送相同資料所需的封包數量，不保證頻寬會提高。若要調整服務模式、虛擬網卡或路由，建議先閱讀TUN 設定說明，避免留下影響其他網路的設定。

DNS 層：解析時間不等於傳輸頻寬

DNS 通常會影響首次開啟網站、建立連線和選擇位址。連線已建立後，如果大型檔案仍持續下載緩慢，通常無法只靠更換 DNS 解決。要判斷問題是否與 DNS 有關，請觀察首次請求和重複請求的差異，並查看紀錄中的逾時、解析失敗及實際目的位址。

如何判斷 Fake-IP 與 real-ip

fake-ip 會回傳用來建立映射的虛擬位址，再由核心關聯網域並處理連線；redir-host 則使用實際解析出的位址。看到 198.18.0.0/16 範圍內的位址，不代表一定異常；實際使用範圍應以目前的執行設定為準。不要因為位址看起來陌生就切換模式，也不要簡單地把兩種模式分成「快」和「慢」。

1. 查看目前實際生效的 DNS 設定，而非只看訂閱原始內容。用戶端覆寫、補丁或設定合併，都可能改變最後生效的 dns 區段。
2. 確認瀏覽器是否啟用了獨立的安全 DNS。瀏覽器透過自己的 DoH 請求解析時，系統 DNS 測試結果不一定能反映瀏覽器實際使用的路徑。
3. 檢查加密 DNS 上游是否可連線，以及 DNS 伺服器網域的初始解析是否依賴無法使用的線路。設定不當可能造成解析相互依賴或一直等待。
4. 修改解析設定後，依用戶端支援的功能清除 DNS 快取，並重新啟動測試中的應用程式。只重新整理網頁，可能仍會沿用既有連線或應用程式快取。

不要直接複製不熟悉的 DNS 清單並覆蓋所有設定。更換解析器可能會改變 CDN 位址，以及 IPv4、IPv6 的選擇；短時間內變快，不能證明解析器本身比較快。如果紀錄顯示 IPv6 連線反覆失敗，但 IPv4 穩定，請分開測試 IPv6 路徑。暫時調整相關設定可用來驗證假設，但長期仍應修復路由，或依實際網路條件設定位址族。

整理測試紀錄：確認問題所在層級

排查結束時，應能用一句話說明如何重現問題，例如：「家用寬頻在晚上使用節點 A，兩個目標下載都很慢；相同設定換成手機熱點就正常。」這比「所有節點都不行」更有參考價值。向訂閱服務提供者或用戶端專案回報時，附上已去識別化的時段、作業系統版本、FlClash 和核心版本，以及測試比較步驟即可。

只擷取問題重現前後必要的幾十秒紀錄。請先移除訂閱網址、節點密碼、驗證權杖和私人存取網域。完整訂閱連結通常包含存取憑證，不應作為公開的排查資料。測試完成後，還原暫時變更的模式、策略組和系統代理狀態，並保留已確認有效的調整。

如果能穩定重現問題，再考慮更新至專案正式發布的版本，並記錄更新前後的版本資訊和測試結果。更新不能取代問題定位；使用相同節點、相同目標並一次只改一個變數，才能判斷改善的原因。若尚未確認訂閱匯入或出站模式，可先參考設定教學建立可正常運作的基準，再繼續測速。