What Is the System Proxy? How It Works and Its Limits
On this page
The system proxy is the switch you flip in Clash Verge Rev, FlClash or any similar client to make your browser start using the proxy. What it actually does is smaller than most people assume: it writes an address and a port into your operating system's network settings, and then it hopes applications read them. It is a declaration, not an enforcement mechanism.
That single fact explains almost every surprise people run into — why the browser works while a game does not, why curl ignores the proxy entirely, and why some traffic keeps escaping no matter how many nodes you switch between.
This article covers what the system proxy is, what your client changes on each platform, which traffic follows it, how to bring command-line tools along, and where the approach runs out of road.
What the system proxy actually is
Your client runs a local listener — typically a mixed HTTP/SOCKS port on 127.0.0.1 — and everything it does for you happens through that port. The system proxy setting is just the operating system's way of publishing that address so applications can find it. Turning the switch on means: "there is a proxy at this address; programs that care should use it."
Nothing forces compliance. An application asks the OS for the current proxy configuration, or it does not. If it does, its connections go to the local port, the core applies your routing rules, and the traffic leaves through the server you selected. If it does not ask, its packets go straight out of your network card as though no proxy existed. Nothing in the client can change that, because the client was never in the path.
What your client changes when you flip the switch
The mechanism differs by platform, though the effect is the same:
- Windows — the client updates the system-wide internet settings (the same values shown under Settings → Network & Internet → Proxy). Most Windows software reads them through the standard networking APIs.
- macOS — the proxy is set on the active network service, per interface. Wi-Fi and Ethernet are configured separately, which is why the setting can appear to "vanish" when you switch connections.
- Linux desktops — there is no single authority. The client typically writes the desktop environment's proxy settings, which GTK and Qt applications generally honor while others ignore, so results vary more than on the other two systems.
Note: the published port is the mixed port from your configuration — commonly 7890 or 7897 depending on client and version. Check the value in the settings rather than assuming it; a mismatch between what you set manually and what the core listens on is a classic cause of "the proxy does nothing".
What follows the system proxy — and what ignores it
Reliably follows it: mainstream browsers, most desktop applications with an update or sync feature, app stores, and anything built on the platform's standard HTTP stack. For everyday browsing this covers essentially everything you touch, which is why the system proxy remains the sensible default.
Commonly ignores it: games and launchers that open raw sockets, peer-to-peer clients, applications that bundle their own networking stack, and a long tail of command-line tools. None of these are misbehaving — reading the system proxy is a convention, not a requirement. Traffic that ignores it simply takes the direct route, which for local services is exactly what you want.
Making terminal tools use the proxy
Command-line programs generally look at environment variables instead of OS settings. Set them in the shell where you need them:
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
curl -I https://www.example.comUse your own mixed port in place of 7890. The variables apply only to that shell session and any process it starts; a new terminal window starts clean. To turn them off again:
unset http_proxy https_proxy all_proxyOn Windows the same idea works in PowerShell with $env:HTTP_PROXY="http://127.0.0.1:7890". A few tools ignore the variables and keep proxy settings of their own — git, npm, pip and Docker among them — which is usually why one of them refuses to cooperate.
PAC mode in brief
Instead of a fixed address, some clients can publish a PAC file: a small script the operating system evaluates per request to decide whether it goes direct or through the proxy. It moves part of the routing decision out of the core and into the application layer.
That occasionally helps — keeping specific domains off the proxy can fix compatibility problems with local or corporate services. But support quality varies between applications, debugging is harder because the decision happens outside the core, and the core's own rule engine is more expressive anyway. Without a specific reason, plain system proxy mode is easier to reason about.
Where the system proxy stops being enough
You have outgrown it when you keep discovering applications that route around it: a game that will not connect, a CLI tool you cannot configure, a background service with no proxy option at all. Setting environment variables one program at a time works, but it is maintenance you inherit forever.
That is precisely the gap TUN mode fills. Instead of asking applications to cooperate, it creates a virtual network adapter and takes traffic at the IP layer, where opting out is not an option. It costs elevated privileges and a slightly longer list of things that can go wrong — the trade-offs are laid out side by side in TUN mode versus system proxy. And if the proxy is on but pages still refuse to load, work through the connection troubleshooting guide before changing modes: an unread system proxy is only one of several possible causes.