Traffic, connection counts and throughput — finding the root cause on the connections page

"It is slow", "my data allowance vanished" and "the client is using a lot of memory" — the answers to all three live on the connections page.

The six columns

Column	Meaning	Diagnostic value
Host	Destination domain or IP	Identifies what is being reached
Rule	The rule that matched	Tells you whether routing is correct
Chain	The policy chain finally used	Confirms which node it took
Process	The program that opened it	Identifies who is on the network
DL / UL	Cumulative traffic on this connection	Finds the heavy users
Time	How long the connection has been open	Spots long-lived connections

The Chain column shows the full path, such as 🚀 Select → ♻️ Auto → HK-01, reading left to right through the nesting of policy groups, with the actual exit on the right.

Case 1: what is eating my data

Sort descending by the DL column and look at the top ten.

The Process column tells you which program it is

Two ways to handle it once found:

Send it direct (recommended, so it does not consume your plan):

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

Block it outright:

prepend-rules:
  - DOMAIN-SUFFIX,some-telemetry-domain,REJECT

Process rules need find-process-mode: strict; see process rules explained.

Case 2: the connection count explodes

Ordinary browsing sits in the tens. If you see hundreds or thousands and climbing:

The ones that reappear immediately are your problem

Common causes:

What you see	Cause
The same domain appearing repeatedly and vanishing quickly	Failed connections retrying. Check whether the node that rule points at is usable
Many connections to the same IP range	A P2P application (BitTorrent, or a cloud drive's P2P acceleration)
A count that climbs slowly and never falls	A connection leak, or a long-lived-connection application (push messaging, WebSocket)
All from one process	That program has a problem, or it is simply highly concurrent by design

Case 3: throughput will not go up

First work out which layer the bottleneck is in:

Work from the outside in; do not start by changing the configuration

Is it the node?

Download the same large file through three nodes in different regions and compare.

All slow → local network or client configuration
Only one slow → that line's problem, change node
Fast by day, slow at night → the line congests at peak hours, the hallmark of a cheap shared line

Is the client the bottleneck?

Look at CPU use. If the Clash process approaches a saturated core while downloading:

The strange symptom MTU causes

Small files fine, large downloads stalling halfway.

That is fragment loss from an oversized MTU. Try lowering tun.mtu from 1500 to 1400.

Continuous monitoring through the API

The connections page only shows the present moment. For ongoing observation, use the API.

Live throughput

/traffic is a WebSocket endpoint pushing once a second:

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

Units are bytes per second.

websocat "ws://127.0.0.1:9090/traffic?token=your-secret"

Periodic connection-count snapshots

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

while true; do
  N=$(curl -s -H "Authorization: Bearer $SECRET" "$API/connections" | jq '.connections | length')
  echo "$(date '+%F %T') connections=$N"
  [ "$N" -gt 500 ] && echo "  ⚠ connection count looks abnormal"
  sleep 30
done

Top 10 by traffic

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 // "-")"'

Traffic per policy group

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)"'

This shows which node is carrying the most traffic, and whether the load is balanced.

Investigating memory use

Clash Verge's memory goes into three places:

Corresponding fixes:

Interface is the largest → enable "auto enter lite mode" to release the WebView when you are not looking at it
Rule sets are the largest → trim them, or move to the mrs format
Connections are the largest → clear connections periodically and look for leaks

An easily missed point: statistics are not billing

The traffic your client shows and the usage in your provider's dashboard often disagree, because:

Take the provider's dashboard figure as authoritative

In short

Unexpected traffic → sort by DL and read the Process column
Exploding connection count → clear the list and watch what returns immediately
Throughput will not rise → work through the layers: local → node → protocol → client → CPU
High memory → lite mode plus trimmed rule sets
Monitor continuously through the API; /connections and /traffic are all you need
Trust the provider's traffic figures; the client's are a reference only

Related docs

DNS & Networking Clash DNS configuration — fake-ip or redir-host?

How fake-ip actually works, how it differs from redir-host, the division of labour between nameserver and fallback, how to prevent DNS leaks, and why internal hostnames stop resolving.

2026-07-131433 words3 min read

DNS & Networking TUN internals — how the virtual adapter, routing table and DNS hijacking work together

What TUN mode does, from the packet's point of view: creating a virtual adapter, rewriting the routing table, hijacking port 53, and choosing between the gvisor, system and mixed stacks.

2026-06-261408 words3 min read

DNS & Networking Why games get worse through a proxy — UDP, NAT type and latency tuning

What makes game traffic different: why UDP needs TUN, what NAT type actually means, why packet loss hurts more than latency, and a configuration checklist aimed at low latency.

2026-06-181440 words3 min read