Clash performance and battery checklist

A client that is only shuttling your browsing around should be close to invisible. When it is not, there is usually one specific cause rather than a general need for optimisation. So before you change a single setting, measure. Tuning without a baseline is not tuning, it is rearranging furniture in the config file.

Measure once, then decide whether to touch anything

• Windows: Task Manager, Details tab. Look for the core process — usually mihomo, sometimes named after the client, sometimes both, because the interface and the core are separate processes. Watch CPU and memory.
• macOS: Activity Monitor, and besides CPU check the Energy tab. The energy impact column is closer to what the battery actually feels.
• Linux: top or htop filtered on the core process name; if you run it as a service, systemctl status also reports memory for that unit.

What counts as normal: with no traffic passing through, CPU should sit near zero and twitch occasionally. Memory scales with node count and open connections, and anything from a few dozen to a few hundred megabytes is unremarkable. The thing worth watching is the trend — leave the machine idle for an hour and if memory is still climbing, that is a finding. One large number in a screenshot is not.

What actually burns resources, in order

1. Automatic latency testing. First place by a wide margin. A url-test group with interval set to 60 and forty members is forty complete HTTP requests every minute, each with a connection setup and a handshake. Move it to somewhere between 300 and 600 and you will not notice a difference in daily use.
2. Node count. A thousand-entry subscription makes list rendering, health checks and connection-page matching all work at that scale, while you realistically use a dozen. Use filter on the provider or the policy group to keep the rest out of the picture.
3. Log level. Running at debug long term costs CPU, writes to disk continuously and grows the log file. Keep it at info or quieter for daily use and raise it only while you are chasing something.
4. TUN mode. It adds a packet-handling layer on top of what a system proxy does. On a desktop the difference vanishes into the noise; on a phone you can feel it. Dropping back to system proxy to save power only pays off if you did not need everything captured in the first place.
5. Connection buildup. A connections list left uncleared for days holds memory, and drawing a few thousand rows is not free either. Clear it periodically, and do not leave that page as your default view.

proxy-providers:
  my-sub:
    type: http
    interval: 86400
    health-check:
      enable: true
      interval: 600
      lazy: true
proxy-groups:
  - name: Auto
    type: url-test
    interval: 600
    lazy: true

There is a trap in that snippet worth naming: interval appears twice. The policy group has one and the provider health check has its own. Double the group interval while the provider quietly keeps testing on its own short schedule and you have saved nothing. Check both places. lazy is the forgotten half — with it on, a group nothing is currently routed through does not get tested at all, which silences every regional group you keep around but rarely select. The arithmetic is easy: forty nodes at a 60-second interval is 2,400 test requests an hour; at 600 seconds it is 240.

Phones: battery is a separate ledger

Accept one thing first. An app that forwards your traffic has to stay alive in the background, and that part cannot be optimised away. Wanting it to route without running is not a configuration problem. What you can reduce is how much work it does while it sits there.

• Automatic testing. On a phone this is the single largest item. Switch it off entirely, or push the interval past ten minutes. You do not change nodes anywhere near that often.
• Subscription auto-update. Once a day is plenty; some clients arrive set to hourly.
• Per-app proxying — the name differs by vendor, and what each platform can do differs too. Route only the apps that need it and let the rest go direct, so their traffic never passes through the process at all. This is the most honest saving on the list.
• IPv6. If your network does not use it, switching off the related resolution removes an extra lookup per domain and a batch of connection attempts that were never going anywhere.

One decision people make without reading it properly: adding the client to the battery optimisation exemption list. That setting exists so the system stops killing the app, and the price is exactly that the app gets more freedom to work in the background. It is the opposite of a power saving. You are buying connection stability with battery, which is often the right trade — just know that is the trade.

To learn what it actually costs you, open the system battery usage screen and sort by app. People are certain the proxy client is draining the phone, then look and find the screen in first place and the client somewhere around seventh. Optimising on a hunch mostly optimises your mood.

Desktop: things that will not help

Launch at login, service mode, and assorted switches with performance in their name improve convenience or solve a permissions problem. Not one of them lowers resource use. Installing the helper service does not bring CPU down; it just means TUN stops asking for administrator rights every time. If you want the machine to run cooler, everything that works is on the list above.