先分辨延遲高、下載慢,還是網頁首次載入慢
Clash 用戶端顯示的延遲,通常是核心透過指定代理連線至測試網址所得的探測結果,不代表持續下載頻寬。測試網址、逾時設定和用戶端實作方式都會影響數值。延遲顯示 80 毫秒的節點,仍可能因出口限速而下載速度很慢;延遲 220 毫秒的遠距節點,也可能有更高的持續傳輸速率。
排查前先把「慢」描述成可觀察的現象。記錄作業系統、用戶端名稱、核心版本、目前設定、代理模式、實際選用的節點,以及問題發生時的網路環境。用戶端版本與核心版本是不同項目,請分別從版本資訊或啟動記錄中確認,不要只寫「最新版」。
| 現象 | 優先記錄 | 優先檢查 |
|---|---|---|
| 網頁第一次開啟很慢,重新整理後變快 | 網域解析、建立連線、首位元組時間 | DNS、連線重用與目標網站 |
| 大型檔案持續下載速度慢 | 連續 30 秒的平均速度 | 節點容量、線路與本機頻寬 |
| 影片偶爾緩衝 | 緩衝時段、實際媒體網域、策略鏈 | 出口至媒體 CDN 的路徑 |
| 只有一個應用程式很慢 | 用戶端是否顯示該應用程式的連線 | 代理涵蓋範圍與規則比對結果 |
固定測試條件,避免一次更動多個變數
先暫停背景大型檔案下載、雲端硬碟同步和其他測速工作。使用 Wi-Fi 時盡量固定在同一位置;條件允許的話,再用有線網路測一次。也要記錄路由器是否啟用了其他 VPN、透明代理或分流服務,避免把兩層代理的結果誤當成單層連線。
- 測試本機基準:關閉用戶端的系統代理與 TUN,確認瀏覽器沒有另外設定代理,再連線至可從本機網路直接存取的測速服務,記錄下載、上傳速度與延遲。這一步用來確認網路接取頻寬,不代表代理出口的效能。
- 固定測試目標:選擇一個允許測試的 HTTPS 下載資源,所有節點都使用相同 URL、下載方式與並行數。不要讓不同測速伺服器成為額外變數。
- 固定出口節點:將實際命中的策略組切換為手動選取的單一節點,避免自動選擇或故障切換在測試期間更換出口。
- 重複測試三輪:每輪約 30 秒,輪次間隔約 15 秒,記錄中位數並註明測試時段。大量傳輸會消耗訂閱流量,可視需要縮短測試時間。
切換節點後,請停止原本的下載並重新建立連線。既有 TCP 連線通常不會因策略組切換而自動轉移至其他出口。需要清除連線時,優先只關閉測試應用程式的連線,避免中斷其他進行中的工作。
例如,記錄表可以寫成「節點 A:2.1、2.4、2.2 MB/s,中位數 2.2 MB/s」。這只是記錄格式範例,並非本站實測結果。比較時也要記錄失敗次數;三次測試有兩次逾時,比單次速度峰值更能反映可用性。
節點品質:比較單一節點的傳輸速度與目標網站表現
節點品質涉及入口可連線性、伺服器負載、限速策略,以及出口至目標網站的連線狀況。若用戶端的「一鍵測速」只測量延遲,就不能據此判斷節點頻寬。先從同一份訂閱中挑選兩到三個候選節點,逐一使用固定目標測試,再觀察實際使用情境。
查看連線記錄,確認測試流量確實經過目標節點
- 開啟用戶端的「連線」頁面,開始新的下載請求。
- 依目標網域或處理程序篩選,查看命中的規則與完整策略鏈。
- 確認最終出口是剛才選取的節點,而不是
DIRECT或其他獨立策略組。 - 若使用
proxy-providers,請檢查該代理集合的更新與健康檢查狀態;這和更新整份設定檔是兩回事。
如果節點 A 對多個目標都很慢,而節點 B 在相同時段明顯較快,應優先考慮 A 的負載、頻寬限制或路徑問題。如果同一節點只有某個網站很慢,其他下載正常,較可能是出口至該網站的路由或 CDN 分配差異,不宜直接判定整個節點失效。
線路壅塞:交叉比對時段與網路環境
節點名稱中的地區通常表示出口位置,無法完整說明從本機到入口、再到出口的路徑。不同地區的兩個節點也可能共用入口或中轉線路,因此「換了地區還是很慢」並不能排除線路問題。
建立兩種比較條件
- 同一網路,不同時段:例如分別在 10:00 和 21:00 測試同一節點與目標。連續多天晚上都明顯變慢,比偶爾一次速度下降更能支持尖峰時段壅塞的判斷。
- 同一時段,不同網路:在幾分鐘內比較家用寬頻與手機熱點。保持用戶端、節點和目標不變,也要留意熱點的訊號強度與資費限制。
- 同一網路,不同入口線路:若服務提供者有明確的線路說明,可比較不同入口的節點;不要只憑名稱推測線路是否獨立。
如果使用家用寬頻時多個節點都很慢,改用手機熱點後恢復正常,問題較可能出在家用網路、電信業者互連或本機路由器。若同一節點在兩種網路下都很慢、其他節點正常,則應優先檢查該節點及其出口。以上都是定位線索,不能只憑一次測試就下定論。
也可以觀察路由器是否在大量上傳時出現延遲暴增。上傳頻寬用滿造成的排隊延遲,會影響網頁與互動請求;暫停上傳後恢復正常,表示應先檢查頻寬占用與路由器佇列管理。中間路由器不回應探測封包很常見,不能只根據單一跳點的封包遺失比例,就認定實際連線也有封包遺失。
規則與 DNS:確認慢速請求的實際路徑
診斷時優先使用規則模式,並確認實際命中的規則。Clash 與 mihomo 的規則通常依序比對,前面的規則可能先於後面的網域規則生效。最後的 MATCH 負責兜底;將目標網域加在它後面,通常不會達到預期效果。
短暫改用全域模式對照,不要長期依賴
了解目前設定後,可以短暫切換至全域模式,並明確選取全域策略使用的節點。如果同一節點在全域模式正常、規則模式異常,應優先檢查規則模式是否選到不同策略組、直連出口或鏈式路徑。測試完成後請恢復原本模式;全域模式可能會改變原本應直連的流量路徑。
分辨 DNS 等待與內容傳輸緩慢
- 只有第一次瀏覽很慢,後續請求變快:檢查 DNS 解析時間、快取與連線重用,不要立刻修改所有 DNS 欄位。
- 網域請求失敗,但其他網站正常:查看記錄中是否有解析逾時,並確認上游 DNS 是否可連線。
- 瀏覽器與其他應用程式的表現不同:檢查瀏覽器的安全 DNS 設定,它可能不會遵循系統的解析路徑。
- 啟用 Fake-IP 後出現
198.18.0.0/16範圍內的位址:這可能是正常的虛擬對應,不應只憑該位址就認定 DNS 故障;實際網段請以設定為準。
在 mihomo 中,dns.nameserver、dns.proxy-server-nameserver 與 dns.nameserver-policy 分別涉及一般解析、代理伺服器網域解析及依網域選擇解析器,實際行為也取決於完整設定。不要直接將網路上的 DNS 設定片段套用到現有訂閱。修改前請先備份,每次只調整一項,重新載入後再建立測試連線。欄位說明請參閱完整手冊的 DNS 章節。
系統代理與 TUN:檢查應用程式涵蓋範圍與本機負載
系統代理主要供遵循系統代理設定的應用程式使用;TUN 透過虛擬網卡和路由接管更多 IP 流量,但實際涵蓋範圍仍會受到路由排除設定、應用程式綁定的介面及用戶端實作影響。TUN 不是加速開關,也無法突破節點限速。
先用明確指定代理的方式隔離問題
以下命令假設本機 HTTP 或混合代理監聽於 127.0.0.1:7890。請先在用戶端的連接埠設定中確認實際值;7890 並非所有用戶端的固定連接埠。Windows 可使用 curl.exe,避免部分 PowerShell 環境中的同名別名影響參數。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 \
--output /dev/null --silent --show-error \
--write-out "connect=%{time_connect}\nTLS=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
https://www.example.com/
這是適用於 macOS、Linux 等環境的簡短請求診斷命令,並非頻寬測試。Windows 使用時,請將 curl 改為 curl.exe、輸出目標改為 NUL,並將命令合併為一行。計時單位為秒,各項數值都是從請求開始累計的時間;使用本機 HTTP 代理時,time_connect 主要反映連至本機代理監聽連接埠的時間,不代表連至遠端節點的延遲。
如果明確指定代理的請求正常,但一般應用程式仍很慢,請確認應用程式是否遵循系統代理、是否安裝獨立的代理擴充功能,以及系統代理是否指向目前用戶端的連接埠。如果請求顯示連線遭拒,先確認核心是否正在執行、監聽位址是否正確,以及連接埠是否被占用,不要先更換 DNS。
分別測試兩種流量接管方式
- 先儲存目前設定,關閉 TUN,只啟用系統代理,並使用同一個瀏覽器和目標進行測試。
- 接著關閉系統代理,只啟用 TUN,確認測試請求出現在連線記錄中,再重複測試。
- 查看工作管理員或活動監視器中的核心 CPU 使用率,同時確認是否有其他 VPN 或虛擬網卡正在修改路由。
- 如果只有啟用 TUN 時發生卡頓,請檢查用戶端記錄、路由衝突和目前網路的相容性,再依用戶端支援範圍比較通訊協定堆疊設定。
只有在 CPU 單核心持續接近滿載且傳輸速度受限時,才可將其視為本機處理瓶頸的線索之一。不要同時修改 TUN 通訊協定堆疊、MTU 和 DNS;尤其是 MTU,應在有大型封包傳輸卡住等證據時進行對照測試,而不是把某個數值當成通用解法。
整理排查結果,找出可重現的問題
每次只修改一項,並保存修改前後的結果。以下對照有助於判斷下一步,但仍須搭配記錄與重複測試:
| 重複出現的結果 | 下一步處理方式 |
|---|---|
| 只有單一節點很慢,其他節點正常 | 保留相同目標的測試記錄,檢查該節點的負載、限速與出口路徑 |
| 所有節點都很慢,直連基準也很慢 | 先檢查本機頻寬、Wi-Fi 訊號、上傳占用與路由器負載 |
| 晚上很慢,白天正常 | 持續記錄不同時段的差異,並比較獨立入口線路 |
| 規則模式很慢,全域模式正常 | 確認命中規則、策略組選擇與最終出口是否一致 |
| 系統代理正常,TUN 異常 | 檢查路由衝突、接管範圍、通訊協定堆疊與資源占用 |
向用戶端維護者或訂閱服務提供者回報時,請提供作業系統版本、用戶端與核心版本、問題時段、網路環境、重現步驟及已去識別化的記錄。請刪除訂閱 URL、權杖、驗證資訊及不必要的存取網域。只有在發現核心相容性問題或明確修正紀錄時,才將升級用戶端或核心列為下一步,並保留可還原的原始設定。
完整排查順序:先測試本機基準,再固定節點比較傳輸速度,接著交叉驗證線路,最後檢查規則、DNS 與流量接管方式。若要繼續處理訂閱失敗或延遲異常,請參閱疑難排解中的延遲排查;若尚未確認匯入與啟用方式,請先依照訂閱匯入教學檢查基本設定。