How to Install Clash Verge Rev on Windows: System Proxy, TUN, and Firewall Troubleshooting

Get the system proxy working first, then enable TUN

For a first-time Clash Verge Rev setup on Windows, follow this order: install the client → import a configuration → choose a policy → verify the system proxy → install the service → enable TUN. Don’t change DNS, routing, and firewall settings all at once. Change one thing at a time so you can pinpoint where a problem starts.

Clash Verge Rev manages configurations, the system proxy, and the user interface. The mihomo core parses configurations, matches rules, and establishes proxy connections. A subscription provides configuration data such as nodes and rules. A successful client installation doesn’t mean the subscription works, and a node showing a latency value doesn’t mean every app is using the proxy.

Choose an installer by system architecture, not CPU brand

1. In Windows, open Settings → System → About and check “System type.” In Windows 10, this page is usually called “About.”
2. If it says “x64-based processor,” choose the x64 installer. AMD64 is another name for the x64 architecture, and x64 Intel processors are supported too.
3. If it says “ARM-based processor,” choose the ARM64 installer if the project provides one. Don’t infer the architecture from the device brand alone.
4. Check the platform options on the client downloads page. Fully exit any existing client before installing to prevent two cores from competing for the same port.

First launch and runtime requirements

Complete the setup wizard, then launch the client as a standard user. If you see a specific message that the WebView2 Runtime is missing, install it as directed by the installer or get it from an official Microsoft source. A blank window can also result from graphics rendering issues or security software interference; it doesn’t, by itself, mean the subscription is invalid.

If Windows displays a warning about the app’s source or publisher, verify where you downloaded it and check the installer details. Don’t disable system protections just to install the app. After installation, note the client and core versions in Settings. When reporting an issue, providing both is more useful than simply saying you have the “latest version.”

Import a subscription and confirm the mode

On the client’s Subscription page, paste the subscription URL and import it, or import a local YAML file. After importing, select the configuration to make it active. Seeing its name in the list doesn’t mean the core has switched to it.

1. Check the update results and runtime logs for YAML parsing errors, invalid field types, or nodes that failed to load.
2. Open the Proxies page and start in Rule mode. Check which nodes are selected in commonly used proxy groups, and make sure you haven’t accidentally selected DIRECT or REJECT.
3. Test the latency of candidate nodes. If a test times out, investigate the node and network rather than blaming the Windows Firewall straight away.
4. Open a site that should use the proxy, then check the matched rule and policy chain on the Connections page.

Rule mode evaluates rules in rules order. Global mode uses the GLOBAL policy. Direct mode won’t use a selected node automatically. For comparison, you can briefly switch to Global mode while troubleshooting. Once the test is done, restore the intended mode and check the specific rule.

System proxy not working? Check the port and request path first

The system proxy is a good first test with browsers and other apps that follow Windows proxy settings. It doesn’t route all system traffic: some games, command-line tools, and apps with their own network settings won’t use it automatically. A standard HTTP system proxy also doesn’t handle all UDP traffic.

Check 127.0.0.1 and the actual mixed port

First, check the mixed port in the client’s settings, then enable “System proxy.” The example below uses 7897 for diagnosis. If the client shows 7890 or another port, replace the value in the command. Don’t change your port just to match the example.

# Check the local listening port in PowerShell
Test-NetConnection 127.0.0.1 -Port 7897

# Check the current user's Windows proxy settings
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

# Check the listening process; the last column shows the PID
netstat -ano | findstr LISTENING | findstr :7897

TcpTestSucceeded : True only confirms that the local port is reachable; it doesn’t mean the remote node is working. If the result is False, first check whether the core is running, the configuration loaded, and another program is using the port. In Task Manager, find the process by PID under Details. Don’t terminate an unknown system process.

Use an explicit proxy request to isolate the problem

# Specify an HTTP proxy explicitly to avoid differences in how apps use system settings
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

This uses curl.exe to avoid PowerShell environments that resolve curl to a different command. The request still follows the core’s Rule mode, so check the Connections page to confirm it used a proxy rather than a direct connection. An HTTP response means this request path responded; it doesn’t mean every site is reachable.

• Explicit proxy works, but the browser doesn’t: Check browser extensions, custom proxy settings, and whether another app changed the settings under Windows Settings → Network & Internet → Proxy.
• Explicit proxy fails, but the local port is reachable: Check the proxy group, node authentication, remote connection, and core logs. Don’t keep toggling the system proxy.
• The browser works, but one app doesn’t: Check whether the app follows the system proxy. If needed, configure a proxy in the app or test with TUN.

netsh winhttp show proxy shows the WinHTTP proxy state, not the Windows proxy settings used by the current user’s browser. Seeing “Direct access” doesn’t, by itself, prove that Clash Verge Rev’s system proxy is broken. Don’t change the machine-wide WinHTTP configuration based on this result alone.

Install the TUN service: check the service first, then routing

TUN routes traffic through a virtual network interface, making it useful for apps that ignore system proxy settings. It requires appropriate permissions and can conflict with other VPNs, virtual adapters, or enterprise network policies. TUN won’t fix a broken node: if a node already fails with the system proxy, enabling TUN usually won’t make it work.

