Clash FAQ
Configuration, connections & troubleshooting

Clash Verge is the name of a desktop client project. Clash Verge Rev is a successor project that continues its development; check each project separately for release and maintenance status. mihomo is the core that handles proxy connections, DNS resolution, and rule matching. The client manages configuration imports, controls, and the interface, while the core processes network traffic. So a working interface doesn’t mean the core has started, and installing a newer client doesn’t guarantee that every field in an older configuration is supported. When troubleshooting, note the client name first, then check the core details in Settings to avoid confusing the client version with the core version.

The client manages connections, but it doesn’t create a working proxy server when installed. A subscription is usually a configuration URL provided by a service provider and may include proxies, proxy groups, and rules. A local YAML file can provide the same information. To get started, import the URL or file on the Profiles page, make sure it parses successfully, then select it as the active configuration. Seeing a profile name doesn’t mean it’s enabled; check the Proxies page to make sure its proxy groups appear. Subscription URLs may contain access credentials, so treat them like account details. Don’t share them in public screenshots, forums, or online conversion tools.

Rule mode evaluates connections against the configuration’s rules in order and applies the matching policy, making it a good choice for everyday traffic routing. Global mode sends connections already handled by the core to the global proxy group. It’s useful for quick comparisons, but you still need to select an available proxy in that group. Direct mode sends handled connections straight to their destinations without using a proxy. These modes determine how traffic is handled after it reaches the core, not which apps reach it. Switching to Global won’t capture an app that ignores the system proxy. Check the app’s proxy settings first, then consider TUN if needed.

System proxy changes the proxy settings provided by the operating system. Only apps that follow those settings send connections to the client. TUN uses a virtual network interface to capture traffic that matches its routing rules. It can work with some apps that ignore the system proxy, but usually requires service permissions and involves routing and DNS settings. When starting out, enable only the system proxy and verify a connection before turning on TUN if you need it. Whether both can or should be used depends on the client and configuration; enabling both isn’t a requirement. When troubleshooting, change one setting at a time and check the destination and matched rule on the Connections page so you can tell what made a difference.

Make sure you copied the complete subscription URL, not an account home page, payment page, or sharing instructions. Check for spaces or line breaks at either end, then try updating the profile again and read the error message. For authentication errors or access denied, ask the provider whether the subscription has expired or the URL has been reset. If the response is a web page, you may have copied the wrong URL or hit a login prompt. For timeouts, try updating directly and through an existing working proxy; available options depend on the client. Don’t delete all your old profiles at once. Keep a working one until the new subscription parses successfully and is selected.

Return to the Profiles page and make sure the imported profile is selected as active, not just downloaded. Then check the core logs to distinguish a configuration parse error, a failure to fetch remote proxy providers, and a configuration with no proxies. Some configurations use proxy-providers to reference remote proxy lists; downloading the main file doesn’t mean those URLs are reachable. If you use configuration merging, scripts, or overrides, temporarily disable them and reload the original configuration for comparison. If the page is still empty, ask the provider whether the subscription supports mihomo. Changing a file extension won’t convert another client’s format into YAML.

Turn off TUN first, then check in the client settings whether service mode is installed and running. If you need to install the service, use the client’s service manager and grant permission when prompted by the operating system. On a managed device, ask your administrator to confirm your permissions. After installing or repairing the service, restart the client, turn TUN back on, and check the logs for virtual interface or route creation errors. If another VPN, virtual network adapter tool, or security app is running, pause them one at a time for comparison only if you’re authorized to do so. Don’t delete network adapters or disable all security protections. If permissions are correct but TUN still fails, check whether the TUN fields in your configuration are compatible with the current core.

Check the client settings for the active proxy port. HTTP, SOCKS, and mixed-port are different; mixed-port accepts both HTTP and SOCKS proxy requests on the same listening port. Use the active configuration and core logs as your reference rather than copying numbers from a tutorial. If you see an address-in-use error, quit any duplicate proxy clients first, then use your operating system’s network tools to identify the process occupying the port if needed. After switching to an available port, reload the configuration and update any browser extensions, terminals, and apps where you entered the proxy manually. The controller port is not a proxy port and shouldn’t be entered as an app’s HTTP proxy.

