The Clash core itself is very light; most "slow" and "laggy" reports have other causes. Work through this checklist - the wins are usually immediate.

Network experience

  • Use the right node: physical proximity and low load beat everything. Let a url-test group choose, with tolerance: 50 against flip-flopping.
  • Enable fake-ip: removes the local DNS round trip; first-byte times drop noticeably. See the DNS guide.
  • UDP support: voice and games ride UDP. Make sure nodes carry udp: true and the provider supports it, or calls fall back to TCP or fail.
  • Front-load hot rules: frequently hit rules near the top reduce per-connection matching (noticeable with ten-thousand-line rule sets).

Resource usage

  • Trim rule sets: each RULE-SET stays resident in memory; loading a dozen large sets costs hundreds of MB. Keep only what you use.
  • Log level: info or warning for daily use; debug only while diagnosing.
  • Leave busy pages: the live-updating Connections view has real rendering cost; park the UI on General when idle.
  • Benchmark frequency: keep url-test interval at 300 s or more - constant health checks are themselves traffic and CPU.

TUN specifics

  • stack: system gives higher throughput, gvisor better compatibility. Try system for heavy downloads; return to gvisor on any weirdness.
  • Avoid running other VPNs or virtual adapters alongside TUN - routing-table fights degrade speed unpredictably.

Healthy baselines

Expect roughly: core memory 50-150 MB (rule sets dependent), UI process 150-300 MB (normal for Electron), near-0% CPU when idle. Significant excess deserves the dedicated guide: High CPU or Memory Usage.

Tip: 90% of speed ceilings are node bandwidth, not local settings. Before tuning, benchmark the same node from another device or client to locate the bottleneck.