Before You Install: Check Your Windows Architecture and What the Client Does
Clash Verge Rev is a graphical client for managing subscriptions, switching configurations, setting the system proxy, and controlling services. The mihomo core handles rule matching and outbound connections. Installing the client does not give you working proxy nodes by itself. To get started, you’ll need a valid subscription URL or a local YAML configuration containing proxies, proxy groups, and rules.
- Open Windows Settings → System → About and check System type. Choose the x64 installer for an x64 PC. For an ARM64 device, use the ARM64 installer if available.
- Visit the client download page for the Clash Verge Rev Windows download and system requirements. Check the release notes for compatibility with older versions of Windows.
- Note which other proxy tools are running. For your first test, exit other VPNs, proxy clients, and network accelerators to prevent multiple apps from changing the system proxy or default route at the same time.
- Back up your subscriptions and override configurations. Subscription URLs often contain access credentials, so don’t share them in public chats or include them in screenshots posted publicly.
Choose an installation folder in the setup wizard. The client interface can usually run without administrator privileges; admin approval is needed only for tasks such as installing a system service, creating a virtual network adapter, or changing routes. If your device is managed by your organization, check that network services are allowed. Don’t bypass restrictions by disabling security policies.
Import a Subscription: Make Sure It’s Enabled, Not Just Listed
How to Import a Remote Subscription or Local File
- Open the Subscriptions page, paste the full URL into the subscription field, and import it. If your version puts the import option under “New,” select a remote configuration and enter the URL there.
- Wait for the download and parsing to finish. Check for YAML syntax errors, authentication failures, or request timeouts.
- Select the configuration you just imported to make it active. A configuration appearing in the list doesn’t mean the core has switched to it.
- Open the Proxies page. Check that the configuration’s proxy groups and nodes are listed, then select a working node in the group that handles your traffic.
- To use a local file, choose the YAML file through the configuration import option. A file containing only proxies, without proxy groups or rules, may not work as a complete configuration.
After importing a subscription, start with rule mode, set by mode: rule. In rule mode, connections are matched against rules in order and routed to the specified proxy group or outbound. Global mode routes traffic through the outbound selected in GLOBAL; it doesn’t replace checking your rules and proxy groups.
What to Check When a Subscription Won’t Import
- HTTP 401 or 403: Check whether the subscription has expired, its access token was reset, or the server restricts client types. Changing DNS repeatedly won’t fix an authentication error.
- HTML response or YAML parsing error: The URL may lead to a sign-in page or error page, or provide a format intended for another client. Get a configuration compatible with Clash/mihomo.
- Request timed out: First check that your current network can reach the subscription service. If an older proxy is still controlling system settings, exit that client and try again.
- Nodes appear, but websites won’t load: Check which proxy group is actually handling the traffic. A successful latency test only confirms that the test destination is reachable; it doesn’t mean every site, protocol, or exit node will work.
System Proxy: Test Browser Traffic First
Enable “System Proxy” in the client and leave TUN off to keep troubleshooting simple. The system proxy changes Windows proxy settings and usually works with browsers and apps that honor them. It doesn’t route all device traffic; some games, command-line tools, and apps with their own network stacks may ignore the setting.
Open Windows Settings → Network & internet → Proxy and check the manual proxy address and port. The address is usually 127.0.0.1; use the port shown in the client’s active configuration. 7890 is just an example, not a default for every installation.
| Check | Example or Expected Value | Notes |
|---|---|---|
| Mixed port | mixed-port: 7890 | The same port accepts HTTP and SOCKS proxy connections. |
| Windows proxy server | 127.0.0.1:7890 | Use the port the client is actually listening on. |
| Current mode | mode: rule | Check connection logs to see which rule matched. |
| LAN access | allow-lan: false | If the proxy is only for this PC, you don’t need to enable LAN access. |
Use an Explicit Proxy Request to Separate App Issues from Core Issues
Run the following command in PowerShell. It explicitly specifies an HTTP proxy, so it doesn’t depend on whether an app reads Windows proxy settings. Replace the port with the value shown in the client. The test domain is only used to make an HTTPS request; it isn’t guaranteed to be reachable on every network.
Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
TcpTestSucceeded: True only confirms that a TCP connection to the local port was established. An HTTPS response header confirms that this request completed proxy negotiation and connected to its destination. If an explicit proxy request works but an app doesn’t, check the app’s proxy settings before reinstalling the client.
At the same time, open the client’s connection log and check the requested domain, matched rule, proxy group, and final node. If the request matches DIRECT, first check whether that rule is expected. Changing the system proxy address won’t help if the selected proxy group points to a non-working node.
TUN and Service Mode: Enable Them After the Basic Connection Works
TUN mode uses a virtual network interface and routes to capture traffic from more apps, including those that ignore the system proxy. Service mode runs privileged core operations through a background service. Installing the service doesn’t enable TUN, and enabling TUN doesn’t guarantee that routes and DNS are configured correctly.
- First complete the system proxy test from the previous section to confirm that the subscription, node, and core are working.
- Open Settings and find “Service Mode.” Use the provided option to install or manage the service. When Windows User Account Control prompts you, verify the program’s source before approving it.
- Make sure the service is running, then enable “TUN Mode.” If the interface asks you to restart the core, wait for it to finish before testing.
- To test TUN on its own, temporarily turn off the system proxy. Make a request from an app that doesn’t use the system proxy and check the client’s connection log.
- Check regular web browsing, DNS resolution, and access to your internal network. Being able to reach the public internet through TUN doesn’t rule out conflicts with your organization’s network, printers, or another VPN’s routes.
Understanding TUN Configuration Fields
This is a mihomo configuration snippet for checking the active configuration, not a complete subscription. The client may generate or override these fields. Check the final configuration first, then make changes through a supported override or merge option. Direct edits to a remote subscription may be overwritten the next time it updates.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
auto-routeautomatically sets up the relevant routes. If routes aren’t added successfully, app traffic may bypass TUN.auto-detect-interfaceautomatically detects the outbound interface. With multiple network adapters, virtual machines, or another VPN in use, check the logs to confirm the actual route out.dns-hijackset toany:53intercepts matching traditional DNS requests; it doesn’t intercept all encrypted DNS. DoH sent directly by a browser is a separate HTTPS connection.fake-ipreturns a mapped address for matching requests, then the core associates it with the domain. Upstream DNS servers still need to be configured correctly in the full DNS setup. Copying these lines alone doesn’t complete DNS configuration.
Common Errors: Troubleshoot Ports, Permissions, and Routes Separately
Port in Use: address already in use
If the logs show bind, address already in use, or a similar listener error, first find out which process owns the port. Run these commands in PowerShell. If your port isn’t 7890, replace it in the commands.
Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 4321
The 4321 in the second command is an example PID; replace it with the OwningProcess returned by the first command. If it belongs to an older proxy client, exit that client normally. If the port is still occupied, change the current client’s mixed port to an available one, such as 7897, then restart the core and update the Windows proxy port to match. Don’t force-quit a system process unless you know what it is.
Service Installation Failed: Access Denied or Service Won’t Start
First determine whether the service failed to install or installed but won’t start. Installation failures are often related to permissions or device policies; startup failures may also result from an outdated install path, quarantined components, or remnants of an older service. Save the full error message, then work through these steps in order.
- Use the client’s service installation option to request administrator approval again. Make sure you don’t cancel the User Account Control prompt.
- Press
Win + R, enterservices.msc, and check the service status and executable path using the service name shown by the client. Don’t guess the service name and delete it. - Check Protection history in Windows Security, along with the relevant entries for that time in Event Viewer → Windows Logs → System.
- If an upgrade left the service pointing to an invalid path, use the client’s options to uninstall and reinstall the service, then restart the client.
Don’t use permanently disabling your firewall or security protection as a fix. If organization policies prevent service installation, an administrator may need to handle it. In the meantime, you can continue using the system proxy setup you’ve already verified.
Internet or Intranet Stops Working After Enabling TUN
Turn off TUN first and check whether your regular network connection returns. If it does, test the system proxy again. If the system proxy works, the node and basic outbound connection probably aren’t the main issue; focus on the virtual interface, routes, and DNS. Exit other VPNs before trying again to avoid two apps taking over the default route.
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric
These commands inspect the network without changing it. Compare the interfaces and routes before and after enabling TUN. If only internal resources are unreachable, check the internal network ranges, access rules, and route exclusions. Adding DIRECT to a rule may not help if the destination is already being routed incorrectly. To roll back, turn off TUN first; don’t delete system routes in bulk.
No Internet Access After Exiting the Client
First check Windows Settings → Network & internet → Proxy. If the manual proxy still points to a 127.0.0.1 port that is no longer listening, turn off that manual proxy setting and test again. Before exiting normally, turn off the client’s system proxy to help prevent stale proxy settings.
If the problem persists, check whether the background service is still running and whether TUN routes have been removed. Closing the window to the system tray is not the same as exiting the app; don’t assume the core has stopped just because the window disappeared.
After Installation: Keep a Repeatable Test Path
You don’t need to enable every switch when setup is complete. If you mainly use a browser, you can stick with the system proxy. Enable TUN only when you need to route other apps and have verified the configuration. Rule mode, the system proxy, and TUN control different layers; the state of one doesn’t confirm that the others are configured correctly.
- Configuration: The current subscription is enabled, the Proxies page shows a working proxy group, and the configuration still loads after an update.
- Ports: The client’s listening port matches the Windows proxy setting, and an explicit proxy request returns a response.
- Rules: Check the connection logs for at least one direct request and one proxied request to confirm the selected outbound matches your configuration.
- TUN: With the system proxy off, the target app still creates connections through TUN, and internal resources remain accessible.
- Restart: After restarting Windows, check the service, configuration, and proxy state again. Don’t assume that starting on boot means traffic is being routed.
- Rollback: You can turn off the system proxy and TUN to restore normal networking. Keep a copy of your previous override configuration so you can restore it.
When reporting an issue, include your Windows system type, client and core versions, operating mode, listening port, and error logs from the same time period. Remove subscription tokens, node credentials, and personal browsing records. Say whether the explicit proxy test succeeded and whether TUN failed; that’s more useful than simply saying “Clash won’t connect.” For details on configuration fields, see the full documentation.