macOS Service Order Does Not Control Your VPN Routes

Something on a website fails, a colleague remembers that service order exists, and Wi-Fi gets dragged above Ethernet. Nothing changes, because that list never decided where a VPN destination goes. Apple gives VPN connections priority over ordinary ones and keeps them out of that reordering, so the switch answers a narrower question than the one being asked. The failure needs the selected route and the resolver, not a new ranking.

What service order changes, and what it never touches

Set Service Order lives under System Settings, Network, in the Action menu, and it ranks ordinary connections when two or more are active. That ranking picks the primary service, which supplies the default route and part of the resolver behaviour. It is a tie-break among peers, not a switch for private destinations behind a tunnel. A laptop with Wi-Fi and a USB Ethernet adapter uses it to answer a sensible question, and that question is not about the tunnel.

A VPN profile carries included routes, excluded destinations and sometimes per-application rules, and those decide what enters the tunnel; the ordering menu does not edit them. That is why a split-tunnel profile can leave public traffic outside while the VPN still outranks every physical interface. Dragging Wi-Fi to the top cannot make a private range reachable, and it cannot stop a destination the profile already includes. The list moves interfaces; the profile moves prefixes. Apple documents the priority on its network service order page, which is worth reading once before you rearrange anything.

Read the route the machine actually selected

Ask the machine where a specific address goes with route get 10.20.4.10, then repeat it for IPv6 with route -n get -inet6 2001:db8::10. The two families are separate decisions, so a working IPv4 path says nothing about the v6 one, and a directly connected subnet or a more specific prefix beats the general connection label anyway, which is exactly why the label keeps misleading people.

If the output names the tunnel interface, the profile captured the destination and the ordering is irrelevant. If it names the physical interface, the profile did not, and no amount of dragging will change the prefix table. Both outputs also name the source address the machine would use, which is the field to quote when you compare two runs. Save the output before you change anything, because it is the only evidence you will have afterwards.

DNS resolves by name, not by interface

Scoped and domain-specific resolvers mean the answer can differ per name rather than per interface. scutil --dns prints the resolver configuration the system is actually using, scoped entries included. Service order influences which service supplies the default resolver, but a name-specific scope can win regardless.

That is why a ping to an address can work while the hostname fails, or the other way round. Read both outputs before you choose a culprit.

Change the profile, then re-read both outputs

When a destination policy needs to change, the owner is the VPN profile: included routes, excluded routes and whatever split-tunnel rules the vendor supports. Changing interfaces instead just moves the argument. On a remotely managed Mac, save the current network state first, because losing the tunnel on a machine you cannot reach is a trip rather than a rollback.

Reproduce the failure, read the route, read the resolver, change one thing, then read the same two outputs again. Shuffling several services and profiles at once leaves a machine nobody can explain, including the person who fixed it. The test is finished when both outputs agree with the change you intended. If they still disagree, the profile and the machine are describing two different policies, and the profile is the one to change.