How-to
How to stop a single Mac app from reaching the internet
macOS 13+ · Apple Silicon and Intel · Updated 2026-08-30
Why you would want this
The reasons are boring and extremely common. An app you otherwise like keeps talking to servers you did not ask it to talk to, and there is no setting to turn that off:
- Telemetry and crash reporting you cannot opt out of.
- An updater that re-downloads and re-prompts every time you launch the app, when you deliberately want to stay on this version.
- A tool that works perfectly offline but insists on a network round trip at startup.
- Software you need for one file but do not particularly trust.
- An app that quietly uploads documents for "sync" you never enabled.
What you want is narrow: this one app, no network, everything else untouched. That turns out to be surprisingly hard to express on macOS.
Why the obvious answers don't work
The built-in firewall only blocks incoming connections
This is the single most common misunderstanding, and it costs people a lot of time. The firewall under System Settings decides whether other machines may connect to yours. It says nothing about traffic your Mac initiates. You can turn it on, set it to block all incoming connections, and the app you are trying to silence will keep phoning out exactly as before.
The other usual suggestions
| Approach | Why it falls short |
|---|---|
| Turn off Wi-Fi while using the app | Takes the whole Mac offline, including everything you were in the middle of |
| Add the domain to /etc/hosts | Matches names, not applications — it blocks that host for every app, and an app with a hard-coded IP walks straight past it |
| Write a pf firewall rule | pf filters by address, port and interface. It has no notion of which process opened a connection |
| Delete the app's network entitlement | Not a thing on macOS, and editing a signed bundle breaks its signature |
| Use an outbound firewall (Little Snitch, LuLu) | Genuinely works, and is the right tool if auditing every connection is your goal — but it is a second network extension and a stream of prompts |
The fix: a block rule for that one app
ProxyRouter decides what happens to a connection at the moment it is created, based on which process created it. Block is one of the three actions a rule can take — the other two being direct and through a chosen upstream — so silencing an app is the same operation as routing it, with a different verdict.
- Install ProxyRouter and approve the system extension once when macOS asks.
- Leave the default action as Direct, so nothing else on the Mac changes.
- Add a rule, pick the application from the list by its icon, and set its action to Block.
- Launch the app and watch Activity: its attempts appear labelled as blocked instead of disappearing silently.
Unblocking is the same rule with a different action, so this is fully reversible at any moment. Nothing about the application is modified.
The useful part: you still see what it tried to reach
A block that silently discards traffic tells you nothing. Here the attempts are still recorded — process, destination, port, and the rule that stopped them — and counted in the Activity view. That turns blocking into an investigation: leave an app blocked for a day and you have a precise list of the endpoints it wanted, which is often more informative than any privacy policy.
What Block covers
A block rule applies to the application's TCP traffic and to QUIC, which is what HTTP/3 runs on. In practice that is everything an app does over the web: HTTPS requests, API calls, update checks, telemetry, crash reports and uploads all stop at the rule.
Because the decision is made by process rather than by address, an app cannot get around it by hard-coding an IP, rotating domains or bringing its own resolver — it is never asked, so there is nothing for it to work around.
Variations worth knowing
- Block the internet but keep the LAN: block the app, then add a higher-priority Direct rule for your private ranges, so it still reaches a NAS or a local server while the outside world is closed to it.
- Block one endpoint instead of the app: match a domain or subnet so a telemetry host is refused while the rest of the app keeps working normally.
- Block only on some networks: bind the rule to a profile, so an app is silenced on a client's Wi-Fi and left alone at home.
- Block first, then decide: because attempts are logged, blocking is a reasonable default for an app you are still evaluating — you learn what it wants before granting it.
FAQ
Doesn't the macOS firewall already block apps?
Not this way. The firewall in System Settings controls incoming connections — whether other machines may connect to yours. It has no effect on outgoing traffic, so an app that phones out is unaffected by it no matter how it is configured. Blocking outbound traffic needs a different mechanism entirely.
Will blocking break the app?
Sometimes, and it depends entirely on the app. Anything with an offline mode usually carries on normally; something that verifies a licence or loads content on launch may show an error or hang. Blocking is one toggle, so the honest approach is to try it and unblock if the app misbehaves — nothing is uninstalled or modified.
How is this different from Little Snitch or LuLu?
Those are outbound firewalls: their job is to intercept connections and ask you about them, which is exactly right when auditing everything is the goal. This is a routing tool where blocking is one of three actions a rule can take, alongside direct and proxy. If you want a prompt for every connection on the machine, use a firewall; if you want a handful of apps silenced while others are routed through different upstreams, a rule is simpler.
Can I block one server instead of the whole app?
Yes. A rule can match a destination as well as an application, so you can block a single domain, a wildcard or a subnet — either for one app or for everything on the Mac. That is the usual way to silence a telemetry endpoint while leaving the rest of the app working.
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.