On this page
Pin the outbound interface only for this set of log messages
This article covers one specific failure: after an Intel Mac connects to an iPhone Personal Hotspot, direct system networking works but Clash Verge Rev cannot connect with TUN enabled. The environment in official issue #7576 uses client v2.5.2 and Mihomo v1.19.29. Other Mac systems should follow this procedure only when the same logs appear.
The key is not the webpage timeout. Immediately after TUN starts, the log shows get empty name, then <invalid>, then interface not found, followed by dns resolve failed. Automatic egress detection first receives an empty interface, leaving DNS and proxy connections without a usable egress.
First confirm that this is the same issue
| Symptom | Interpretation | Next step |
|---|---|---|
| Direct system connectivity returns immediately after TUN is disabled | The node and system network are at least not failing together | Continue by checking the outbound interface |
| The log first shows get empty name or <invalid> | Automatic detection did not obtain an egress in time | Query the current physical adapter |
| The log contains only operation not permitted | This is a permissions or service-mode issue | Do not change the outbound interface |
| Neither the system proxy nor TUN can connect | The node, subscription, or core may have failed | Troubleshoot the shared failure first |
- iPhone Personal HotspotProvides the current network egress for the Mac
- macOS physical adapterThe route command shows the real interface
- Mihomo TUNUse that interface for DNS and connections
- Destination websiteCompletes resolution, rule matching, and access
If automatic detection receives an empty value in the second step, subsequent DNS and egress fail. Pinning an interface applies only to this log pattern.
Use the system route to identify the adapter used by the hotspot
First disable TUN so macOS returns to a directly connected state, then query the route to a public address in Terminal. The interface in the output is the physical adapter currently carrying hotspot traffic. Do not guess the name from someone else's screenshot.
route -n get 223.5.5.5Record only the actual result on this Mac
Confirm direct connectivity
Disable TUN and the system proxy, then open an ordinary webpage so the route is not read from a failed state.
Find the interface line
The issue reporter saw en0, but Wi-Fi, a USB adapter, or a wired connection may have a different name.
Run it once more
Disconnect and reconnect the mobile hotspot, then query again. Confirm that the interface name remains unchanged before writing the override.
Override only two fields in Merge
Mihomo uses top-level interface-name for outbound traffic and places auto-detect-interface under tun. Open Merge or the override for the current Profile and add only these two keys. Do not copy the issue's complete TUN, DNS, or IPv6 configuration, which could replace settings that already work.
interface-name: en0
tun:
auto-detect-interface: falseen0 is only an example. Do not put it in tun.device either. Official documentation says the macOS TUN device name begins with utun, while interface-name is the interface Mihomo uses to send traffic outward; they serve different purposes.
Restart the core, inspect the log first, then test DNS and webpages
After saving the override and passing configuration validation, restart the core completely, then enable TUN. Inspect the newly generated log first rather than relying on the switch color. After the interface error disappears, make a new DNS query and HTTPS request.
Validate in the same order
Reload the current configuration
Confirm that the original Profile and node remain selected. Do not change the subscription, DNS, or proxy mode at the same time.
Enable TUN again
Read the log from this startup and check whether <invalid> or interface not found still appears.
Make two types of requests
Open an ordinary webpage first, then check whether the Connections page shows the domain, rule, and actual egress.
Disable TUN for comparison
Confirm that direct system connectivity still recovers, so a cache hit is not mistaken for a completed fix.
The empty-interface and interface not found messages disappear, and webpages recover
Pinning the interface has bypassed this automatic-detection failure; continue with network-switch validation.
interface not found still appears
The interface name is wrong or has changed. Disable TUN and query the system route again.
The interface error disappears, but dns resolve failed remains
Stop adding DNS fields. Remove the override and troubleshoot DNS as a separate issue.
Configuration validation fails
Check that interface-name is at the top level and that indentation under tun is two spaces.
Recheck after switching networks when the interface is pinned
Manually selecting the interface disables automatic detection. It can temporarily stabilize a mobile-hotspot environment, but after switching back to home Wi-Fi, a USB network, or a wired connection, the original interface may no longer be the default egress. If it is not updated, TUN can remain enabled without establishing new connections.
Handling network changes
| Query result | Action |
|---|---|
| interface matches the override value | Keep the current setting, then test DNS and webpages |
| interface has changed to another name | Disable TUN, update interface-name, and restart the core |
| You will switch networks frequently | Remove the pinned-interface override, restore automatic detection, and observe whether the issue returns |
| Another VPN or TUN is running at the same time | Disable and test them separately first; do not hide a routing conflict behind one fixed value |
If it does not work, remove the override and restore the original configuration
If pinning the correct interface still fails, automatic detection is not the only cause. Do not keep adding DNS, routing, or script settings from unknown sources. Restore the Profile from before the change.
Complete rollback order
Disable TUN
Wait for ordinary system networking to recover before editing Merge, so the old core does not keep using the failed route.
Remove the two override keys
Remove top-level interface-name and the tun.auto-detect-interface added in this procedure, restoring the original content.
Reload the original Profile
Keep the original node and rules, then complete one request through the system proxy to confirm that basic connectivity still works.
Retain redacted logs
Record the macOS, client, and core versions plus the first error after enabling TUN, and submit them to the corresponding official issue.
Five checks to confirm TUN works again on the hotspot
Final validation checklist
- With the system proxy disabled and only TUN enabled, both the browser and terminal create new connections
- The log no longer shows get empty name, <invalid>, or interface not found
- The Connections page shows the expected domain, rule, and proxy or direct egress
- After disconnecting and reconnecting the same hotspot, the interface name still matches the override
- Direct system connectivity returns immediately after TUN is disabled without restarting the Mac