How to Enable TUN Mode in Clash Verge Rev on Windows

1. What TUN Mode Changes on Windows

Clash Verge Rev can send traffic to the proxy core in more than one way. With the Windows system proxy enabled, applications that honor the system proxy settings can send their web requests to Clash. Some command-line tools, games, launchers, and background services ignore those settings, however. TUN mode adds a virtual network interface and uses Windows routing to capture more device traffic, including connections from many applications that do not use the system proxy.

TUN does not turn every connection into a proxy connection by itself. It provides another path for traffic to reach the core; the active configuration still decides whether a captured connection goes to a proxy, connects directly, or is rejected. In Rule mode, the core evaluates the configured rules in order. In Global mode, it generally sends eligible traffic through the selected global policy. The policy group must contain a usable proxy if you expect internet traffic to leave through a proxy.

• System proxy: A Windows setting used by compatible applications. It is usually simpler to enable, but it does not capture every program.
• TUN mode: A virtual adapter and routing mechanism that can capture more device traffic. It needs the core, Windows networking, and the required permissions to work together.
• Rules and policies: Decide what happens after traffic reaches the core. Enabling TUN does not replace them or guarantee that every destination uses a proxy.

The exact labels and layout can differ between Clash Verge Rev releases, language settings, and bundled core versions. Treat the steps below as a way to locate and verify the relevant controls, not as a claim that every build uses identical menu names. If a setting is missing, check the installed client version, selected core, and the client’s service or permission status before editing a subscription configuration.

2. Check the Client, Core, and Windows Permissions

Start with the active application and core rather than assuming that the desktop shortcut identifies the runtime components. Clash Verge Rev is the interface and service manager; the selected core handles configuration parsing, traffic capture, DNS, rules, and outbound connections. TUN support depends on the core build and how the client launches it. Record the client version, core name, and full core version from the application’s information screen or startup logs.

1. Confirm that a configuration is active. Start a known working profile and check that the core reaches its running state. TUN cannot route through a profile that fails to parse or has no usable outbound policy.
2. Check the core choice. If the configuration uses mihomo-specific fields, confirm that the selected core supports them. An interface option can be visible even when a particular core build cannot apply the requested configuration.
3. Check service and permission status. Look in the client’s settings for its service, administrator, or system integration controls. Some setups need an elevated service to create or manage the virtual adapter. Follow the prompt provided by the installed build; do not assume that repeatedly launching the whole client as administrator is the only supported method.
4. Check security prompts. Windows may display a User Account Control prompt when a privileged service or network component is installed or started. Approve it only when it was triggered by the Clash Verge Rev installation or action you intended to perform.
5. Close competing network tools for the first test. Another VPN, packet capture tool, virtual machine network, or security product may install routes or filter traffic. Temporarily disable only software you recognize and can safely restore.

On Windows, the TUN implementation commonly relies on a virtual adapter such as Wintun, but the exact component and installation path depend on the client and core build. Do not download a driver from an unrelated source just because an adapter is absent. Use the client’s supported installation or service controls, and check Windows Device Manager for a warning icon if the adapter was created but is not functioning.

It is also useful to separate permission problems from configuration problems. A message about creating a device or opening a network interface points toward service permissions, driver installation, or a conflict with another network component. A YAML parsing error or an unknown field points toward configuration compatibility. A connection timeout after the core starts is a later stage and should be diagnosed through the active rules, DNS behavior, and proxy node.

3. Enable TUN Mode in Clash Verge Rev

Once the profile is running and the required service is available, enable TUN from the client interface. In many builds, the control is under Settings and is labeled TUN Mode or simply TUN. Some releases expose additional options on the same page, while others use a system service prompt or a separate service-management control. If your screen differs, search the settings for “TUN” and read the nearby status text before changing options.

1. Open Clash Verge Rev and select the configuration you intend to use. Confirm that it is active and that the core has started without a configuration error.
2. Open the client’s settings and locate the TUN control. Check any displayed notice about administrator access, service installation, or a required restart.
3. If the client asks to install or start its service, approve the request through the client’s own prompt. If Windows asks for confirmation, verify the application name and the action before accepting.
4. Turn on TUN. Wait for the status to change to enabled or for the core log to show that the virtual interface and TUN listener started successfully.
5. Keep the existing routing mode and rules for the first test. Changing TUN, DNS, the system proxy, and rule mode together makes it harder to identify which change affected connectivity.
6. Test one application that ignores the system proxy, then check the client’s connection list or logs for the destination, matched rule, policy, and outbound.

