Mac VPN, Content Filter or Private Relay: Which Is Active?
Three Mac network layers look alike in Settings. Use exit path, flow policy and browsing scope to tell a VPN, a content filter and Private Relay apart.
Your Mac can have a VPN tunnel, a content filter and iCloud Private Relay installed at once, and none of them announces which one is shaping a given connection. The settings panes look similar, the icons look similar, and nearly every vendor calls its product network security. Three facts separate them: whether traffic leaves through a remote endpoint you can name, whether a policy engine is making allow-or-drop decisions on individual flows, and whether the protection stops at Safari. Get those three straight and most is-my-VPN-on questions answer themselves.
Three conditions that identify the component
Condition one is the exit. A tunnel provider hands packets to a remote gateway, so your public address changes and, if the profile says so, hosts behind that gateway become reachable. If the address never changes and no private subnet opens up, you are not looking at a working tunnel, whatever the menu bar says.
Condition two is the decision. A content filter evaluates flows and returns allow or drop. It can enforce a category block, a per-app rule or a policy pushed by an employer, and it can log the verdict. What it cannot do on its own is give the traffic somewhere to go.
Condition three is scope. Private Relay protects a defined slice of browsing rather than a whole device, and its job is to separate who you are from what you visit, not to place you on another network.
Line the three up and the boundaries are hard to miss:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
A content filter is a policy engine, not an exit
On macOS a filter arrives as a Network Extension built on Apple's filter data provider class, NEFilterDataProvider. In a managed deployment it is pushed by MDM, installed as a system extension, and approved once under System Settings, General, Login Items and Extensions. From then on it sees TCP flows, and in some configurations UDP as well, and returns a verdict on each one.
The failure mode is what confuses people. A filter that drops a flow produces a timeout, a stalled TLS handshake or a reset, which looks exactly like a tunnel that came up but cannot pass traffic. The public address never changed, because there was never an exit to change it.
Commercial clients often bundle both roles. One installer ships a tunnel provider and a filter, the filter does the blocking, and the tunnel does the routing. So the application name tells you nothing about which component refused the connection. Check the extension list, then the connected service, then the client log, in that order.
Private Relay covers Safari, not the machine
Private Relay sends the browsing it covers through two relays operated by separate parties, so no single operator holds both your identity and your destinations. That is a privacy design, not a tunnel: there is no gateway you can reach into, no private subnet, and no way to pin an egress address in a country you choose.
Its scope is deliberately narrow, covering Safari browsing along with the DNS lookups and insecure HTTP loads that go with it. A terminal session, a mail client, a chat app and a game launcher sit outside it. If a check in Terminal still shows your access-network address while Safari shows a relay address, that is the expected result, not a broken install.
Availability is conditional. It needs an iCloud+ plan, it is not offered in every region, and a managed network can block relay access, in which case Safari falls back to a direct connection. Apple's Private Relay overview is the reference for the current scope. When a VPN profile is connected and carrying that traffic, the relay is not stacked on top of it; the profile decides the path.
Read the evidence in the right order
Start with service state, because it is the cheapest signal. scutil --nc list prints the configured VPN services and whether each is connected. A profile can sit there for years without ever being connected, and people routinely count that as a tunnel.
Then look at interfaces and routes. ifconfig shows utun interfaces, but their presence proves little on its own, since macOS uses utun for several purposes beyond VPN. What matters is whether the default route points into one, which route -n get default reports.
For name resolution, scutil --dns lists the resolvers the system will actually use, and a DNS proxy provider shows up there. Comparing dig +short example.com with dig +short example.com @1.1.1.1 separates the resolver answering from the resolver being intercepted.
Extension activity reaches the unified log: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. You are looking for which extension started and whether a filter reported a verdict on the flow you care about, not for a line to memorize.
Narrow the symptom before you disable anything
Classify the failure first. A name that does not resolve, a connection refused immediately, and a connection that hangs until timeout are three different observations with three different owners. Resolution points at a resolver or DNS proxy. Immediate refusal points at a filter rule. Silence usually points at routing, or at a tunnel that is up but not forwarding.
On a managed Mac, assume the filter belongs to the organization. Disabling it to test the VPN removes the component you were trying to observe, and MDM often restores it at the next check-in. Ask the administrator for the policy name before you change anything, and test with the specific app that failed instead of the whole system.
One more trap: switching off Private Relay to test a VPN tells you nothing about foreign traffic, because the relay never covered that traffic in the first place. Each layer has to be tested on the app it actually governs.
Work through this list and stop at the first item that fails:
- Does
scutil --nc listshow the service you expect as connected? - Does the public address seen from Terminal differ from the address your access network assigned?
- Is a filter extension installed, and did it log a verdict for the failing flow?
- Is the failure Safari-only? If so, check relay scope before blaming the tunnel.
If all four pass and the app still fails, the problem sits above the network layer: proxy settings, certificate trust, or an application-level allow list.