On this page
If your Mac connects directly through a phone hotspot but cannot load pages with TUN enabled, the later DNS error may follow from a missing outbound adapter. Keep the startup logs and use the system routes to identify the adapter carrying hotspot traffic before deciding whether a temporary fixed interface is appropriate.
Direct hotspot access works, but TUN logs show an empty interface
On an Intel Mac connected to an iPhone personal hotspot, compare with Clash Verge Rev TUN off and on to confirm whether direct access works while proxy access fails. Official issue #7576 used client v2.5.2 and Mihomo v1.19.29; other Mac setups should proceed only if 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.
- 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.
Use the logs to choose interface or permission checks
| 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 |
Set the outbound adapter in Merge and disable automatic adapter detection
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.
After restarting, check interface errors, DNS, and pages
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
Using the same node, make a new DNS query and HTTPS request. Check whether the connections page shows the corresponding domain, rule, and actual exit.
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.
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
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.
Steps to undo this interface override
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.