Before You Install: Check Your System Architecture and Configuration Source
On Windows, install Clash Verge Rev in this order: launch the client → import a subscription → verify the system proxy → set up service mode → enable TUN. Don’t turn on every option the first time you launch it. Get a proxy connection working first, then tackle apps that don’t use the system proxy. This makes problems much easier to isolate.
Clash Verge Rev is a desktop management interface. The mihomo core, also known as Clash Meta, handles connections and rules. A successful installation only means the app is in place; it doesn’t mean you have usable nodes. You’ll also need a core-compatible configuration or a Clash-format subscription from your service provider.
Choose an Installer for Your Processor Architecture
- Press Win + I to open Windows Settings, then go to “System” → “About” and check “System type.” In some Windows versions, this page may be called “System information.”
- For most 64-bit Intel or AMD PCs, choose the Windows x64 installer. For devices with an ARM processor, choose the ARM64 package offered on the release page.
- Make sure the release supports your version of Windows. A filename that includes “Windows” doesn’t guarantee support for older versions, and x64 packages won’t work on 32-bit systems.
- Run the installer and follow the setup wizard. If you already have an older client, exit it first to prevent both clients from competing to control the system proxy.
First Launch: How to Handle the Windows Firewall Prompt
When the core starts for the first time, Windows may ask whether to allow the app through the firewall. The prompt may name the client or the core that listens on the port. Check that the program path points to the directory where you just installed it before choosing a network scope. A similar name isn’t enough to verify the app.
Local Proxy Access Is Not the Same as LAN Sharing
- For this PC only: Leave “Allow LAN” off and bind the proxy listener to the loopback address. A normal local loopback connection doesn’t require opening an inbound port to your LAN.
- To share with phones or other PCs: Enable LAN access and add an inbound rule for trusted private networks. Don’t enable it on public networks by default.
- On a managed device: Administrator policies may restrict core network access, service installation, or virtual adapter creation. Check with your administrator instead of turning off the firewall entirely.
If you clicked “Cancel” by mistake, go to “Windows Security” → “Firewall & network protection” → “Allow an app through firewall” and check the entries. To review rules by program path, port, or remote address, search the Start menu for “Windows Defender Firewall with Advanced Security” and inspect the relevant rule’s scope. The allowed-app list mainly concerns inbound access; a checked box alone doesn’t prove outbound connections will work.
If the installation directory or core path changes after an upgrade, an old rule may no longer match. Change only the rule you’ve confirmed is causing a problem. Don’t disable the firewall for every network profile just to investigate one failed connection.
Import a Subscription and Verify One Connection Through the System Proxy
- Open the client’s “Subscriptions” page and use the add or import option to paste the full subscription URL. Download the configuration and select it. Button names may vary between versions.
- Check that nodes appear in your proxy groups. Select a node you know works, then make sure the client is in Rule mode, not Direct mode.
- In “Settings,” find the Clash settings and note the mixed port, then enable the system proxy. The example below assumes the mixed port is
7897; use the value shown in your client. - Go to Windows “Settings” → “Network & internet” → “Proxy” and check that the manual proxy points to
127.0.0.1and the port you noted. - Visit the target site in a browser while checking the client’s “Connections” or “Logs” page. Confirm which rule, proxy group, and node handled the connection.
A successful node latency test only shows that its test target was reachable at that moment. It doesn’t prove that every site, UDP traffic, or DNS request is working. If the node list is empty, troubleshoot the subscription format, download errors, or configuration parsing first—not the TUN driver.
Use an Explicit Proxy to Pinpoint the Problem
Open PowerShell and run the two commands below. The first checks the local port; the second explicitly uses an HTTP proxy to reach a test site. These commands use curl.exe to avoid older versions of Windows PowerShell interpreting curl as a different command.
Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com
TcpTestSucceeded : False: Check whether the core is running, whether the port has changed, and whether another program is using it.- The local proxy connects, but the request fails during the handshake or times out: check the node, target site, DNS, and TLS errors in the logs.
- The explicit proxy gets an HTTP response, but the browser fails: check the browser’s proxy settings, extensions, system proxy settings, and bypass list first.
A test site returning an HTTP status such as 403 or 405 may still mean the server responded, but it doesn’t mean the request succeeded. Check the client’s connection log to confirm the request used the intended proxy policy rather than being sent DIRECT by a rule.
Service Mode and TUN: Install, Enable, and Verify in Order
The system proxy is for apps that read Windows proxy settings. Some command-line tools, games, and apps with their own network stack don’t. TUN routes traffic through a virtual network interface and can cover more apps, but it also adds variables involving routing, DNS, and permissions.
Get Service Mode Working First
- In the client’s “Settings,” find the “Service Mode” option and install it. Before granting permission, check the program source shown in the Windows User Account Control prompt.
- After installation, confirm the client shows that the service is running. If it still says the service isn’t installed or failed to start, check the client logs instead of repeatedly reinstalling it.
- Keep the configuration and nodes you’ve already verified, then enable TUN. Check the logs for errors creating the interface, insufficient permissions, or failed route setup.
- Press Win + R, run
ncpa.cpl, and look for the virtual adapter under Network Connections. You can also use the PowerShell command below to show hidden adapters.
Get-NetAdapter -IncludeHidden |
Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Select-Object -First 20 DestinationPrefix, NextHop, InterfaceAlias, RouteMetric
The interface name depends on the core and configuration; it may not include “Clash.” Seeing a virtual adapter doesn’t prove traffic is using it—check the routes and client connection logs too. Enabling TUN doesn’t necessarily remove the existing default route; the core may add more specific routes to capture traffic.
TUN Driver Errors: Don’t Download Random Driver Packages
Creating a TUN interface on Windows requires a compatible driver and sufficient permissions. The implementation depends on the core and client release package. Use the client’s built-in installation, repair, or update mechanism. If the logs clearly report a missing driver component, check your security software’s quarantine and verify the installation is complete, then repair it using a trusted release source.
Service mode runs the relevant components as a service; it doesn’t make an incompatible subscription work or fix dead nodes. If the system proxy test already fails, go back to checking the configuration and nodes. Enabling TUN alone usually won’t fix a problem caused by the same failing node.
System Proxy Is On but Not Working: Diagnose by Symptom
An enabled toggle only means the client tried to set the proxy; it doesn’t mean the target app reads it. First check whether the request reaches the client, then decide whether to investigate the app, rules, or node. The steps below are more direct than reinstalling repeatedly.
| Symptom | Check First | Next Step |
|---|---|---|
| All browsers fail, and the local port test fails too | Core status, port, and listening process | Check the mixed port and review the core startup log. |
| Explicit proxy works, but one browser fails | Proxy extensions, browser-specific proxy settings, and bypass list | Temporarily disable proxy extensions and check the browser’s network settings. |
| Browser works, but terminal or game traffic bypasses the proxy | Whether the app supports the system proxy | Configure the app’s proxy, try temporary proxy variables, or test TUN. |
| Request reaches the client but shows DIRECT | Rule order, proxy group selection, and operating mode | Check which rule matched, then adjust that rule or proxy group. |
| Network drops only after enabling TUN | DNS, routes, other VPNs, and service permissions | Turn off TUN to restore the baseline, then check each factor separately. |
Port in Use: Find the PID; Don’t End a Task by Process Name
If the log says the address is already in use, use PowerShell to find the process listening on the port. The example below uses 7897; check the executable path for the process ID in Task Manager. Running multiple proxy clients is a common cause, but don’t force-close an unknown process.
Get-NetTCPConnection -LocalPort 7897 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Terminal Doesn’t Inherit the System Proxy: Test with Temporary Variables
For command-line tools that support these environment variables, you can set a proxy just for the current PowerShell window. This won’t make every program proxy-aware, and you shouldn’t set global system variables before verifying the setup.
$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
# Clear the variables from this window after testing
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Using http:// as the value for HTTPS_PROXY doesn’t downgrade the target site to HTTP. It tells the client how to connect to the local HTTP proxy; HTTPS destinations are typically reached through a CONNECT tunnel. If an app only accepts SOCKS proxies, follow its documentation instead of copying the HTTP settings.
Network Drops After Enabling TUN: Check DNS and Other Virtual Networks
Turn off TUN first and repeat the same test with the system proxy still enabled. If the connection immediately works again, the problem is more likely in the TUN traffic-capture path than with the subscription as a whole. Note the log timestamps before and after toggling TUN, and check for other VPNs, proxy apps, virtual machine networks, or corporate security software.
Tell DNS Cache Issues Apart from DNS Routing Issues
- After changing DNS settings, run
ipconfig /flushdnsto clear the Windows DNS cache, then restart the test app. Browsers may also keep their own cache and connections. - A browser’s Secure DNS feature or an app’s built-in DoH may bypass the system DNS path. Record the original settings before testing, and change only one DNS setting at a time.
- With fake-ip enabled, some domains may resolve to addresses in the
198.18.0.0/16range. This is a common mapping method; it doesn’t by itself mean DNS has been poisoned, and the mapped address shouldn’t be used as the real server address. - Corporate intranet domains and LAN devices may need a dedicated DNS policy or bypass rule. Access to public domains doesn’t prove that intranet DNS is working.
If DNS hijacking is enabled in the configuration, check its actual scope and the core logs. Traditional DNS on port 53 and DNS sent over HTTPS are different types of traffic. A rule that hijacks port 53 won’t necessarily handle DNS from every app.
Working with Other VPNs and Virtual Machine Networks
Don’t uninstall every virtual adapter. First quit VPNs or other proxy clients you aren’t using, then test TUN again. If you need a corporate VPN running at the same time, ask your administrator to confirm route priorities, intranet subnets, and DNS split-tunneling. Arbitrarily lowering route metrics may send traffic meant for the intranet through the wrong gateway.
Exit, Startup, and Routine Maintenance
After installation, test a normal shutdown: turn off TUN and the system proxy, exit the client, and confirm that your regular network connection still works. If your browser loses connectivity after the client crashes, go to Windows “Settings” → “Network & internet” → “Proxy” and check for a manual proxy still pointing to a local port. Disable it only after confirming no other program depends on it.
- Set the client to start with Windows only after testing. First, restart once and verify that the subscription loads, the core runs, and the proxy is in the expected state. Starting the GUI at login and starting the service are separate things.
- Recheck key settings after updates. Verify the core version, mixed port, service mode, and TUN state. If configuration fields change, refer to the current core documentation and error logs.
- Use overrides for persistent changes. Direct edits to downloaded subscription content may be overwritten the next time it refreshes.
- Include only the essential details when reporting an issue. Note your Windows, client, and core versions, reproduction steps, and redacted logs. Remove subscription credentials, node passwords, and management API keys.
The key to troubleshooting is to preserve a path you’ve already verified: the local port connects, the explicit proxy returns a response, and the expected rule matches. Then expand testing to the system proxy and TUN. With a clear result at each step, there’s no need to gamble on repeated reinstalls.