Browser works but apps bypass the proxy

The system proxy is a suggestion, not an order

When you flip the system proxy switch, the client does exactly one thing: it writes 127.0.0.1 and a port number into the operating system's proxy settings. Which programs bother to read that setting is not up to the OS, and it cannot force the issue. Programs that read it go through the proxy; programs that do not connect straight out. That is the whole reason your browser is fine while one specific app refuses to work.

• Chrome and Edge follow the system setting with no extra configuration.
• Firefox follows it by default, but it keeps its own proxy page. Once someone has switched that to manual configuration or to no proxy, it stops following.
• Command-line tools ignore the system proxy entirely. curl, git, npm, pip, apt and their relatives read environment variables instead.
• Some Electron apps and most game clients connect directly by design, or carry their own proxy field that has nothing to do with the system one.
• Windows Store apps (UWP) run inside a container with its own network isolation rules, which is a separate situation again.

First decide: not proxied, or proxied and failing?

1. Open the client's connections page, labelled Connections in most builds.
2. Clear the existing list, then go use the app and make it fire a request.
3. Not a single new row appears: the app is not using the proxy at all, so the next two sections are for you.
4. Rows appear but keep failing, or stall at a few hundred bytes: it is using the proxy and your problem is the node or the rules. Different investigation entirely, so do not spend time on proxy configuration.

If the app has its own proxy field, just fill it in

Easiest layer, most often skipped. Dig through the app's settings; a proxy field hides under Network or Connection more often than you would expect. Enter 127.0.0.1 and your mixed port. Note whether it asks for an HTTP proxy or SOCKS5: mixed-port accepts both, so either works, but on an older config that splits port and socks-port you have to match the right one.

Command-line tools only read environment variables

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1,192.168.0.0/16

Both lowercase and uppercase spellings are in active use by different programs, so the careful move is to set each name twice. no_proxy keeps local and LAN addresses out of the proxy; leave it out and requests to your own machine take a detour. These lines apply to the current shell session only and vanish when you close the terminal — to make them stick, put them in .bashrc, .zshrc or whatever your shell reads at startup. On Windows, PowerShell uses the $env:HTTP_PROXY form, CMD uses set, and setx writes it permanently. One more thing: git, npm and pip each keep their own proxy settings, so if the environment variables appear to be ignored, check those config files.

When neither works, TUN is what is left

Some programs have no proxy field and no interest in environment variables; they open a socket and go. Reasoning with them is not an option. TUN takes over one layer down: it creates a virtual adapter and rewrites routing so outbound traffic is captured regardless of what any program believes about proxies. It is the only universal fallback, and it costs you elevated privileges plus a whole category of its own problems. UDP is the same story — games and voice calls run over UDP, which the system proxy never touched. The reverse need exists as well: internal tools, download managers and corporate software that you would rather keep off the proxy. One rule matched on process name handles that.

rules:
  - PROCESS-NAME,aria2c.exe,DIRECT
  - PROCESS-NAME,ssh,DIRECT
  - MATCH,PROXY