流量統計、連接數與速率排查：從連接頁找出問題根源

「網速慢」「流量莫名其妙用完了」「用戶端佔記憶體」——這三類問題的答案都在連接頁裡。

連接頁的六列

列	含義	排查價值
Host	目標網域或 IP	定位是訪問什麼
Rule	命中的規則	判斷分流是否正確
Chain	最終經過的策略鏈	確認走了哪個節點
Process	發起連接的行程	定位是誰在聯網
DL / UL	該連接的累計流量	找出流量大戶
Time	連接建立時長	識別長連接

Chain 列顯示的是完整鏈路，比如 🚀 节点选择 → ♻️ 自动选择 → HK-01，從左到右是策略組的嵌套順序，最右邊是實际出口。

場景一：流量被誰吃了

按 DL（下載） 列降序排序，看前十條。

Process 列會告訴你是哪個程式

找到之後有兩種處理：

讓它直連（推薦，不消耗方案流量）：

prepend-rules:
  - PROCESS-NAME,OneDrive.exe,DIRECT
  - PROCESS-NAME,SteamService.exe,DIRECT
  - DOMAIN-SUFFIX,windowsupdate.com,DIRECT

直接攔掉：

prepend-rules:
  - DOMAIN-SUFFIX,某遥测域名,REJECT

行程規則需要 find-process-mode: strict，見行程規則詳解。

場景二：連接數爆炸

正常瀏覽時連接數在幾十條。如果看到幾百上千條並持續增長：

立刻重新出現的那批，就是問題所在

常見原因：

現象	原因
同一個網域反複出現、每次都很快消失	連接失敗在重試。檢查那條規則指向的節點是否可用
大量連接指向同一個 IP 段	P2P 應用（BT、某些網盤的 P2P 加速）
連接數緩慢增長不下降	連接泄漏，或者是長連接應用（消息推送、WebSocket）
全是某個行程	那個程式有問題，或者它本來就是高並發的

場景三：速率上不去

先確定瓶頸在哪一層：

從外往內逐層排除，不要一上來就改設定

判斷是不是節點問題

同一個大檔案，分別用三個不同地區的節點下載，對比速率。

都慢 → 本地網路或用戶端設定問題
只有某個慢 → 那條線路的問題，換節點
白天快晚上慢 → 線路在晚高峰擁塞，這是廉價共享線路的典型特徵

判斷是不是用戶端瓶頸

看 CPU 佔用。如果下載時 Clash 行程 CPU 接近單核跑滿：

MTU 導致的怪現象

症狀：小檔案正常，大檔案下載到一半卡死。

這是 MTU 過大導致分片丟失。把 tun.mtu 從 1500 降到 1400 試試。

用 API 做持續監控

連接頁只能看當下。要持續觀察，用 API。

實時速率

/traffic 是 WebSocket 接口，每秒推送一次：

{"up": 12345, "down": 678901}

單位是字節/秒。

websocat "ws://127.0.0.1:9090/traffic?token=你的secret"

定時快照連接數

#!/bin/bash
# conn-watch.sh
API="http://127.0.0.1:9090"
SECRET="你的secret"

while true; do
  N=$(curl -s -H "Authorization: Bearer $SECRET" "$API/connections" | jq '.connections | length')
  MEM=$(curl -s -H "Authorization: Bearer $SECRET" "$API/connections" | jq '.memory // 0')
  echo "$(date '+%F %T') 连接数=$N"
  [ "$N" -gt 500 ] && echo "  ⚠ 连接数异常" 
  sleep 30
done

統計流量 Top 10

curl -s -H "Authorization: Bearer $SECRET" http://127.0.0.1:9090/connections \
  | jq -r '.connections
      | sort_by(-.download)
      | .[:10][]
      | "\(.download/1048576 | floor)MB\t\(.metadata.host // .metadata.destinationIP)\t\(.metadata.processPath // "-")"'

按策略組統計流量

curl -s -H "Authorization: Bearer $SECRET" http://127.0.0.1:9090/connections \
  | jq -r '.connections
      | group_by(.chains[-1])
      | map({node: .[0].chains[-1], mb: ([.[].download] | add / 1048576 | floor)})
      | sort_by(-.mb)[]
      | "\(.mb)MB\t\(.node)"'

能看出哪個節點承載了最多流量，判斷負載是否均衡。

記憶體佔用排查

Clash Verge 的記憶體主要花在三處：

對應的最佳化：

介面佔用大 → 開啟「自動進入輕量模式」，不看介面時釋放 WebView
規則集佔用大 → 精簡規則集，或換 mrs 格式
連接佔用大 → 定期清理連接，排查連接泄漏

一個容易被忽略的點：統計不等於計費

用戶端顯示的流量和服務商後台的用量經常對不上，原因：

以服務商後台的數字為准

小結

流量異常 → 按 DL 列排序，看 Process
連接數爆炸 → 清空後觀察哪些立刻重現
速率上不去 → 逐層排查：本地 → 節點 → 協議 → 用戶端 → CPU
記憶體偏高 → 開輕量模式 + 精簡規則集
持續監控用 API，/connections 和 /traffic 兩個接口就夠
流量數字以服務商後台為准，用戶端只是參考

相關：外部控制 API 指南、行程規則詳解。