What a macOS DNS leak is—and what it is not

People searching “macOS DNS leak” or “Mac VPN DNS settings” usually picture a dramatic failure: the public IP changes but every website name still resolves through home broadband. That can happen, yet day-to-day leaks are often quieter. Your browser traffic may be encrypted while a background app, system service, or stale resolver list still sends DNS to a router you trusted before lunch. On Mac, DNS is not a single switch; it is a stack of per-interface resolver orders, cached answers, optional DoH profiles, and whatever your VPN Network Extension injects when you connect.

A DNS leak, in practical terms, means a lookup for a hostname leaves the privacy path you expect—typically your VPN’s DNS policy—and reaches a resolver that can log or shape those queries (ISP, office gateway, hotel captive portal). It is not the same as a WebRTC IP disclosure inside a browser tab, nor does fixing DNS automatically solve every tracker. Still, for VPN users who care about consistent routing, DNS alignment is one of the highest-leverage knobs because almost every app asks for names before it talks on TCP or QUIC.

Apple’s own iCloud Private Relay and third-party VPNs can coexist awkwardly if you enable overlapping features. If you run a full-tunnel VPN, treat Private Relay as a separate product decision—turn it off while testing DNS behavior so you are not debugging two overlapping systems at once. Likewise, corporate MDM profiles may push fixed resolvers that override GUI settings; note that in tickets before blaming consumer VPN software alone.

Run a Mac DNS leak test before you change anything

Baseline measurement prevents placebo tweaks. Connect your VPN to a deliberate region, wait until the menu bar shows a stable session, then use a reputable leak-test page that reports which resolvers answered the probe—not only your egress IP. Run the test twice: once immediately after connect, and again after closing the laptop lid for a minute (sleep/wake is a classic Mac handoff bug). If resolver names flip back to your ISP only after wake, you have a reproducible handoff issue rather than a permanent misconfiguration.

Terminal power users can inspect live state with scutil --dns and compare output before and after connecting. You are looking for whether the highest-priority resolver set belongs to the VPN interface (often labeled utun*) versus Wi‑Fi or Ethernet. Do not obsess over every legacy entry—macOS keeps historical rows—but the active order should shift when the tunnel is up. Screenshot the “after” state when filing support; it beats describing “something feels leaky.”

If you recently followed our ChatGPT network stability checklist, you already know flaky DNS can masquerade as app outages. The same discipline applies here: separate “names do not resolve” from “names resolve but via the wrong resolver.” The fix paths differ.

macOS system DNS settings that matter for VPN users

On current macOS releases, open System Settings > Network, select the active service (Wi‑Fi or Ethernet), click Details, then DNS. Here you will see manually added servers or an empty list that inherits from DHCP. For most app-based VPN workflows, the best practice is: let the VPN client push DNS when connected, and avoid hard-coding ISP resolvers on the physical interface unless IT requires it. Manual entries on Wi‑Fi can outrank tunnel DNS during brief races right after connect.

  1. Disconnect the VPN temporarily and note any custom DNS rows on your active network service.
  2. Remove redundant public resolvers you added years ago for “speed tests” unless you still need them off-tunnel.
  3. Reconnect the VPN and re-open the DNS pane—many clients will not mirror their resolvers here, and that is normal when the tunnel owns lookups.
  4. Repeat scutil --dns to confirm priority moved to the tunnel interface.

Search domains and Supplemental Match Domains matter on office Macs: split-DNS for corp.example may need local resolvers while everything else uses the VPN. Consumer users rarely need search-domain edits; breaking them can stop internal printers from resolving. If you are not on a managed corporate image, leave search domains empty unless documentation tells you otherwise.

macOS also supports encrypted DNS profiles (DoH/DoT) from browsers and configuration profiles. A browser forcing its own DoH while the system uses VPN DNS can look like a “leak” in simplistic tests even when traffic is still encrypted—just to a different operator. During VPN DNS tuning, disable experimental DoH in browsers temporarily so measurements reflect the system path you are trying to fix.

VPN client DNS options on Mac (what to enable)

Modern macOS VPN apps use Network Extension frameworks to install a virtual interface and publish DNS settings to the OS. Wording varies by vendor, but you will usually see concepts like Use VPN DNS, DNS leak protection, or Force all DNS through tunnel. Enable the strictest option your workflow allows. “Use VPN DNS” should be on for everyday privacy-minded browsing; “allow local network” exceptions are where leaks reappear on purpose so printers and NAS devices stay reachable.

In ClashVPN for macOS, connect once, open settings related to network protection, and confirm DNS handling is set to follow the tunnel rather than fall back to the underlying interface. If the app exposes split tunneling or per-app bypass lists, remember every bypass is a deliberate hole: mail sync or a local dev server excluded from the tunnel may still issue DNS on the LAN. That is not a defect; it is a trade-off you should document for yourself.

