Work out which process it is
Task Manager shows the client interface and the core as two separate processes. High usage on the interface almost always means an open window rendering the live connections list. High usage on the core is a traffic-handling issue and is the one worth investigating.
The first step is simple: close the main window, leave it in the tray, and watch for ten minutes. If usage drops, nothing is wrong. An idle core should sit very low; only sustained use of a full core justifies digging further.
Four checks, in order
- 1
Log level
With debug or trace enabled, every connection is written out and usage climbs noticeably. Set it back to info or warning when you are done troubleshooting. This is the item people forget most often.
- 2
Sniffing
Sniffing parses the handshake of each connection to recover the domain. It is genuinely useful when your rules lean on domain matching, but it is not free. Turn it off if you do not need it, or restrict it to ports 443 and 80.
- 3
Rule provider intervals
Many remote rule providers on a short interval means repeatedly downloading and recompiling rule sets. Once a day is enough for almost every setup.
- 4
Connection count
Download managers and peer-to-peer clients open thousands of sockets. Sort the connections page by start time and look for one process cycling connections continuously.
Is memory that does not drop a problem?
Core memory grows with connection count and is not returned to the system immediately when connections close. That is ordinary Go runtime behaviour and not a fault. The test is whether memory levels off within a few minutes after the connection count falls. Only a steady linear climb is abnormal; if you see that, note the config and core version and compare against the previous core release.
- Change one thing, then watch for ten minutes before changing the next
- Strict route in TUN can be expensive on some adapters; try it off as a comparison
- For machines left running, disable automatic latency tests or lengthen the interval
Common questions
Usage is fine as soon as I close the window. Is that a bug?
No. The connections page receives a continuous stream from the core and rendering it costs something. Running from the tray is the intended behaviour.
The same config is fine on another machine. Why?
Suspect the network adapter driver and security software first. Deep inspection of a virtual adapter shows up as overhead attributed to the core process, which makes it look like the core is at fault.