一、先分辨網頁載入慢、下載慢還是連線中斷

Clash 顯示節點延遲正常，影片卻一直緩衝，兩者並不矛盾。節點卡片上的延遲通常來自單次測試，只反映當下連線至測試網址的回應狀況；持續下載速度還會受到節點負載、跨網路線、目標網站限速及本機 Wi-Fi 影響。開始排查前，先把「速度慢」轉化為可重複觀察的現象。

現象優先檢查項目比對方式
第一次開啟要等很久，之後就正常DNS、建立連線與 TLS 交握比較首次與再次造訪所需時間
網頁開得了，大型檔案下載卻一直很慢節點傳輸量、線路壅塞、伺服器限速下載同一個檔案，先換節點，再換網路
只有一個應用程式速度慢或無法連線應用程式的代理支援、命中規則、UDP 路徑查看該應用程式的實際連線紀錄
直連網站和代理網站都很慢Wi-Fi、路由器、寬頻與背景流量暫時關閉代理，測試本機網路

建立可重複比對的基準

  1. 暫停雲端硬碟同步、遊戲下載和系統更新，測試期間保持裝置、地點與目標檔案一致。
  2. 在用戶端的「代理」頁面展開目前的策略群組，暫時手動選定一個節點，避免自動選擇群組在測試途中切換出口。
  3. 針對同一個目標連續測試 3 次，每次記錄開始時間、首次畫面等待時間和穩定下載速度；大型檔案可觀察約 30 秒，並留意流量用量。
  4. 每輪只變更一個條件，依序比較「節點 → 網路連線 → 本機設定」。

二、節點層：低延遲不代表頻寬充足

先開啟用戶端的「代理」頁面，找出目前規則使用的策略群組，再選擇特定節點。Clash Verge Rev 等圖形介面用戶端，常見入口包括側邊欄的「代理」、「連線」和「日誌」；其他用戶端的名稱可能不同，請以目前介面為準。除了查看節點卡片，也要前往「連線」頁面，確認測試請求實際經過剛才選取的節點。

透過三種比對方式判斷是否為節點問題

  • 更換相同地區的節點：維持目標不變，比較兩個相同地區的節點。如果只有其中一個長期速度偏慢，較可能與該節點的負載、限速或出口有關。
  • 更換不同地區的出口：如果某個地區的節點普遍較慢，換到另一個地區後恢復正常，代表值得進一步檢查路徑，或目標網站至該出口的連線；這不代表本機用戶端設定已損壞。
  • 更換目標檔案：同一個節點連線其他網站正常，只有某個下載來源速度慢，應檢查該網站的帳戶限速、CDN 配置或單一連線限制。

不要連續執行全部節點測速後，立刻拿結果比較下載速度。批次測試會在短時間內增加請求；部分用戶端的「延遲測試」與「下載測速」也不是同一項功能。先停止測試，再逐一比較節點；如果訂閱方案有流量上限，大量測速本身也會耗用流量。

確認更新訂閱後是否改變了節點選擇

前往「訂閱」或「設定檔」頁面，確認目前啟用的 Profile，並查看上次更新時間與更新結果。訂閱更新後，節點名稱或群組成員可能有所變動，先前手動選取的節點不一定仍有效。返回「代理」頁面重新確認，再到「連線」頁面驗證實際路徑。請勿將含有帳戶權杖的訂閱網址貼到公開網站。

三、線路層：透過更換網路和分時段測試找出壅塞

節點名稱中的地區通常指出口位置，無法完整呈現入口、跨網路或中轉路徑。同一個出口在不同電信業者的網路上，表現可能不一樣。如果更換節點的效果不穩定，下一步應比對網路連線，而不是馬上重設 DNS。

  1. 先排除無線網路問題：保持節點不變，讓電腦靠近路由器；情況允許時改用網路線。觀察連線同一個目標是否恢復正常，避免把訊號微弱或無線干擾誤判為代理線路壅塞。
  2. 再改用手機熱點比對：讓同一台電腦改連手機熱點，維持節點和目標不變。如果速度明顯變快，問題可能與原本的寬頻路徑、路由器或網路連線有關；使用熱點會耗用行動數據。
  3. 記錄尖峰時段的差異：例如分別在 10:00、20:30 和 23:30 執行同一組測試。如果只有晚上速度普遍下降，較符合共用線路負載增加的情況；但僅憑時段變化，無法判定具體的壅塞位置。

一般的 ping 通常使用 ICMP 傳送封包，不會因為開啟系統 HTTP 代理就自動經過代理節點，因此不能直接用 ping 的結果代表代理下載速度。路由追蹤也可能遇到中間設備未回應；單一節點逾時，不能單獨證明該處有封包遺失。更有參考價值的做法，是在同一裝置上，以不同網路連線比對相同目標的應用程式連線狀況。

四、DNS 層：先確認解析路徑，再調整設定

DNS 異常常見的現象包括首次開啟網站很慢、部分網域無法連線，或解析到不合適的 CDN 位址；但通常無法解釋連線建立後持續穩定的低傳輸速度。如果下載已持續進行但速度偏慢，應優先完成節點與線路的比對。

檢查三個可能各自獨立的 DNS 解析位置

  • 系統 DNS：影響未由用戶端接管的 DNS 解析。在 Windows 中，可於終端機執行 ipconfig /all，查看目前網路介面的 DNS 伺服器。
  • 核心 DNS：開啟目前設定檔的 DNS 區段，檢查 dns.enable、enhanced-mode 和上游 DNS 位址。使用 mihomo 的用戶端也可能透過覆寫產生最終設定，因此應檢查正在執行的設定，而不只查看訂閱中的原始檔案。
  • 瀏覽器安全 DNS：瀏覽器可能另外使用加密 DNS。Chrome 常見的設定位置為「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」；測試時先記下原本的設定，暫時關閉作為比對，完成後視需要還原。

