<!-- llms-explorer concept facts · https://llms-explorer.com/tree/fake-ip-split-dns-and-utun-tunnel-route-changes-as-false-tcp-down-dns-up-diagnoses/ · pack 2026-10-29 · ~1578 tokens -->

# Fake-IP, split-DNS and utun tunnel route changes as false TCP-down/DNS-up diagnoses

> Source-anchored research for Fake-IP, split-DNS and utun tunnel route changes as false TCP-down/DNS-up diagnoses. Run status: COMPLETED.

Parent: [Apple Platform Publishing (Mac App Store)](https://llms-explorer.com/tree/apple-platform-publishing-mac-app-store/) · 3 facets · 11 facts · page: https://llms-explorer.com/tree/fake-ip-split-dns-and-utun-tunnel-route-changes-as-false-tcp-down-dns-up-diagnoses/

## How it works

- A successful name lookup followed by a TCP timeout can result from route selection even when DNS returned an answer. Apple says the system routing table can supersede NetworkExtension included and excluded VPN routes. A macOS two-utun troubleshooting report describes a hostname resolving to 10.99.99.99 while a broad 10/8 route sent TCP and ICMP over the wrong utun; route -n get exposed the selected interface. (medium confidence) — [source](https://developer.apple.com/documentation/networkextension/routing-your-vpn-network-traffic?changes=l__4)
- The 2023 USENIX Security study demonstrates that VPN route exceptions can be manipulated to send traffic outside the protected tunnel. Its threat model concerns routing-based traffic leaks; it does not establish that routine macOS fake-IP or split-DNS TCP failures share that cause or measure how often they occur. (low confidence) — [source](https://www.usenix.org/system/files/usenixsecurity23-xue.pdf)

## Problems, failure modes and limitations

- A macOS dual-VPN report describes an internal hostname resolving to 10.99.99.99 while TCP and ICMP timed out: an aggregate 10.0.0.0/8 route through utun0 captured traffic intended for a second tunnel on utun15. The report recommends checking `route -n get <IP>` to see which route handles the resolved address before treating the symptom as DNS failure. (medium confidence) — [source](https://blog.margrop.net/en/post/macos-routing-table-vpn-troubleshooting/)
- For a VPN configured with includeAllNetworks set to true, Apple documents that the transition from disconnected to connecting leaves existing TCP connections open but drops their subsequent packets; when that VPN leaves connected state, the system drops network traffic. A TCP timeout during this tunnel transition can therefore occur without a DNS lookup failure. (high confidence) — [source](https://developer.apple.com/documentation/networkextension/routing-your-vpn-network-traffic?changes=l__4)
- A Versa support article reports the converse case after VPN disconnect: hostname resolution can fail while direct IP connectivity remains available when the VPN and underlay use the same DNS server IP and the system resolver remains pinned to a defunct utun path. DNS failures after a tunnel transition are therefore possible and should be checked directly. (low confidence) — [source](https://versanetworks.freshdesk.com/support/solutions/articles/23000029468-dns-resolution-failure-after-vpn-disconnect-macos-)
- Mihomo fake-IP mode can return synthetic addresses such as the documented 198.18.0.1/16 range. Its TUN documentation says macOS defaults to dns-mode disabled when unset and cannot automatically hijack DNS requests sent to the local network. A Clash Verge report shows the resulting resolver-path split: the system resolver returned router DNS results while Mihomo returned fake IPs; a direct request failed while a request forced to the fake IP succeeded. (medium confidence) (verified as of 2026-10-22) — [source](https://wiki.metacubex.one/en/config/dns/)
- A TCP-down/DNS-up symptom does not identify one root cause. Mihomo advises selecting the outbound interface explicitly when multiple interfaces are active. In an August 11, 2026 follow-up on the Clash Verge report, another commenter said enabling Mihomo sniffing restored connectivity without changing the TUN stack, strict-route setting, or TCP port 53 hijack. Check resolver results, the route and outbound interface, and the client's request logs before assigning the failure to DNS or a utun route. (medium confidence) (verified as of 2026-08-11) — [source](https://wiki.metacubex.one/en/config/inbound/tun/)

## Facts and statements

- Apple configures packet-tunnel DNS resolver settings separately from IP included and excluded routes. `NEDNSSettings.matchDomains` selects DNS settings by hostname, while `NEIPv4Settings.includedRoutes` selects IPv4 destination traffic for the TUN interface. A live utun or route therefore does not establish which resolver answered a name, and a successful DNS answer does not establish which interface carries traffic to its IP. (high confidence) — [source](https://developer.apple.com/documentation/networkextension/netunnelprovider/settunnelnetworksettings%28_%3Acompletionhandler%3A%29)
- Apple's NEDNSSettings.matchDomains selects which DNS queries use the tunnel resolver; nonmatching names use the system default resolver. Apple also documents that a VPN which becomes the network's default route uses its configured DNS servers as the default resolver and ignores matchDomains. A successful lookup alone therefore does not show which resolver produced the answer. (high confidence) — [source](https://developer.apple.com/documentation/networkextension/nednssettings/matchdomains)
- A Clash Verge Rev report updated on 2026-08-11 showed TUN routes through utun1024 while `scutil --dns` still selected the router on en0. System resolution returned real IPs, local Mihomo DNS returned 198.18.x.x Fake-IP addresses, and a forced request to a Fake-IP address received HTTP 302 while the ordinary request timed out. This case shows that TUN route presence alone did not prove the system resolver was using the intended Fake-IP path. (low confidence) (verified as of 2026-08-11) — [source](https://github.com/clash-verge-rev/clash-verge-rev/issues/7100)
- Implementation inference from the split-DNS guide and the two-utun route report: inspect scutil --dns for resolver selection, then use route -n get <returned-IP> and test TCP to that same destination. A direct dig query to a named DNS server checks that server, while an application request tests the resolver and route path that the application actually uses. (medium confidence) — [source](https://gethostbar.com/guides/vpn-split-dns-not-resolving-mac)