How to route one website outside your WireGuard tunnel

Excluding a hostname is something a tunnel cannot do. A route, though, can point a single address past the tunnel and out through the home gateway, and that is usually enough for one site. The catch is that everything downstream of the route has to agree: the firewall has to let the packet out, DNS has to hand back the address you routed, and the site has to keep using that address. When any one of the three drifts, the exception stops working without announcing itself.

Read the destination address before you touch the tunnel

Load the site once with the tunnel up, then look at the peer address the browser actually connected to. On Linux, ss -tunp lists the remote address for every open socket, and dig +short on the same name shows what the resolver returned. Keep both numbers in front of you.

The two answers disagree often, and the disagreement is the whole problem. Large sites put a content network in front of their origin, so the address your resolver returns now may not be the one the browser used a minute ago. Route what you observed on the socket, not what an older guide lists. If the answers keep rotating across regions, an address exception is the wrong instrument for that particular site.

Run the lookup a second time from another network, and record the IPv6 answer along with the IPv4 one. A tunnel that carries both families needs an exception in both, otherwise the browser quietly falls back to the IPv6 path you never touched. Put the addresses and the date somewhere you will look at again.

Put one host route on the client

Assume the interface is called home-wg and the LAN router sits at 192.168.1.1. NetworkManager takes a route whose gateway is that router and whose prefix length covers the full 32 bits, and the kernel prefers it because the longest prefix wins.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

The gateway has to be reachable without the tunnel; pointing the next hop at the tunnel address defeats the purpose, because the packet would re-enter the interface you are trying to avoid. After the connection comes back up, ip route get for the exception should print the LAN gateway, and the same command for a public resolver should still print the tunnel device.

A wg-quick profile has no routes field, so the same exception lives in a PostUp line that adds the host route to the main table with the LAN interface as its device. Bring the interface down and up after editing, since a running interface never re-reads its file. The fwmark rules wg-quick installs only steer its own encapsulated packets, so ordinary browser traffic still follows the main table and finds your /32.

The kill switch is the next thing that blocks it

A firewall policy that admits traffic only on the tunnel interface will drop the exception even when the route is exactly right. Read the rules behind the toggle instead of trusting the toggle, because the ones that implement a kill switch are usually scoped to an interface name.

What you want is a narrow permission for the physical interface and that one destination, placed before the drop, while the default policy stays untouched. Pausing the kill switch wholesale does prove the point, but it also leaves the machine exposed for as long as you forget to turn it back on.

Test the two directions separately. A request to the exception address should succeed while a request to an unrelated site still exits through the tunnel. If both succeed but the second one reports the home address, the ordering of the firewall rules is wrong rather than the route.

DNS decides which address the browser dials

When the name resolves inside the tunnel, the provider's resolver can answer with a different address than the local one did. Your route then applies to an address the browser never contacts, and the page loads through the tunnel as though nothing had changed. This failure looks like a broken exception even though the routing table is correct.

Send that name's queries through the local resolver as well, or skip names entirely and test the address directly. Splitting the address while leaving DNS inside the tunnel is the most common half-finished version of this setup, and it is also the hardest to notice, because the site keeps working, just not the way you intended.

Same exception on the router, once, for every device

With the tunnel running on the router, the host route belongs in the router's policy routing table and points at the WAN gateway instead of the LAN one. Every device behind it inherits the exception, which matters for a streaming box or a work laptop whose network settings you cannot change.

Leave the tunnel as the default exit for every other client, then verify from a client machine rather than from the router console. Load the exception site and a second site in the same browser session and compare the exit addresses; if the second still shows the tunnel, the policy table is doing what you asked.

Write down the address, the date, and the reason in the router's notes. An exception built around an address that later moves becomes a fault nobody can explain a year from now, and the fix always looks like a mystery until someone finds the old note.