1. Close other proxy clients and third-party VPNs, then note whether your network works normally without a proxy.
2. In Clash Verge Rev, open Settings and find Service Mode and its install or management option. Install the service as prompted and approve the Windows User Account Control prompt.
3. Make sure the interface shows that the service is available, then enable “Virtual Network Mode” or “TUN Mode.” If the service status is abnormal, fix the installation issue first instead of repeatedly toggling TUN.
4. To isolate variables, temporarily disable the system proxy and leave only TUN enabled. Open the target app and check Connections and Logs for its traffic.

Understand the TUN fields

This is a sample of common mihomo TUN fields, not a complete configuration with nodes, proxy groups, and rules. Clash Verge Rev may generate these fields through runtime overrides. Prefer the client’s settings and check the effective configuration. Don’t append this whole block to the end of a subscription; doing so may create duplicate tun keys.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

• auto-route sets routes automatically. After enabling it, confirm that traffic is actually reaching the core.
• auto-detect-interface detects the outbound interface automatically. If multiple adapters, a hotspot, and a VPN are in use, check the detected interface in the logs.
• any:53 under dns-hijack intercepts matching traditional DNS requests. It doesn’t convert all encrypted DNS over HTTPS requests into regular DNS.
• stack support and behavior depend on the core and platform. Don’t keep switching network stacks without evidence in the logs.

If enabling TUN cuts off all network access, disable it first to restore connectivity. Then check the outbound interface, DNS settings, and routes from other VPNs. If the problem starts after waking from sleep or switching from Ethernet to Wi-Fi, check the interface and service status before considering a system reinstall.

UWP apps can’t connect? Check loopback restrictions and proxy bypass

Apps such as Microsoft Store may use an app-container networking model that restricts loopback access. If an app tries to use a local proxy at 127.0.0.1:7897, it may fail to connect even when a regular browser works. Not every app installed from the Store uses the same networking model, so don’t assume they’re all UWP apps.

Two ways to troubleshoot

• Keep using the system proxy: If your version includes a tool to exempt UWP apps from loopback restrictions, grant access only to the apps that need it. If there’s no such option, use built-in Windows tools to investigate. Don’t download bulk-edit scripts from untrusted sources.
• Route traffic through TUN: Disable the system proxy and test TUN on its own. Check whether the app’s connection appears in the core. TUN changes the traffic path, but it doesn’t replace checks for app authentication, DNS, or server-side errors.

# List existing app-container loopback exemptions in an elevated terminal
CheckNetIsolation.exe LoopbackExempt -s

This command only lists existing exemptions; it doesn’t remove restrictions for every app. To add one, first use Get-AppxPackage to find the target app’s package family name, then follow the tool’s help to make the precise change. Only modify affected apps; don’t treat “exempt all” as a general optimization.

If the app still fails with TUN, check whether its connection appears in the client. If there’s no connection at all, investigate the traffic routing path first. If a connection appears but returns an authentication or region error, check the account, egress location, and service requirements instead of assuming a loopback restriction.

Troubleshoot the firewall without disabling protection

A standard local proxy listens on 127.0.0.1; you don’t need to expose the mixed port to your entire LAN to access the internet. Only enable LAN access, change the listening address, or add inbound rules if other devices need to connect to this proxy. Restrict access to the intended network.

Press Win + R, enter wf.msc, and open “Windows Defender Firewall with Advanced Security.” First check Outbound Rules for any block rules targeting the current client or core, then review your security software’s logs. Windows commonly allows outbound connections by default, but organization-managed PCs may use different policies. Contact your administrator for help.

If Windows asks whether to allow an app through the firewall, don’t automatically check every network type. Grant access for its actual purpose. Using a proxy on your own PC doesn’t mean other devices need inbound access over public Wi-Fi. Don’t expose the core’s controller API to fix ordinary web access.

Final checks and restoring connectivity after exit

After installation, follow a consistent checklist rather than relying on the system tray icon. Start with one known-good node and one traffic-routing method. Once everything is stable, add complex rules or extra overrides.

1. Check the configuration: The intended subscription is selected, the core logs show no persistent errors, and proxy groups aren’t mistakenly set to Direct or Reject.
2. Check the traffic: Open a site that should use the proxy and confirm the rule and policy chain under Connections. An IP lookup is only a secondary check, since the lookup request itself might match a direct rule.
3. Check the apps: Test both a browser and the app that failed before. A working browser doesn’t mean every app is fixed.
4. Check after exit: Turn off the system proxy and TUN before exiting the client normally. Confirm that regular network access is restored.

Client has exited, but Windows still points to the local proxy

If the client exits unexpectedly and Windows still points to a 127.0.0.1 proxy with no process listening on that port, apps that follow system proxy settings will fail. Open Windows Settings → Network & Internet → Proxy and check the “Use a proxy server” setting under Manual proxy setup. Disable it only after confirming the address belongs to the client that has exited. Don’t remove proxy settings or setup scripts required by your organization.

If the problem occurs only after TUN exits, restart the client, turn TUN off normally, and check whether the virtual adapter and routes have been restored. Don’t bulk-delete adapters, clear the routing table, or reset all network settings; these actions can affect other VPNs and enterprise networks.

For more help tuning fields, see the YAML configuration manual. Get a minimal configuration working with just one traffic-routing method, then gradually restore custom DNS, routing rules, and other network tools. This is usually easier to troubleshoot than enabling everything at once.