On this page
TUN addresses programs missed by the system proxy
On Windows, Clash Verge Rev TUN is useful when Chrome and Edge already work through the system proxy, but terminals, game launchers, or store apps show no connection records. If no program works, address the subscription or node first; do not make TUN the first toggle.
The system proxy and TUN are not two speed tiers. The system proxy only tells programs willing to read it about the Windows proxy address; TUN uses a virtual adapter to capture more TCP and UDP connections.
After these connections enter Mihomo, rules still determine direct access or proxying. TUN expands capture scope; it does not repair a dead node or correct a bad rule automatically.
Choose an entry point based on the symptom
| Current behavior | Next step |
|---|---|
| The browser and common software work | Continue using the system proxy; there is no need to enable TUN |
| The browser works, but the terminal or launcher connects directly | Use TUN for one comparison |
| Nothing works, whether or not the system proxy is enabled | Address the subscription, node, or core first |
| Only one domain uses the wrong outbound route | Inspect the rule match; TUN is not the focus |
Preserve a working system-proxy state
Before enabling TUN, select the current subscription under “Configurations,” pin one verified node on the “Proxies” screen, and keep the mode on Rule. Enable the system proxy, visit a familiar website, and confirm on the “Connections” screen that the request appears.
This step preserves a fallback. If the system proxy already has no connection records, the subscription may not be current or the policy group may still be on DIRECT. Enabling TUN immediately only hides the original problem behind the virtual adapter.
Before opening TUN settings, you should see
- The current configuration has a clear update time
- The proxy screen shows policy groups and nodes
- The fixed node can complete one web request
- Connection records show the domain, rule, and actual outbound route
Service mode handles permissions; it does not choose a node for you
Creating a virtual adapter on Windows requires elevated privileges. Clash Verge Rev delegates that work to service mode so the entire interface does not need to run as administrator every day. Find “Service Mode” in settings; if it shows as not installed, use the client's built-in installation action.
When Windows requests elevation, the initiating program should come from the installed Clash Verge Rev. Reload the core after the service installs. If status keeps switching between “Stopped” and “Starting,” inspect the log before repeatedly clicking the TUN toggle.
Enable TUN with the configuration you just verified
Switch from a working state
Quit other proxies and VPN software
Prevent multiple programs from changing routes or occupying the same port.
Keep Rule mode and a fixed node
Do not let an automatic benchmark group switch outbound routes during the test.
Enable TUN mode
Wait for the service and virtual adapter to become ready; do not change DNS and rules at the same time.
Repeat the action that previously failed
For example, run the same terminal command or open the same page in the launcher.
Current Mihomo supports network stacks including system, gvisor, and mixed. Keep the client default if it works; changing stack is a compatibility diagnostic, not a performance toggle. If system or mixed connections are blocked, also check whether Windows Firewall allows the Mihomo core process.
auto-route sends matching system traffic into TUN, while auto-detect-interface identifies the real outbound adapter. Understanding these fields helps with logs, but graphical-client users do not need to copy a large online configuration for “optimization.”
An illuminated toggle is not completion; connection records are
Return to the program that failed under the system proxy and repeat the exact same request. If the “Connections” screen now shows the domain or target IP along with its rule and outbound route, traffic entered Mihomo through TUN. The setup truly works only if the app also receives a result.
If connection records remain empty, focus on whether the program's traffic crosses the virtual adapter and whether the firewall blocks it—not subscription latency. If a record appears but matches DIRECT, fix the rule. If it matches a proxy but times out, compare with another known-good node.
The app fails, and the connections screen has no new record
Check service status, the virtual adapter, other VPN software, and Windows Firewall.
A record appears but shows DIRECT
Inspect the matched rule line; do not repeatedly toggle TUN instead of fixing the rule.
A record uses the proxy and shows timeout
Pin another working node to distinguish an entry-path issue from a node issue.
If everything fails after enabling TUN, return to the system proxy and define the boundary
Disable TUN first. If the system proxy immediately works again, the subscription and node probably still function and the issue is confined to the service, routing, virtual adapter, or DNS. If the system proxy also fails, recheck the configuration and core you just verified. This comparison is faster than reinstalling the client.
- Service fails to start
- Reload the core and inspect logs for permission, service, or driver messages.
- A virtual adapter exists, but no requests appear
- Quit other VPN software, security software, or an old Clash process; confirm that a second TUN is not also changing routes.
- Connections appear, but domain resolution fails
- Inspect DNS logs and dns-hijack settings. Advice about Android Private DNS does not apply to Windows; do not combine tutorials.
- It fails only after changing Wi-Fi
- Have the core detect the outbound adapter again, then inspect the auto-detect-interface result.
If NAS devices and printers suddenly disappear, check whether local subnets are being routed away
If external access has recovered but the router admin page, NAS devices, or printers are unreachable, local connections probably entered TUN without matching direct local-network rules. If these devices return immediately after disabling TUN, that also supports the diagnosis.
Confirm that private-address rules match DIRECT before a broader proxy rule. If the corporate network uses custom subnets and internal domains, add its real addresses instead of copying a home-network exclusion list. strict-route on Windows may also affect virtual networks such as VirtualBox, so validate virtual machines separately.
Information needed to restore local-network access
- Actual IP and subnet of the unreachable device
- The rule matched by that connection in Clash
- Whether corporate internal DNS works only on the current network
- Whether VirtualBox, Hyper-V, or another virtual adapter also exists
When rolling back, undo only the TUN layer
Disable TUN, keep the verified configuration and node, then enable the system proxy. If networking recovers immediately, there is no reason to use Windows “Network reset.” That action clears Wi-Fi, virtual adapters, and other network settings together—far more than the current issue requires.
Service mode itself can remain; it is only the permission layer. If you are certain you will not use it again, remove it through the uninstall action in client settings. After returning to the system proxy, the browser should work normally, while programs that depended on TUN again show no connection records. That difference directly reveals whether TUN is necessary.
If the target program enters Connections only under TUN and the network, DNS, and local network all work, keep TUN. When the system proxy already covers everyday programs, leaving TUN off is simpler.