Legacy IKEv2 or L2TP profiles created manually under System Settings > VPN behave differently from app extensions: they may honor server-pushed DNS—or ignore it—depending on profile flags. App-first clients generally update faster when vendors rotate resolvers. If you still maintain an old manual profile from a previous provider, delete it to avoid macOS offering two VPN stacks that fight for priority.

Split tunneling, LAN access, and DNS on the same subnet

Split tunneling sends some IP ranges outside the VPN while keeping others inside. DNS rarely splits as cleanly as IP. When you enable “local network access” or exclude private RFC1918 ranges, macOS may continue using your router as resolver for .local Bonjour names even while public sites use VPN DNS. That is expected for AirPlay and file shares. Problems start when exclusions are too broad—e.g., excluding all of 10.0.0.0/8—and general browsing DNS slips to the gateway.

Tighten exclusions to the smallest subnet you need. Prefer application-level split rules when the client supports them instead of giant CIDR blocks copied from forum posts. After changes, rerun your leak test; split tuning without measurement is guesswork.

IPv6, multicast DNS, and other Mac-specific leak paths

IPv6 is the second place Mac users look after classic DNS leaks. If your VPN tunnels IPv4 only while the physical interface still has a global IPv6 address, some hosts may prefer AAAA records and exit without the tunnel. Mitigations vary: choose a VPN that handles IPv6 policy explicitly, disable IPv6 on the physical interface only when you understand the side effects, or rely on client settings labeled IPv6 leak protection. Disabling IPv6 bluntly can break reachability on networks that are v6-only—test your actual sites before locking it in permanently.

Multicast DNS (.local) does not traverse most VPNs by design. That is not an ISP DNS leak, but privacy testers sometimes flag it. Know the difference so you do not chase Bonjour noise. Similarly, captive portals on airport Wi‑Fi may require a momentary disconnect; macOS “Ask to join hotspots” and auto-login pages can stall DNS until you authenticate in Safari—VPN on or off.

Sleep, wake, and network changes (when DNS “forgets” the tunnel)

Closing the lid mid-meeting is routine; macOS renegotiates Wi‑Fi, rediscovers gateways, and sometimes reapplies DHCP DNS before the VPN extension catches up. If leak tests pass on a fresh connect but fail only after resume, try: disconnect VPN → toggle Wi‑Fi off/on → reconnect VPN. Update the client—handoff bugs are often fixed in point releases. Avoid running two VPN clients simultaneously; double extensions race to install DNS and leave neither authoritative.

Moving between Ethernet dock and Wi‑Fi triggers the same class of issue. Pick a habit: pause downloads, disconnect VPN, switch interfaces, reconnect. Faster than debugging mysterious resolver order with half a dozen browser tabs open.

Troubleshooting Mac VPN DNS leaks (checklist)

  • Leak only after sleep: Reconnect VPN; update client; disable overlapping iCloud Private Relay or second VPN; check for MDM DNS profiles.
  • Sites fail but leak test is clean: Flush DNS cache with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (admin password required); verify you are not blocking the VPN’s resolver IP in a firewall suite.
  • ISP resolver still appears: Remove manual DNS on Wi‑Fi/Ethernet; turn on client DNS protection; narrow split-tunnel exclusions; delete stale manual VPN profiles.
  • Office LAN printers broke: Re-enable limited local network access; accept that .local may bypass tunnel DNS by design.

Browser-only “VPN” extensions deserve a special mention: they proxy tabs, not system DNS. Safari, Mail, and Background Tasks can still query your ISP while the extension shows a foreign IP in one website’s widget. That gap is why platform guides matter—our iPhone VPN server switching guide covers the iOS side of the same system-versus-extension divide, and the Mac story is parallel: install a real client, grant Network Extension permissions once, and let it own resolver policy.

Free public DNS changers marketed as “one-click privacy” without a tunnel only swap who logs your queries—they do not encrypt traffic to sites. Pairing them with a half-configured VPN can even prolong races where macOS prefers the wrong order. A maintained desktop client that pushes DNS at connect time is simpler to reason about than stacking three partial fixes.

ClashVPN on macOS fits the app-first model: signed installer from the official download flow, unified login and signup through the same entry point as other platforms, DNS alignment handled when the tunnel comes up, and no forced ads gating the baseline experience. New accounts receive free high-speed traffic after registration without binding a card; paid plans only matter when you voluntarily need more volume—every tier uses the same node catalog, so DNS behavior does not change because you upgraded traffic alone.

If you also manage Android devices in the household, mirror habits across platforms—our Android VPN install guide walks through permission and first-connect checks that complement the Mac DNS steps here. On this Mac, grab the client from the download page, connect once, run a leak test, and only then tune split tunnel or LAN exceptions with evidence instead of superstition.