Troubleshooting
When a Mac app ignores the system proxy setting
macOS 13+ · Apple Silicon and Intel · Updated 2026-08-30
The symptom
The system proxy is on. Safari goes through it, and a quick check in the browser confirms the exit address changed. Then one specific app behaves as though nothing happened: it reaches sites it should not be able to reach, or it fails to reach anything at all, or it reports your real location while every browser reports the proxy's.
Why it happens
macOS publishes the proxy configuration and applications choose whether to read it. Nothing enforces compliance. An application ends up ignoring the setting for one of a small number of reasons:
- It ships its own network stack. Many Electron, Go, Rust and Java programs bundle a client that has no idea macOS has an opinion about proxies.
- It has its own proxy setting, and that setting says Direct. Firefox is the well-known example; several Electron apps behave the same way.
- It was launched outside a shell, so any proxy environment variables you exported are invisible to it.
- It uses UDP. The macOS SOCKS setting is TCP only, so UDP traffic is not covered even by apps that do respect the setting.
- It resolves DNS on its own, sometimes over DNS-over-HTTPS to a fixed server, which sidesteps whatever your system is configured to do.
Proving it, rather than guessing
Before changing anything, confirm which process is actually connecting directly. This lists the open network connections for one application by name:
# replace Slack with the process you suspect lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i slack # and what your proxy's exit address looks like, for comparison curl -s --socks5-hostname 127.0.0.1:7890 https://api.ipify.org; echo
If the app's connections go straight to external addresses while the proxy is enabled, it is ignoring the setting. This is also where a per-app routing tool saves time: instead of running lsof per suspect, the Activity view shows every process, the path each connection took, and the rule that decided it.
Workarounds that only half work
| Approach | Why it falls short |
|---|---|
| Set the proxy inside the app | Only works for apps that have such a setting — the ones causing trouble usually do not |
| Export proxy environment variables | Invisible to anything launched from Finder, the Dock or Spotlight |
| Block the app in a firewall until it complies | It does not comply; it just fails, and you lose the app instead of routing it |
| Route the whole Mac through a transparent tunnel | Catches the app, and also the VPN, the LAN, localhost and everything else you did not want routed |
The fix: take the choice away from the app
The reliable answer is to move the decision below the application, to the point where a connection is created and the operating system still knows which process created it. At that layer, cooperation is not required — the app is never consulted, so "ignoring the setting" is not an option available to it.
- Add the upstream you want that app to use.
- Add a rule naming the application, picked from a list by its icon rather than a typed process name.
- If it needs UDP, use an upstream that supports SOCKS5 UDP, and set QUIC to proxy; if your upstream is TCP-only, set QUIC to fall back to TCP instead.
- Keep localhost and your LAN ranges Direct so the app can still reach local services.
- Watch it in Activity for a minute and confirm every connection now takes the path you expect.
The same mechanism solves the inverse problem. If an app insists on using the system proxy and you would rather it did not — a backup client, a large download, a latency-sensitive game — give it a Direct rule and it stays off the proxy regardless of what the system setting says.
FAQ
Is the app broken, or am I doing something wrong?
Neither. The macOS proxy setting is published by the system, not enforced by it. An app that connects directly is making a legitimate choice — usually because it ships its own network stack. There is no setting you missed.
How can I tell which apps are ignoring it?
By watching connections per process rather than trusting the setting. Anything that shows a direct connection to an external address while the system proxy is on is ignoring it. A per-app routing tool lists this continuously; without one, lsof and a packet capture will tell you the same thing with more work.
Will forcing the app through a proxy break it?
Rarely, but check two things: an app that needs UDP requires an upstream that supports SOCKS5 UDP, and an app that talks to your LAN or localhost needs those destinations kept on Direct. Both are one rule each.
What about apps that hardcode their own DNS?
They are handled the same way. When routing happens below the application, its DNS queries are subject to the same rules as its other traffic — the app does not get to opt out, because it is never asked.
ProxyRouter comes with a free full-feature trial, no card required. You bring your own SOCKS5 or HTTP upstream — a corporate proxy, a staging gateway, or a port on localhost. We do not provide or resell proxy servers.