流量统计、连接数与速率排查：从连接页找出问题根源

「网速慢」「流量莫名其妙用完了」「客户端占内存」——这三类问题的答案都在连接页里。

连接页的六列

列	含义	排查价值
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 指南、进程规则详解。