macOS & Windows

Two of the three routing modes run here. Pick from the table first — choosing the wrong one is the single most common way a first attempt fails, and it fails without saying so.

Which mode to choose

Mode	macOS / Windows	What it costs
destinations	Yes	Only the addresses you name go through us. Cannot receive connections from anywhere else.
full	Yes	Everything the machine sends goes through us, so all of its traffic takes our path and our latency.
source	No	Linux only. See below.

If a partner has to see your address, choose Named destinations and list the partner. If you are hosting something the internet connects to, you need Full tunnel — see use cases.

Why source routing is not offered here

Source routing means “traffic from this address goes through the tunnel”, and that is a feature of the operating system, not of WireGuard. Linux has it as ip rule from …, which is what our source-routed file uses. Windows has no equivalent — its routing decides by destination only. macOS has no equivalent in route either.

So the file cannot work there, and it does not fail gracefully. The App Store and mobile clients have nowhere to run its PostUp lines at all. The Homebrew wg-quick does run them, they call ip, macOS has no such command, and wg-quick then deletes the interface it just made.

macOS

Install WireGuard from the Mac App Store, or brew install wireguard-tools for the command-line version. Both run the two supported modes.

In the app: Import tunnel(s) from file, choose your .conf, activate.

With Homebrew instead:

sudo mkdir -p /etc/wireguard
sudo install -m 600 anchoredip-42.conf /etc/wireguard/aip0.conf
sudo wg-quick up aip0
sudo /opt/homebrew/bin/wg show

The interface gets a name of its own — utun7 or similar — so wg show aip0 will say it cannot find it. Use wg show with no argument. And sudo drops Homebrew from the path, which is why the full path is spelled out above.

Windows

Install the official client from wireguard.com/install, then Add Tunnel → Import from file and activate.

Or from an elevated PowerShell, as a service that survives reboots:

wireguard.exe /installtunnelservice C:\path\to\anchoredip-42.conf

If the machine is on a corporate VPN

A managed device often carries an always-on VPN — Cloudflare WARP under a Zero Trust policy, Zscaler, Netskope. How it interacts with a tunnel of yours depends on how it works, and there are two kinds.

One installs a default route. A Named-destinations config survives beside it: every route it adds is more specific than a default one, so the kernel prefers it for those addresses and the corporate VPN keeps everything else. A full tunnel will fight it and lose.

The other captures traffic below the routing table, and then no tunnel on that machine can carry anything — ours included, whichever mode. Measured on a Mac under a locked WARP profile in exclude mode with an empty exclude list: the handshake completed normally and not one byte of payload ever reached us, because the packets never reached the routing table to begin with. The only fix is for whoever manages the policy to exclude our address range; it cannot be done from the machine.

The symptom is specific and worth recognising: the client reports a recent handshake, and every request still leaves from your ordinary address. If you see that, stop testing and ask your administrator.

AmneziaWG on a desktop

An AmneziaWG config needs an AmneziaWG client. The obfuscation parameters travel in the file and must not be edited. The stock WireGuard app and the Homebrew wg tools cannot use it: they reject the extra keys, or connect to nothing.

On macOS, use the AmneziaVPN app: import the .conf file and connect. Measured on version 5.0.3 with a full-tunnel config — handshake, the leased address confirmed by curl https://api.ipify.org, and the rest of the internet answering through it.

A config created before 13 October 2026 will not work in the AmneziaVPN app. It listed every address on one Address line, which the app cannot parse: it either refused to connect, or connected and carried nothing. Revoke that tunnel in your dashboard and create a new one — the file you get now has one address per line, written the way the app reads it. Other clients were never affected.

The AmneziaVPN app carries IPv4 only. It ignores the IPv6 address in the file and puts an internal one of its own on the interface, so your /48 does not reach that machine through it. If the Mac needs IPv6, use a WireGuard config in the WireGuard app instead. amnezia-box, Amnezia’s fork of sing-box, also runs our full-tunnel config — a customer uses it — but its releases ship as source and we have not run it ourselves.

On Windows we have not tested an AmneziaWG client. If you use one and it works, or does not, write to support — that is how this section got written.

Verify

curl -s https://api.ipify.org

On a full tunnel this prints your leased address, with nothing to bind. On Named destinations it prints your own address, and that is correct — only the addresses you listed go through us. Test that mode by reaching one of them and asking what it saw. If neither behaves as described, check troubleshooting.