Do not add a second copy of a TUN section to a subscription simply because the interface toggle did not work. Clash Verge Rev may generate or merge runtime settings, and a subscription can be refreshed later. First inspect the effective configuration or startup log and use the client’s supported override mechanism if a core option genuinely needs to be changed. The interface toggle, generated runtime configuration, and core-supported fields must agree.

Leave advanced options at their defaults during the initial test unless the client reports a specific requirement. Options related to the stack, DNS hijacking, address ranges, or route exclusions can change how traffic is captured. A setting that is appropriate for one network may conflict with another VPN, a corporate route, or a local virtual machine. Make one change at a time and record its original value.

4. Verify the Virtual Adapter and Test Traffic

A toggle that appears enabled is useful evidence, but it does not prove that an application’s traffic is reaching the core. Verify the setup at three levels: Windows creates or activates the adapter, the core reports a successful TUN startup, and a test connection appears in Clash Verge Rev. This separates an adapter startup issue from a routing or proxy issue.

Check the adapter in Windows

Open Settings > Network & internet > Advanced network settings and inspect the network adapters. Depending on the Windows version and core, the adapter name may refer to TUN, Wintun, or the client. It may not use the exact same display name on every installation. You can also open Device Manager, expand Network adapters, and check whether a related virtual adapter is present and free of a warning symbol.

Do not judge the setup by whether the adapter receives a familiar gateway or by comparing its address with your physical Wi-Fi or Ethernet address. Virtual interfaces can use addresses and route metrics that are specific to the implementation. The more useful checks are whether the adapter is enabled while TUN is on, whether the core log reports successful initialization, and whether the expected connections appear in the client.

Run a controlled test

1. Choose one application known not to follow the Windows system proxy, and note its destination before testing.
2. With TUN enabled, generate one request and wait several seconds. Check the connection view for the destination and the selected rule or policy.
3. If the connection appears, confirm that the selected outbound is the one you expect. A connection routed to DIRECT is captured but not sent through a proxy.
4. Compare with TUN disabled only if it is safe to do so. The difference can confirm whether the application relies on the TUN path.

For a simple diagnostic, keep the test narrow: one application, one destination, and a short log window. In Rule mode, inspect the first matching rule and the final policy; in Global mode, confirm the selected global outbound. If the connection is absent, investigate capture and route setup. If it is present but fails, investigate DNS, the matched rule, the outbound group, and the proxy node. Those are different failure paths.

5. Troubleshoot Startup and Connectivity Problems

If enabling TUN makes networking fail, avoid resetting all Windows network settings as a first response. Turn TUN off from Clash Verge Rev if the control still works, restore the previous system proxy setting if it changed, and restart the core once. Then use the error and the layer where it appears to choose the next check.

• The toggle switches off immediately: Check the client’s service status, Windows permission prompts, and the core startup log. A service that is not installed or cannot start can prevent the interface from being created.
• The log reports a device or interface creation error: Confirm that the selected core supports TUN and that the client has permission to manage the virtual interface. Check Device Manager for an existing adapter with an error state, and look for conflicts with another VPN or network filter.
• The adapter exists but traffic is not captured: Check whether the client reports TUN as active, whether the application is excluded by a route or process setting, and whether another VPN has installed a competing route. Compare one test connection with TUN on and off.
• Connections appear but websites fail: TUN capture is likely working, so inspect the matched rule, selected outbound, DNS result, and node availability. A rule that sends the request to DIRECT will not use the proxy, even though TUN captured it.
• Only some applications fail: Check whether the application uses UDP, a custom DNS resolver, local network access, or a connection excluded by the client’s routing options. Avoid assuming that every application uses the same transport or name-resolution path.
• Local devices or corporate resources stop working: Check local subnet routes, DNS, and any supported bypass or exclusion controls. Change only the specific route or domain behavior needed, and preserve the original values so they can be restored.

When reviewing logs, capture the time of one reproduced request and include the core’s startup messages around TUN initialization. The exact wording varies by core version, so keep the complete error line rather than searching for a single phrase. Before sharing logs, redact subscription URLs, node passwords, authentication tokens, controller secrets, and personal hostnames. Preserve the error type, relevant port, core version, and rule outcome because those details help distinguish an access problem from a routing problem.

Once the test succeeds, leave only the settings you need. If applications that honor the system proxy work without TUN, you can keep TUN off and enable it only when broader capture is necessary. If you rely on TUN, confirm after a client or core update that the service still starts, the adapter appears, and the expected traffic reaches the core. A successful toggle is not a substitute for checking the route and outbound used by real applications.