Clash Verge FAQ

Clash Verge is the name of a desktop proxy client project. Clash Verge Rev is a community project that continues the same style of use, but the two follow separate release tracks, so check their installers and maintenance status separately. Mihomo is the core that handles protocol connections, rule matching, and DNS; the graphical client manages subscriptions, system proxy settings, preferences, and logs. When troubleshooting, note the full client name from its About or Settings page, then record the core details—don't just write “Clash.” A desktop client is not a mobile app: for Android or iOS, choose a client for that platform and confirm that it supports your subscription format.

The client reads configuration and forwards traffic; installing it does not provide a proxy service. You generally need a subscription URL from a provider you're authorized to use, or a configuration file with proxy nodes and proxy groups. A successful import only means the content was read—it doesn't confirm that your account is active or that every node is reachable. To get started, check your subscription status, select a working proxy group, enable the system proxy, and test the site you want to reach. Subscription URLs may contain account identifiers, so treat them as sensitive. When asking for help, don't share the full URL, its QR code, or an unredacted configuration file.

Rule mode applies configuration rules in order to send each connection direct, reject it, or route it through a proxy group. Global mode sends connections that enter the core through the selected global proxy group. Direct mode lets those connections reach their destinations without a proxy. Global mode does not take over every connection on your device: traffic only enters the core through an entry point such as the system proxy, an app proxy, or TUN. Rule mode is usually best for everyday traffic routing. For troubleshooting, you can temporarily switch to Global, select a working node, then restore your previous mode. After switching, reconnect—existing long-lived connections may keep using their previous route. Check DNS behavior separately against your DNS settings.

The system proxy registers a local proxy address with the operating system. It's suitable for browsers and apps that honor that setting, but some games, command-line tools, and apps with their own networking stack may ignore it. TUN uses a virtual network interface and routing to capture traffic that matches its configuration. It covers more traffic, but requires more setup for permissions, routes, and DNS. When getting started, use the system proxy to verify your subscription and nodes, then enable TUN if your apps need it. The two modes can coexist, but enabling both shouldn't be your default troubleshooting fix. If another VPN or traffic-routing tool is running, disable one of them first to avoid conflicting routes.

First determine whether the download failed or the content couldn't be parsed. A timeout, authentication failure, or HTTP 403 usually points to a network, account, or server-side restriction. A YAML parsing error means the returned content isn't a configuration the client can read. Check that you copied the full URL, your account is active, and your provider hasn't changed the subscription endpoint. If the response is a login page or error page, importing it again won't help. HTTP 403 doesn't necessarily mean your account has expired—check your provider's guidance. If the subscription is only accessible through a proxy, try updating it over an existing working connection, depending on the client's update settings. Don't give a private subscription to an unfamiliar online conversion service.

Check the processor architecture shown by your operating system rather than relying on the device brand. Most Windows PCs with Intel or AMD processors use an x64 package. For ARM devices, confirm that the client offers a matching build and that your system can run it. On macOS, check About This Mac to see whether you have Apple silicon or Intel, then choose the corresponding installer. On Linux, amd64 and arm64 are architectures, while deb and rpm are package formats for different distributions; they aren't interchangeable. If the app won't run or reports missing dependencies, verify the architecture, distribution, and system requirements before reinstalling. Don't disable system security protections to work around an installer with unknown origins or compatibility.

Check the logs to see whether the failure occurred while starting the service, creating the virtual network adapter, or setting up routes. Don't rely only on whether the toggle switches back off. On Windows, check that the client’s required service mode is installed and running; installing or repairing it usually requires administrator approval. On macOS, complete the authorization steps requested by the system. On Linux, configure the service or network permissions as described by the client. After authorization, restart the core and test again. If the logs mention a device in use or a route conflict, stop other VPNs, older proxy services, or duplicate client processes first. Permission requirements vary by OS and client version; don't run every app with elevated privileges as a permanent workaround.

Start at login only launches the client after you sign in; it doesn't mean the network is ready, the subscription has updated, or the TUN service has started. First launch the client manually and verify that the current configuration, proxy group, and traffic entry point all work. Then enable startup. Silent startup usually controls whether the window appears; it doesn't fix connection problems. After restarting, check the status in the taskbar or menu bar, the service status, and the timestamps in the logs. Confirm whether the window closed while the process stayed active—or whether the process never started. If the subscription update runs before the network is available, connect to the network and update it manually. Before closing the client, also check how it restores the system proxy setting so it doesn't leave the system pointing to a port that is no longer running.

