Clash 節點清單顯示 80ms，播放影片卻仍然緩衝；換成 180ms 的節點，下載速度反而更快。這並不矛盾：延遲測試、持續傳輸和應用程式載入測量的並非同一件事。排查時先確認慢在哪裡，再依序檢查節點、線路和本機，通常比一再修改 DNS、規則和 TUN 參數更容易找到原因。

一、分辨延遲高、傳輸量低與網頁初次開啟慢

Clash 類用戶端顯示的「延遲」，通常是透過節點向測試網址發出一次請求所得，並不等於 ICMP ping，也不能直接代表可用頻寬。測試網址、逾時時間和連線重用都會影響結果。把測試網址從一個網站換成另一個，數值可能有所變化，但目標影音平台的使用體驗未必會改善。

觀察到的情況優先檢查項目記錄指標
開啟頁面前等很久，開啟後則正常DNS、連線建立、規則命中首位元組時間、連線記錄
下載速度長時間維持低檔節點負載、出口頻寬、來源伺服器限速持續 30 秒以上的平均速度
每隔一段時間就卡住封包遺失、無線網路、節點切換失敗次數、卡頓時間點
只有一個應用程式速度慢應用程式代理設定、UDP、分流規則程序、目標網域、實際出口

建立可重複的測速條件

  1. 暫停雲端硬碟同步、遊戲更新和其他裝置的大型檔案下載；筆記型電腦接上電源，並先使用穩定的 Wi-Fi 或有線網路。
  2. 固定使用同一台裝置、同一個下載來源和同一種連線方式，選擇允許測試且檔案大小足夠的檔案，連續傳輸至少 30 秒。
  3. 每組測試 3 次，記錄中位數。不要只截取剛開始幾秒的快取峰值，也不要同時測速十幾個節點。
  4. 分別記錄直連和代理的結果。有些目標無法直連，請改用可直連的對照網站，不要直接把連線失敗當成零頻寬。

留意單位：100 Mbps 的理論傳輸上限約為 12.5 MB/s，實際速度還要扣除通訊協定的額外負擔。下載工具顯示 10 MB/s，不代表百兆寬頻只能跑出十分之一的速度。瀏覽器使用多連線或單連線下載，速度也可能差很多，應分開記錄。

二、第一層：確認節點品質與實際使用的策略

先在用戶端的「連線」頁面找到正在測試的網域，確認命中的規則、策略群組和最終節點。使用規則模式時，切換介面上的某個代理群組，不一定會影響目前的請求；巢狀策略群組也可能仍指向另一個自動選擇群組。既有連線通常不會因切換選項而立即重新建立，測試前請先停止下載並重新發出請求，必要時只關閉相關的舊連線。

挑三個節點交叉比較，不只看最低延遲

  • 相同地區的不同節點：協助判斷是否只有單一節點壅塞，盡量選擇不同入口或線路標示的節點。
  • 不同地區的節點：確認目標服務是否受到特定出口地區或電信業者互連路徑影響。
  • 同一節點在不同時段：白天與晚間各測一次；若只有晚間速度明顯下降，較可能是容量不足或互連壅塞，不應先修改本機 MTU。

例如，節點 A 測得 65ms、持續下載速度為 1.2 MB/s，節點 B 測得 145ms、持續下載速度為 8.0 MB/s。這組示例只能說明 B 較適合這次的大檔案傳輸，不能據此推論 B 對所有遊戲或網頁都比較好。請一併保存測試網址、時間和節點，避免直接比較不同條件下的數值。

更新訂閱是為了確認設定和節點資訊是否過期，不會直接增加線路容量。先確認訂閱仍在有效期限內、流量尚未用完，且服務端沒有限速提示，再手動更新一次。若更新失敗，請保留仍可運作的設定並查看錯誤訊息，不要反覆刪除訂閱再重新建立。

三、第二層：分別檢查入口網路、出口線路和目標網站

一次代理連線至少會經過裝置到節點入口、節點到目標網站兩段路徑。更換節點時同時改變了多項條件，因此「換了之後就變快」還不足以確認根本原因。最有效的補充測試是維持節點不變，將電腦網路從家用寬頻改為手機熱點，再重做相同的操作。

測試結果較可能的問題下一步
家用寬頻較慢，手機熱點明顯較快本地網路連線或通往節點入口的路徑改用有線網路重測，並比較不同入口線路
兩種網路都只有同一個節點較慢節點容量或其出口路徑改測同地區的其他節點，並記錄測試時段
其他網站正常，只有單一網站較慢目標網站限速、CDN 或出口互連以相同目標改測其他地區，並確認服務狀態
同一網路上的多台裝置都較慢公共網路環境或共用線路檢查路由器負載和上傳頻寬占用

測試封包遺失時要看終點，不要只看中間節點

Windows 可用下列指令觀察與某個公用 IP 的基本連線狀況。這個位址只是網路探測目標，不是建議寫入設定的 DNS，也不代表節點路徑。啟用 TUN 時，探測是否經過核心取決於路由和 ICMP 支援；若要建立直連基準，請先暫停 TUN，並確認系統路由已恢復。

ping -n 30 1.1.1.1
tracert -d 1.1.1.1

中間路由器可能會限制 ICMP 回覆；若某一跳逾時但終點正常，不能據此判定鏈路有封包遺失。終點沒有回覆也不一定代表網頁無法使用。若上傳頻寬已滿，下載確認封包和網頁請求就會排隊；可先暫停上傳工作再測一次。這類情況通常不需要修改代理通訊協定。

四、第三層：排除系統代理、TUN 與應用程式設定衝突

