On this page
Confirm that the logs show a TUN loopback storm
This article addresses one specific set of Windows symptoms: the Clash Verge Rev system proxy works until TUN is enabled, then the log repeatedly shows reject loopback connection, verge-mihomo.exe repeatedly fails to dial the node, CPU usage rises sharply, and in severe cases the core reports thread exhaustion and crashes.
Official issue #7764 documents this failure chain in service mode with Clash Verge Rev v2.5.2 and Mihomo v1.19.29 and v1.19.30. The reporter ultimately found that automatic detection had selected the v2rayN Wintun virtual adapter. After the real Ethernet interface was pinned manually, the loopback logs, abnormal CPU use, and thread exhaustion all stopped.
This is a confirmed result from a computer with several virtual adapters; it does not mean every TUN timeout is caused by interface selection. If the log does not contain reject loopback, or if the system proxy also fails after TUN is disabled, troubleshoot the subscription, node, DNS, or service mode first.
Use three signals to narrow the problem
| Signal | Behavior in this issue | If it does not match |
|---|---|---|
| Trigger | Starts within seconds of enabling TUN | If the system proxy also fails, inspect the shared path first |
| Main log pattern | verge-mihomo.exe dials the node and repeatedly reports reject loopback | A timeout limited to ordinary apps is not the same failure |
| Resource behavior | CPU rises quickly and thread exhaustion may appear | If resource use stays stable, branch from the first error instead |
- verge-mihomo.exeDial the current proxy node
- Incorrectly selected virtual adapterauto-detect-interface does not use the real physical egress
- Mihomo TUNThe core's own dial attempt enters TUN again
- Loopback detection and retryContinuous reject loopback causes CPU use and thread count to rise rapidly
After pinning the outbound interface to the physical adapter used by the current default route, the core's dial attempts no longer reenter its own TUN. The loopback logs and resource storm should stop together.
Turn off TUN and restore system stability first
When the logs start repeating rapidly, turn off TUN first. Do not switch nodes, change DNS, or repeatedly reload the core at the same time. After CPU usage falls, keep the original Profile and node, enable the system proxy, and load one webpage. If the system proxy recovers, the subscription and node still have a working baseline, which points more strongly to TUN egress selection.
If the UI has frozen, close Clash Verge Rev normally from Task Manager, then confirm that the Windows system proxy is no longer pointing to a stopped local port. After direct connectivity is restored, export the app log, active configuration, and adapter list. Remove the subscription token, node addresses, and passwords from the configuration copy.
Establish a rollback-ready troubleshooting baseline
Disable TUN
Stop new loopback dial attempts and wait for CPU usage and log writes to return to normal.
Validate the system proxy
Keep the original Profile and node unchanged, enable only the system proxy, and make one new request.
Save the current Merge
Copy the active override and final configuration; from this point, change only the two outbound-interface fields.
Keep the first log segment
Record the client, core, and Windows versions, plus redacted content around the first reject loopback entry.
Identify the physical adapter that is actually online
With TUN still disabled, use PowerShell to view visible adapters and the IPv4 default route together. The Name from Get-NetAdapter is the interface name you will enter later; Get-NetRoute shows which adapter currently carries the default egress. A wireless connection may be named Wi-Fi, while a wired connection may be named “Ethernet”; use the values from your own computer.
Get-NetAdapter -Name * |
Format-Table Name, InterfaceDescription, Status, LinkSpeed, ifIndex
Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
Sort-Object RouteMetric |
Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetricEliminate incorrect candidates from the results
| Result | Interpretation |
|---|---|
| Status is Up, and the default route uses the same InterfaceAlias | Prefer it as the current real-egress candidate |
| The name or description contains Wintun, TAP, VMware, or VirtualBox | If it is a virtual adapter, do not choose it based only on LinkSpeed |
| The adapter is Up but has no current default route | It may serve only a virtual machine, VPN, or the LAN |
| Both Wi-Fi and a wired connection have default routes | Disconnect the unused one first, then confirm the actual egress again |
Compare automatic detection with the default route
Open the active configuration you saved and the log from this launch. Confirm whether auto-detect-interface is enabled and find the outbound interface Mihomo actually selected. The root cause matches the official issue only if the system default route uses physical Wi-Fi or a wired adapter while the log shows node dialing bound to a Wintun, TAP, or VMware interface.
Do not decide based on a virtual adapter's advertised speed. In the #7764 environment, vgate0 reported 100 Gbps, which caused automatic detection to choose the wrong egress. Add an override only after the interface evidence agrees. If you cannot find the selection result, send the adapter list and first log segment to the project maintainers instead of guessing a name.
The default route uses the wired connection, but the runtime log uses vgate0
This matches incorrect interface selection; proceed with the minimal override.
The default route and Mihomo both use the same physical adapter
This does not match the known root cause; stop applying this article's configuration.
The log contains only dns resolve failed
Troubleshoot the DNS path first; do not treat it as reject loopback.
The failure disappears after the other VPN is disabled
Record the conflicting software and adapter; there is no need to pin the interface.
Pin only the outbound interface in Merge
The official Mihomo configuration defines interface-name as the top-level outbound interface and places auto-detect-interface under tun. Open Merge or the override for the current Profile and add only these two fields. Do not copy the entire TUN and DNS configuration from the issue, and do not put the physical adapter name in tun.device.
interface-name: "以太网"
tun:
auto-detect-interface: falseKeep the change minimal
Confirm that the interface name matches exactly
Match spaces, hyphens, and language exactly; do not substitute InterfaceDescription for Name.
Save and validate the configuration
interface-name is at the top level, and auto-detect-interface is indented by two spaces only under tun.
Leave all other fields unchanged
Keep the original node, rules, DNS, stack, and strict-route so you do not introduce a second variable.
Restart the core completely
Confirm that the new runtime configuration contains both override values, then run one controlled TUN test.
Validate the interface fix with one controlled test
After restarting the core, open the log before enabling TUN. Keep the test window visible and make one ordinary HTTPS request. If reject loopback starts appearing rapidly again, disable TUN immediately. A real fix must improve the logs, CPU use, core uptime, and actual connectivity together; an enabled TUN switch alone is not proof.
After pinning the physical Ethernet interface, the reporter on the official issue confirmed that the loopback storm disappeared completely, CPU usage returned to normal, and neither v1.19.29 nor v1.19.30 exhausted its threads. Upstream issue #3122 was then closed without requiring a Mihomo core change, so this case should not be described as fixed by a newer core release.
Completion criteria for the interface fix
- No new reject loopback connection entries after enabling TUN
- verge-mihomo.exe CPU usage remains stable in Task Manager
- The core keeps running without thread exhaustion or repeated reload
- The same node completes a new HTTPS request and the connection appears in the records
- Direct system connectivity returns immediately after TUN is disabled
Handle any remaining DNS errors separately after the loop stops
After the interface issue was fixed, #7764 also exposed a separate DNS configuration error, including a bootstrap loop involving a DoH domain. A maintainer also corrected the reporter's early conclusion about proxy-server-nameserver. Do not copy the issue's DoT, nameserver-policy, or full DNS example into your own configuration.
If reject loopback is gone and CPU usage is normal but webpages still report dns resolve failed, keep the validated interface override and compare domain resolution with direct access on the same node. Change the relevant upstream or policy only when the DNS evidence is clear, so the two separate failures do not become mixed together again.
The next error after fixing the interface
| Symptom | Action |
|---|---|
| Connection records contain domains, and node dialing works | The interface issue is resolved; continue validating the actual workload |
| Only dns resolve failed appears | Check the DNS upstream, bootstrap path, and proxy-server-nameserver |
| reject loopback still appears | Disable TUN and recheck the actual interface name and runtime configuration |
| Configuration validation fails | Remove the override and check the top-level fields and YAML indentation |
Update the interface after changing networks; fully roll back if it stops working
After automatic detection is disabled, Mihomo keeps using the manually selected adapter. When you switch from a wired connection to Wi-Fi, a mobile hotspot, or a USB adapter, the old interface may no longer carry the default route. If TUN fails again after a network change, disable TUN and repeat the read-only checks; do not keep an obsolete interface name across every network.
Restore the original state if the override does not work
Disable TUN
Confirm that direct Windows connectivity is restored before editing Merge.
Remove the two fields
Delete the top-level interface-name and the tun.auto-detect-interface added in this procedure.
Reload the original Profile
Use the system proxy to confirm that the original subscription, node, and rules still work.
Retain redacted evidence
Submit the actual adapter list, the first error, and the runtime-configuration diff without exposing the subscription or node credentials.
Six checks to confirm Windows TUN has recovered
Final validation checklist
- The system proxy works, and the original request still completes after TUN is enabled
- The new log contains no reject loopback, thread exhaustion, or core-replacement loop
- interface-name in the runtime configuration matches the interface used by the current default route
- CPU usage and thread count do not keep rising after observation in Task Manager
- When switching nodes or creating a new connection, the Connections page shows the expected rule and egress
- Normal Windows networking can recover after TUN is disabled and the client exits