啟用 fake-ip 時，應用程式看到合成位址是此模式的正常運作方式，不要只因位址不是公網 IP 就認定 DNS 解析錯誤。反過來說，瀏覽器獨立進行 DNS 解析、應用程式保留舊位址快取，或網域未納入接管範圍，都可能導致規則比對結果與預期不同。

修改前先備份設定，每次只調整一項。訂閱管理用戶端應優先使用支援的覆寫功能，避免下次更新時修改內容遭到覆蓋。上游 DNS 的連線路徑也必須可用；若隨意改成只能透過目前代理才能連線的位址，可能讓排查更加複雜。欄位設定請以所使用的核心文件為準，勿將 mihomo 設定直接套用到所有舊版 Clash 核心。

清除快取後再比對

在 Windows 變更 DNS 後，可在命令提示字元執行以下命令，再完全關閉並重新開啟測試中的應用程式。這只會清除系統 DNS 解析快取，不會清除瀏覽器的所有快取，也不會提升線路頻寬。

ipconfig /flushdns

五、規則層：確認實際出口與連線模式

開啟用戶端的「連線」頁面，重新造訪目標網站，依網域篩選新連線，檢查命中的規則、策略群組和最終節點。Clash 規則路由通常依照由上而下的順序比對；範圍過廣的前置規則，可能讓原本應直連的服務繞道遠端，也可能讓需要代理的服務直接連線。

  1. 確認目前模式為 Rule，並記錄目標連線所命中的規則與出口。
  2. 暫時切換至 Global，並在全域策略群組中選擇同一個待測節點，再造訪相同目標。
  3. 如果全域模式正常、規則模式異常，優先檢查分流規則和群組選擇；如果兩種模式都很慢，則回頭檢查節點、連線路徑與目標網站。
  4. 測試後恢復為 Rule，避免長時間讓本機服務或中國大陸的服務繞道連線。

以下是最簡化的規則順序示意，只用來說明「特定網域規則在前，預設規則在後」。其中的 PROXY 必須是目前設定檔中實際存在的策略群組；請勿以此內容取代整份訂閱。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

切換節點或規則後，既有的長連線可能仍沿用原本的出口。可以先暫停下載，再重新開始；或只在「連線」頁面關閉目標連線，接著觀察新連線。關閉所有連線會中斷會議、檔案傳輸等工作，不應每次排查都預設採用。

六、本機流量接管層：系統代理、TUN 與應用程式協定

系統代理主要供遵循系統代理設定的應用程式使用，並不會自動接管所有程式。TUN 透過虛擬網路介面接管流量，實際涵蓋範圍則取決於路由、權限、排除項目和核心實作。TUN 不是頻寬加速開關：如果瀏覽器已正確使用系統代理，單純啟用 TUN 通常無法解決節點壅塞。

使用明確指定的代理測試，區分流量接管問題

先在用戶端的「設定」中尋找連接埠設定，或在執行設定中查看 mixed-port。以下指令假設混合連接埠為 7890；如果實際使用的是 7897 或其他數值，請務必替換。Windows 請使用 curl.exe，macOS 和 Linux 請使用 curl；範例只會連線至公開測試網域，不會測試大型檔案的頻寬。

curl --proxy http://127.0.0.1:7890 -o /dev/null -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

在 Windows 中，請將上方指令的 curl 改為 curl.exe，並將 /dev/null 改為 NUL。這些時間是從請求開始起累計的時間點；使用本機代理時，time_connect 主要反映連線至本機代理所需時間，不能視為節點往返延遲。first_byte 也包含目標伺服器的處理時間。

  • 明確指定代理時正常，但應用程式速度慢：檢查應用程式是否使用系統代理、是否設定了專屬代理位址，以及新請求是否出現在「連線」頁面。
  • 只有啟用 TUN 時異常：檢查服務模式或管理員權限、路由衝突和 DNS 接管狀態；先將相關設定還原為用戶端預設值，再逐項比對。
  • 只有影片或即時應用程式異常：部分應用程式使用 QUIC 或其他 UDP 協定。HTTP 代理測試正常，不代表 UDP 路徑也正常；還需確認節點與用戶端支援並允許相應流量。

不要一開始就隨意調整 MTU、關閉 IPv6 或整套更換 DNS。只有在特定網路下大封包會卡住、某類位址持續連線失敗等現象可重複發生時，才值得針對該項繼續檢查。如果懷疑裝置效能不足，可查看工作管理員或活動監視器：下載時核心程序是否持續占滿一個邏輯核心，以及路由器是否同時處理大量連線。

七、保留排查紀錄，依據證據決定下一步

完成一輪排查後，保留能重現問題的最小條件組合，而不是存下數十張缺少說明的測速截圖。以下資訊足以協助釐清問題範圍，也方便向訂閱服務業者或用戶端維護者描述情況。

  • 環境：作業系統、用戶端名稱、用戶端與核心版本；請從「關於」頁面或啟動記錄複製實際資訊。
  • 路徑：寬頻或手機熱點、測試時間、節點代號、目標網域；請勿公開帳戶資訊。
  • 設定：Rule 或 Global、系統代理或 TUN、目標命中的規則與最終出口。
  • 結果：各組 3 次測試的等待時間與穩定速度，以及更換節點或網路後是否改善。

需要提交記錄時，只在短時間內提高記錄層級並重現一次，之後恢復平常使用的層級。分享前請遮蔽訂閱權杖、節點密碼、個人 IP 和瀏覽紀錄。更多基礎操作請參考Clash 設定手冊中的代理模式、規則分流與 TUN 章節；如果尚未完成首次連線，請先依照使用文件確認設定已啟用，再比較速度。