系統代理和 TUN 是兩種不同的流量接管方式。系統代理主要供遵循系統代理設定的應用程式使用；TUN 則透過虛擬網路介面接管符合路由條件的流量。兩者同時啟用不一定會衝突，但排查問題時只保留一種方式，更容易確認流量實際經過哪裡。

先只測試系統代理

  1. 結束其他 VPN 和代理工具，關閉目前用戶端的 TUN，保留系統代理。
  2. 在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」，確認手動 Proxy 或指令碼設定符合預期。macOS 請開啟「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「Proxy」，檢查是否還留有其他工具的位址。
  3. 確認用戶端實際使用的監聽連接埠。以下範例使用本機 HTTP 或 mixed 連接埠 7890；這是常見的範例值，不是所有用戶端固定使用的預設值。
  4. 使用明確指定代理的請求與瀏覽器結果交叉比對。Windows PowerShell 請使用 curl.exe，避免舊版環境中 curl 別名造成行為差異。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/

這個小測試頁面用來確認請求能否完成，以及等待首位元組的時間是否異常，無法測出最大下載頻寬。透過 HTTP 代理發出請求時，time_connect 主要反映與本機代理建立連線所需的時間，不能當成遠端節點延遲；time_starttransfer 則包含後續交涉和伺服器等待時間。macOS 或 Linux 可使用 curl，並將 NUL 改成 /dev/null。

接著單獨測試 TUN

關閉系統代理後啟用 TUN，維持相同節點和目標，重新建立連線。如果只有 TUN 模式較慢，請檢查用戶端服務權限、虛擬介面、路由，以及是否殘留其他 VPN；如果明確指定代理的請求很快、瀏覽器卻很慢，請優先檢查瀏覽器代理擴充功能、安全 DNS 和快取，不必急著重新購買節點。

遊戲、語音和部分影音連線可能會使用 UDP。HTTP 代理測試成功，只能證明相應的 TCP 請求可用，不能證明 UDP 路徑正常。請同時確認應用程式已由代理接管、節點通訊協定支援相應的轉發方式、伺服器允許 UDP，並在連線記錄中核對實際流量。不要把關閉所有 UDP 當成通用的加速方法。

五、DNS 與 MTU：出現相應症狀再調整

首次開啟緩慢，先檢查 DNS 解析路徑

如果網頁第一次開啟很慢，重新整理後就正常，請檢查記錄中是否反覆出現解析逾時，以及 DNS 上游是否連得上。使用 mihomo 的 fake-ip 模式時，回傳虛擬位址可能是正常情況，不要只因看到 198.18.0.0/16 範圍內的位址就判定 DNS 解析錯誤。瀏覽器安全 DNS、作業系統解析和核心 DNS 可能走不同路徑，需依實際的流量接管方式判斷。

  • 保留一套已確認可用的 DNS 設定作為基準，不要一次加入大量不熟悉的上游伺服器。
  • 檢查分流規則是否讓 DNS 上游產生循環依賴，尤其是必須先解析網域才能建立的代理連線。
  • 修改 DNS 或 fake-ip 設定後，請依用戶端要求重新載入，關閉舊連線再測試；Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取，但不會清除所有應用程式和核心快取。

只有大型封包卡住或 TUN 模式出現異常時，再檢查 MTU

MTU 是鏈路允許的最大傳輸單元。封裝額外負擔或路徑 MTU 探測受阻，可能導致小型請求成功，但大型檔案或部分 TLS 連線卡住。不過 1500、1480、1400 都不是適用於所有網路的固定答案；降低 MTU 也不會自動增加節點頻寬。

Windows 可在命令提示字元中測試 IPv4 的不可分割封包。乙太網路 MTU 為 1500 時，1472 位元組的 ICMP 資料加上通常為 28 位元組的 IPv4 與 ICMP 標頭，總計 1500 位元組。若測試失敗，可改用 1400 位元組的資料進行比較：

ping -4 -f -l 1472 -n 4 1.1.1.1
ping -4 -f -l 1400 -n 4 1.1.1.1
netsh interface ipv4 show subinterfaces

目標可能會封鎖 ICMP，因此這兩條 ping 不一定能涵蓋代理通道的實際路徑，結果只能作為線索。若確實遇到 TUN 相關的大型封包問題，先記下目前的 TUN MTU，再只於目前用戶端或 mihomo 的 TUN 設定中暫時改為 1400，重新啟動相關連線後測試；若沒有改善就還原設定。不要順手修改所有實體網卡，也不要將這組 IPv4 測試公式套用到 IPv6。

六、整理測試結果，避免反覆盲目調整

完成三層交叉測試後，通常已能將問題範圍縮小。提供給服務供應商或用戶端維護者的資訊，應包含可重現的步驟，而不只是「速度很慢」。以下清單足以整理出有效的測試記錄：

  • 執行環境：作業系統版本、用戶端版本、核心名稱與版本、是否啟用 TUN，以及實際監聽連接埠。
  • 測試條件：日期與時段、家用寬頻或手機熱點、目標服務、單連線或多連線。
  • 比較數據：同一節點三次持續測速的中位數、切換節點前後的結果、等待首位元組的時間。
  • 流量路徑：命中的規則、最終策略節點、失敗請求前後必要的記錄，並移除認證資訊。

如果目前使用的用戶端或核心長期未維護，請先備份訂閱和自訂規則，再選擇適用於作業系統且仍持續維護的用戶端。遷移後先用最精簡的設定完成連線，再逐項加回覆寫設定、規則和 TUN 設定，避免將舊環境的衝突一併帶過去。基本操作可參考Clash 設定教學；連線失敗和測速逾時也可查看延遲測試常見問題。