macOS: default-interface monitor stays on removed USB tether after Wi-Fi handoff

[grinkevichegor]

Environment

• Apple Silicon M4, macOS 27.0
• Clash Verge Rev 2.5.8; Mihomo v1.19.32 (88dcbf7); github.com/metacubex/sing-tun v0.4.27
• TUN with gVisor, auto-route and auto-detect-interface; no fixed outbound interface

Observation

On one iPhone hotspot, USB (en7) works with TUN, mixed proxy and direct HTTPS. After joining the same hotspot by Wi-Fi, macOS uses en0 as its physical default and en7 goes inactive. New physical HTTPS succeeds, while new mixed-proxy and system-TUN HTTPS time out. Outbound dials report network is unreachable; the core logged default interface => en7 but no subsequent => en0 before the stock trial ended. We also observed attempted dials retaining the disappeared USB source address. A TUN restart restores traffic, but is only a workaround.

Controlled isolated-core trial	USB baseline	After USB → Wi-Fi
Stock Mihomo/sing-tun	Mixed and TUN 4/4	Physical HTTPS 6/6; mixed and TUN 0/6; monitor stayed on en7
Same source with Darwin recheck	Mixed and TUN 4/4	Monitor selected en0; mixed and TUN recovered after brief warm-up
Patched repeat after stock failure	Wi-Fi → USB passed	USB → Wi-Fi passed without TUN restart

The patched core was also installed as a local Clash Verge pilot. Both admin and ordinary configurations completed Wi-Fi → USB → Wi-Fi with TUN enabled. One ordinary run had a transient timeout followed by four consecutive successes. This supports repair of the persistent stale-interface failure, not lossless handoff.

Diagnostic candidate and limits

The attached sanitized source patch adds a Darwin-only 2-second recheck using the existing postCheckUpdate() path, stops it on Close(), and tests rechecks without a route event. This is a diagnostic candidate; an event-driven repair or slower fallback may be preferable. One place worth examining is networkUpdateMonitor.loopUpdate0/loopUpdate1 in sing-tun v0.4.27: it opens an AF_ROUTE socket, reads once, then closes and reopens it. Could a rapid handoff event fall between reads? This is a source-level hypothesis, not a proven cause.

The isolated comparison used a privately copied application runtime. I have not yet reduced it to a standalone public DIRECT-only CLI configuration, tested latest Alpha, or collected complete DEBUG logs suitable for publication. I cannot prove whether macOS omitted a route event or the monitor missed it. Same-interface Wi-Fi IP/gateway changes, sleep/wake and other networks still need separate checks. No private profile, endpoint, address, capture or raw log is attached.

Could maintainers advise the preferred fix in sing-tun/Mihomo and whether a minimal DIRECT CLI reproduction would help? A related Clash Verge report is #7576; it has a different trigger and does not establish the same root cause.

Sanitized diagnostic source patch:
vpn082-sing-tun-poll.patch.txt

[grinkevichegor]

Update (2026-10-24): I reproduced a stale outbound selection with the current official Mihomo Alpha alpha-91e85ee, launched directly from the CLI with a public DIRECT-only configuration. The bounded Wi-Fi → iPhone USB trial, complete redacted DEBUG log, hashes and probe results are now in formal bug issue #3357. This is the reverse transition from the original Discussion observation; a shared root cause is not established.