The system proxy is, at heart, a note posted in the OS: "please send traffic to 127.0.0.1:7890". Browsers and well-behaved apps comply. But a note is not enforcement - some programs simply ignore it.

The four offender classes

  1. CLI tools (curl, git, pip, go, …): never read the Windows proxy. Fix: env vars or per-tool proxy settings.
  2. UWP / Store apps: blocked from loopback by the OS. Fix: the UWP Loopback tool.
  3. Apps with their own network stack (some games, office suites, chat clients): they dial directly without consulting proxy settings. If the app has an in-app proxy option, set 127.0.0.1:7890 (SOCKS5 or HTTP); if not, TUN is the answer.
  4. System services and drivers (Windows Update, time sync, …): run in service context, ignoring user proxy settings. Also TUN territory.

The universal fix: TUN mode

TUN mode resolves every case above by taking traffic at the network layer - no cooperation required. After enabling, use the Connections page's Process column to confirm the app's traffic is arriving.

The inverse problem: keeping an app out of the proxy

Under TUN everything is captured; for the apps you want direct (cloud drives, domestic game clients):

rules:
  - PROCESS-NAME,clouddrive.exe,DIRECT
  - PROCESS-NAME,game.exe,DIRECT

See PROCESS-NAME Rules.

One more possibility: the app uses a different proxy

On machines with several proxy tools installed, an app may be configured for another port entirely. Check the app's own network settings, and watch whether the System Proxy switch keeps flipping - a telltale of another tool rewriting it.

The key diagnostic: no trace of an app on the Connections page = its traffic never reaches Clash (not a rule problem). Solve "getting in" before "routing correctly".