First make sure the active configuration and proxy group selection are in effect. Then enable the system proxy and visit a site that should match a proxy rule. Check the Connections page right away to verify the destination domain, matched rule, and policy or proxy used. A lit system proxy switch alone doesn’t confirm that traffic is being proxied. You can also compare your public IP before and after, but check the Connections page too: some IP lookup domains may be routed directly by your rules. Disable browser extensions that set their own proxy during testing to avoid conflicts. If you use TUN, also test with an app that normally ignores the system proxy.

select lets you choose a proxy manually, which is useful for a consistent exit or troubleshooting. url-test compares candidate proxies against the configured test URL on a schedule, then chooses based on the tolerance setting. Its results only reflect performance against that test destination. fallback chooses an available option in the configured order, making it useful when you have a preferred proxy and backups. Proxy groups can reference other groups, so the final exit may be determined by a nested group rather than the one selected in the interface. To check a specific request, inspect its connection details for the actual route. Don’t switch group types based on a single test; first confirm the test URL works, then choose based on whether you need a stable exit or automatic failover.

Remote subscriptions usually regenerate the original configuration during updates, so edits made directly to that file may be overwritten. To keep custom rules, add them through a client-supported override or configuration merge feature and make sure it’s linked to the active subscription. Rules are generally evaluated in order, so place custom entries before broader rules that might match first, and never after the MATCH catch-all rule. Make sure every referenced proxy group exists, with matching capitalization and spacing. After saving, reload the configuration and use the Connections page to verify which rule a request matched. Don’t rely on the text simply remaining in the editor.

When you’re finished, turn off the system proxy and TUN, then quit the client normally from the system tray so it can restore the relevant settings. If you manually configured a proxy in your browser, terminal, or developer tools, turn off those app-specific settings too. If your connection stops working after an unexpected shutdown, check whether the system proxy still points to localhost even though the listening process has stopped. Turn off that proxy setting and test again. Don’t start by resetting all network settings or deleting configuration files. If you want the client to start automatically, check startup, core status, and proxy capture separately; launching at startup doesn’t mean the connection is ready.

Turn off the proxy first and confirm your basic network connection works. Then check that the client core is running, the local port is listening, and the target app is actually sending traffic to the client. Check that your subscription is still valid, try another proxy in the same group for comparison, and review the logs for the request. For DNS resolution failures, start with DNS settings. For authentication errors, check the proxy credentials and subscription status. For connection refused, verify the server address, port, and service availability. If every proxy fails at once, check your local network and configuration before changing protocol settings one by one. Change only one thing at a time and retry the same destination, keeping the logs from before and after to see whether it helped.

In your operating system’s proxy settings, confirm that the address and port point to the current client, and check that the core is listening. Then look for an app-specific proxy setting, browser extension, bypass list, or another VPN that could change the connection route. Watch the Connections page while visiting a test destination. If there’s no entry, check how traffic is being captured. If there is an entry marked DIRECT, check the rules and policy rather than reinstalling the client. Some apps ignore the system proxy; configure a supported proxy option in the app or consider TUN. Terminals may also use proxy environment variables, so check them separately after changing the system setting.

First decide which resolver should handle each domain, then check the configuration’s DNS listener, upstream resolvers, and routing rules. Browser Secure DNS, app-level DoH, and encrypted DNS in the operating system can each use a different resolution path. Whether to turn them off depends on your intended setup, not on a single toggle. When using a DNS leak test, distinguish the proxy exit IP from the recursive resolver address; a difference alone doesn’t prove there’s a leak. What matters is whether queries bypass the path you intended. Temporarily turn off the browser’s independent DNS setting for comparison and check the core logs. If you use TUN, also verify that DNS hijacking and routing are active.

Some Windows apps that use AppContainer isolation are restricted from accessing localhost and may not be able to connect to the local proxy listening in the client. First confirm that a regular browser can connect through the same proxy. Then check whether the client offers a UWP loopback exemption setting. If it does, select and authorize only the apps you need. You can also have an administrator manage exemptions with Windows CheckNetIsolation, but you’ll need to identify the app package correctly. Not all Store apps have the same restriction. If it still fails, check whether the app reads the system proxy, whether you’re signed in, and whether the Connections page shows requests instead of repeatedly adding exemptions.