On this page
If enabling virtual-adapter proxying makes the computer busy with repeated errors, stop triggering the failure rather than waiting for the client to recover by itself. Check whether the original system proxy works, whether logged connection attempts loop back, and which adapter is actually used. Set the outbound interface to the real network adapter only when the evidence matches.
reject loopback and rising CPU after enabling TUN
Compare the previous connectivity state with the logs: on Windows, the Clash Verge Rev system proxy worked, but enabling TUN produced repeated reject loopback connection errors, failed verge-mihomo.exe connection attempts, and rising CPU usage. Severe cases show thread exhaustion and a core crash. Stop triggering the failure if this pattern appears.
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 result was confirmed on a computer with multiple virtual adapters; it does not mean that every TUN timeout is caused by interface selection. If the logs contain no reject loopback, or the system proxy also fails after TUN is turned off, check the subscription, node, DNS, or service mode first.
- 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 setting the outbound interface to the physical network adapter used by the current default route, the core’s connections no longer loop back into its own TUN. Loopback logs should stop, and CPU usage and thread counts should return to normal.
Check the original node and system proxy with TUN off
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 interface is frozen and cannot quit normally, use Task Manager to end Clash Verge Rev. Then check the Windows system proxy so it does not keep pointing to a stopped local port. Ending the GUI does not prove that TUN or the service has stopped. Restore direct access before exporting logs, the runtime configuration and adapter list; redact subscription token values, node addresses and passwords in public copies.
Restore the connection and keep override records
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.
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 usage is stable, investigate the cause indicated by the first error |
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 |
Did automatic detection choose a virtual adapter for outgoing traffic?
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
- Normal Windows networking can recover after TUN is disabled and the client exits
- interface-name in the runtime configuration matches the interface used by the current default route
- When switching nodes or creating a new connection, the Connections page shows the expected rule and egress
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 correct interface is selected; now check that connections work normally |
| 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 |
Select the outbound interface again after switching networks; undo the interface override if it does not help
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.
Restore the original state of both fields
Use the saved Merge to restore the original values of interface-name and tun.auto-detect-interface. Delete a field only if it was absent before this change; retain all other TUN overrides.
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.
References
- Clash Verge RevResolution of Windows TUN reject loopback caused by incorrect interface selection
- Mihomo WikiMihomo TUN and auto-detect-interface configuration
- Microsoft LearnWindows Get-NetAdapter command reference
- Clash Verge RevClash Verge Rev Windows service local privilege-escalation advisory GHSA-99qg-xv7m-jf4v