Rules are generally matched from top to bottom, and the first match determines the policy. Rules placed after the fallback MATCH rule usually won't run. Check the connection log for the destination domain, matched rule, and actual policy, then decide whether you need a domain rule, an IP rule, or a rule set. The proxy group named at the end of a rule must match the configuration exactly. After editing, make sure the configuration has been reloaded. Don't rely only on the browser's address bar: a page may connect to multiple resource domains, and existing connections may keep their original policy. For rules you need to keep, use the client's supported override or merge mechanism and check where the rules are inserted. Direct edits to a subscription-generated file may be overwritten at the next update.

A subscription update fetches the remote configuration again, so changes made directly to that file may be overwritten. If a node or proxy group is renamed, the saved selection may no longer match and can revert to the default. First identify what you need to keep—custom rules, DNS fields, or proxy group structure—then use the override, merge, or scripting features supported by your client. Check the order in which those features run. Save a recoverable copy before making changes, then inspect the final active configuration after updating, not just the source file in the editor. When restoring changes, merge them one at a time. Avoid overwriting the new configuration wholesale with old node details, outdated rule-set URLs, or unsupported fields.

fake-ip is a way to handle DNS responses and map them to connections; it doesn't mean every DNS request is being captured. Check system DNS, the browser's Secure DNS setting, the client's DNS listener and upstream resolvers, and the scope of DNS capture in TUN separately. Before testing, note which resolver you expect to use and compare that with the logs and actual query path. A test site's reported resolver location alone doesn't prove there's a leak. A browser's encrypted DNS may bypass system resolution, while its traffic still goes through the proxy—check the actual route. Change one entry point at a time, clear the app's DNS cache, and reconnect so you can identify the cause.

On the other device, enter the IP address of the computer running the client on your current local network, along with the proxy port the client is actually listening on. Don't use 127.0.0.1: that address points to the device itself on every machine. Make sure LAN access is enabled, the listening address accepts connections from other devices, and both devices are on a network that allows them to communicate. Then check that the firewall permits the port only on trusted networks. Guest Wi-Fi or wireless client isolation may block device-to-device connections, and a sleeping computer will interrupt them. Use this only on a trusted LAN; don't expose the proxy port to the public internet. Turn off sharing when you're done. If you change the client's port, update the settings on other devices too.

First, check the client's connection log to see whether requests from the app appear. If nothing shows up, verify that the core is running, the system proxy address and port match the client, and the app isn't using its own proxy settings, a browser extension, or a bypass list. Command-line tools may require proxy arguments of their own, so their connection status alone doesn't show whether the system proxy is broken. If requests do appear in the log, check the matched rule and policy—the rule may be routing traffic direct rather than indicating a problem with the proxy entry point. Reconnect after making changes, then test again. Also check whether another proxy tool keeps overwriting system settings. Don't run multiple clients that compete for the same port or control the same proxy settings.

First turn off the proxy entry point and confirm that your basic network can reach sites that normally work without a proxy. Then check that the subscription is valid and the system clock is accurate. A timed-out test may only mean the test address is unreachable; it doesn't prove the node is down. Check access to actual sites and the core logs too. Choose a known working node, switch to Global mode temporarily, and note whether the error occurs during DNS lookup, connection setup, or the protocol handshake. If only some nodes fail, check those nodes or the provider's service first. If they all fail, check local ports, DNS, network restrictions, and conflicts with other VPNs. Change one thing at a time and keep its original value so the issue can be reproduced and isolated instead of masked by repeated reinstalls.

Some Windows apps isolated by AppContainer can't access the local loopback address by default, so a working browser doesn't mean those apps can connect to a proxy at 127.0.0.1. First confirm that the target app is affected. Then, in an administrator terminal, run CheckNetIsolation LoopbackExempt -s to see existing exemptions. Use Get-AppxPackage to find the app's PackageFamilyName, then run CheckNetIsolation LoopbackExempt -a -n= followed by that package family name. Add an exemption only for apps that need it, then reopen the app and test. You can also consider using TUN to capture its traffic, but not every connection failure is caused by loopback restrictions. On managed devices, follow your organization's policies and don't exempt every app.

Don't make ignoring certificate warnings your regular fix, and don't install a root certificate from an unknown source just to keep browsing. Check the system date, time zone, and time synchronization first, then compare the same site with the proxy turned off. If the error only occurs with the proxy enabled, check for HTTPS inspection tools, security software scanning encrypted traffic, incorrect DNS results, or a network portal that requires sign-in. A standard proxy doesn't usually need to replace a destination site's certificate. If several sites show the same unfamiliar issuer, stop sensitive activity and inspect the certificate chain. If only one site fails across different networks, the site may have a certificate issue of its own. Wait for it to be fixed rather than lowering your browser's verification requirements.