Send one app through a proxy. Leave the rest alone.
TrafficWeaver is a macOS utility that routes outbound connections from the applications you choose through the SOCKS5 or HTTPS proxy servers you already have. Everything you don't write a rule for keeps working exactly as before.
macOS 13 Ventura or later · Apple silicon and Intel · signed and notarized by Apple
What it actually does
You give it a proxy — one you run, one your company runs, or one you rent — and a few rules. From then on the connections that match those rules go through that proxy, and nothing else changes. There is no virtual adapter, no system-wide switch to forget about, and no traffic quietly taking a different route than you expect.
A rule looks like this
Applications com.anthropic.claudefordesktop*
Target hosts claude.ai
*.anthropic.com
Match when app or target matches
Action Proxy: Office SOCKS5
Rules are evaluated top to bottom and the first match wins. You can pick applications from a list instead of typing identifiers, and there is a library of ready-made services if you'd rather not look up which CDN domains a site loads from.
Why not just set a system proxy
A system proxy is all-or-nothing, and plenty of software ignores it. TrafficWeaver works at the connection level using a Network Extension, so it sees each outbound connection together with the application that opened it. That is what makes "this app, through this proxy, and only this app" possible.
Details that usually matter later
| Proxy protocols | SOCKS5 with optional username/password authentication, and HTTPS (CONNECT) with Basic authentication. Host names are passed to SOCKS5 proxies unresolved, so name resolution happens at the proxy rather than on your machine. |
|---|---|
| UDP | Carried through SOCKS5 UDP ASSOCIATE, so DNS and QUIC can follow the same rules as TCP. |
| Proxy chains | A rule can route through several proxies in order. TCP only — the SOCKS5 UDP mechanism cannot be nested, so datagrams matched by a chain rule are dropped rather than quietly sent through a single hop. |
| Matching | By application (bundle identifier or executable path, with wildcards), by host name
(*.example.com also covers example.com), by network
(10.0.0.0/8), by port or port range, and by TCP/UDP. |
| Rule simulator | Type a hypothetical app, host and port and see which rule would win and why each other rule did not match. Useful before you find out the hard way. |
| Connection log | Live list grouped by application, with the matched rule, byte counters and a throughput graph. Exports to CSV. |
What it does not do
This is a routing tool, not a proxy service. It ships no servers and no bundled endpoints — you supply the proxy. It does not decrypt TLS, does not inspect payloads, and does not modify the traffic it forwards.
One honest limitation. macOS hands some connections to the extension with only an IP address, because the application resolved the name itself. TrafficWeaver recovers the name where it can by reading the DNS answers it already relays, and matching by application always works. But an app that resolves over encrypted DNS, or connects to hardcoded addresses the way Telegram and SSH often do, can only be matched by application, not by host name. The connection log tells you which case you are looking at.
Trial
Fourteen days, everything enabled, no account. When the trial ends the app stops routing traffic and your Mac carries on as if it were not installed. Buying a licence re-enables it without reinstalling.