macOS has no built-in way to send one app through a VPN while everything else uses your normal connection. When you connect a VPN app, it replaces your default route, and every process on the machine follows it: your browser, your video calls, your backups, your bank.
There are three ways around that. Here's what each actually involves.
The direct answer. A handful of macOS tools can route traffic per application:
Run the app inside a VM (UTM, Parallels, VMware Fusion) and connect the VPN inside the guest. Complete isolation, works with any VPN client, and costs you nothing if you use UTM.
The downsides are real though: several gigabytes of disk, a second OS to keep updated, no GPU acceleration for video work, and clumsy file sharing. Fine for a browser or a chat client, painful for a video editor.
macOS ships with PF, a packet filter that can't match traffic by application but can match by unix group. A per-app VPN can launch an app under a private group and route that group's traffic into an owned WireGuard tunnel.
VPNonly's current privileged engine source is public for inspection. The repository's root-level command-line scripts are an older prototype: they assume a fixed tunnel interface and replace PF's main ruleset. They are kept for history and are not recommended on a current Mac.
The how it works page explains the current app's safer ownership and firewall model.
If you want a maintained per-app switch and support when it breaks, that's what VPNonly is for. If you need genuine isolation rather than just a different exit IP, use a VM.
Moving an app onto a VPN changes its exit IP, not its DNS by default. With VPNonly, connections are tunneled but DNS lookups still go through your system resolver. If your goal is a different exit IP, that's fine. If your goal is hiding which sites you visit from your ISP, you need a tool built for that.
The app’s exact privileged engine source is public and MIT licensed.