Clash FAQ & Troubleshooting

Clash is a commonly used name for the proxy core and its configuration ecosystem. mihomo is a core in this ecosystem that continues to be developed; it was also known as Clash Meta in the past. Clash Verge Rev is a desktop client for managing configurations, switching proxies, and accessing system settings. The client interface and the core it runs are separate layers. Whether a YAML field is supported depends on the core bundled with the client and its version. When troubleshooting, note the client name on its About page, then identify the core from the core information or startup logs. Don’t assume another client uses the same menu layout.

The client reads configurations and forwards traffic; installing it does not automatically provide a working proxy service. A subscription link is usually provided by a service provider and supplies configuration such as nodes, proxy groups, and rules. Open the provider’s subscription page, choose a configuration link compatible with Clash or mihomo, then add it as a remote configuration in the client. Don’t use the provider’s sign-in page URL as a subscription link, and don’t post your subscription link in a public forum: its access credentials may let others retrieve your configuration. If you only have a local configuration file, you can import it from a file instead.

For everyday use, start with Rule mode, which routes traffic according to the rules in the loaded configuration. Global mode generally applies the global policy to connections that reach the core, but it does not mean every app is being handled; check that the system proxy or TUN is working too. Direct mode connects traffic received by the core straight to its destination, making it useful for quick comparisons. Change only one mode at a time; don’t also change DNS or nodes while testing. If a website works only in Global mode, check its rule match and proxy group selection rather than relying on Global mode to hide a configuration issue.

The system proxy sets a proxy address in the operating system and mainly affects apps that honor that setting. TUN uses a virtual network interface and routing to capture eligible traffic, and usually requires additional permissions. You don’t need to enable both just to get connected. First test a browser with only the system proxy, then try TUN if you need to route games, command-line tools, or other apps. Some clients let you use both, but routing and exclusion settings also affect which traffic is captured. If problems start after enabling TUN, turn it off and compare to see whether the cause is traffic capture or the proxy service itself.

Return to the configuration page and make sure the imported configuration is active, not just saved in the list. Then check the update history and core logs to see whether the download succeeded and the YAML parsed correctly. Some configurations fetch nodes separately through proxy-providers, so a successfully loaded main configuration doesn’t guarantee that the providers have updated. Check their status on the providers page too. If the service returns a sign-in page, an error, or a subscription format the client doesn’t support, get a compatible link from the provider. Don’t keep creating configurations with the same name; keep one copy for comparison while troubleshooting.

Check the provider’s account page to see whether the subscription has expired, its data allowance is used up, or the link has been reset. A 401 usually indicates an authentication issue, while a 403 means access was denied; check the provider’s guidance for the specific cause. Copy the full subscription URL again, removing any accidental spaces or line breaks, replace the link in the existing configuration, and update it manually. If the link works on another network, check whether the current network is blocking the request. When reporting the issue, include only the error code and redacted logs—not the full subscription URL. Repeatedly clicking Update usually won’t lift a server-side access restriction.

First confirm that the regular system proxy works, then troubleshoot TUN permissions. Desktop clients often need service mode installed or running. On Windows, check the service status in the client settings and grant permission when prompted; on macOS, complete the required system authorization. On Linux, follow the client’s documentation to configure its service or required capabilities. Don’t make an entire directory writable without a specific reason. After granting permission, restart the client and check the logs for failures creating the interface, setting routes, or accessing the service. If this is a managed work device, ask your administrator about the permission policy instead of repeatedly trying to bypass system restrictions.

Some Windows apps isolated with AppContainer can’t access the local loopback address by default. If a browser works but a Store app doesn’t, check whether loopback restrictions are the cause. If your client includes a UWP loopback tool, open it as an administrator and select only the apps that need access to the local proxy. Save the changes, then fully close and restart the affected app. Menu names vary by client; if there’s no built-in tool, consult Microsoft’s guidance on loopback exemptions. Grant access only to the apps that need it—don’t select everything. A loopback exemption won’t fix an expired subscription, a remote node failure, or an app’s own network restrictions.

Follow the update interval recommended by your provider. If there’s no specific guidance, start with once a day rather than requesting the subscription too frequently. Changes made directly to a remote YAML file may be overwritten when the configuration updates, so put custom rules, DNS settings, and policy changes in the client’s supported override or merge configuration instead. After setting this up, run an update manually and check the resulting active configuration to confirm your changes remain. Clients handle merge order and arrays differently, so recheck everything when switching clients; copying an override file alone doesn’t guarantee the same result.

Give each configuration a distinct name, such as one based on its purpose or provider, instead of keeping the default names. To switch, set the intended configuration as active on the configuration page, then check that the proxy groups and available nodes have changed on the proxy page. Existing connections may continue using their previous route for a while. Before testing, close and reopen the app or end its connections using the client’s connection manager. Delete the old configuration only after confirming the new one works. Save any local rules you need first, and check whether remote subscriptions and local overrides are stored separately.

Open the client’s Connections page, then visit the website again. Find the new connection by domain or destination address and check the matched rule, proxy group, and final outbound. Existing connections may not be matched again, so close the old page or end the connection before retesting. If the interface shows only an IP address, check the logs to see whether DNS resolution occurred and whether the rule depends on domain information. If traffic matches the fallback rule, make sure the intended rule comes before it and that the rule set loaded successfully. Don’t assume every website uses the selected node just because it’s selected on the proxy page.

Include your operating system, client name, client and core versions, and the proxy mode, system proxy, and TUN status when the issue occurred. Describe a repeatable action—for example, what error appears when you open a particular type of app—and say whether other apps work on the same network. Include only the relevant log lines around one failed attempt, keeping error codes and necessary context. Before posting, hide the full subscription URL, access credentials, node passwords, personal account details, and any public IP addresses that aren’t needed. Don’t upload the entire configuration file publicly; extract the relevant fields and replace sensitive values to help others diagnose the issue while limiting exposure.

Turn off the proxy first to confirm that the underlying network works. Check that your device’s date and time are correct, then verify the subscription status and configuration update. Test one known-good node and check the logs to see whether the failure is DNS resolution, a refused connection, or a failed handshake. A speed-test timeout can also mean the test target is unreachable, so compare it with actual browsing results. If all nodes fail, check DNS, network restrictions, and the local configuration first. If only one node fails, try another and contact the provider. Change one setting at a time and note what you changed; switching ports, DNS, and routes together makes the cause harder to find.

First check that the client core is running. Then verify that the system proxy’s host and port match the client’s current listening address and mixed port; an enabled switch alone doesn’t guarantee the settings are correct. Close other proxy clients and browser extensions that may override proxy settings, then restart the browser and test again. Apps such as Firefox may use their own network settings, so select the system proxy or enter the correct local proxy address. If no new connection appears on the Connections page, the issue is likely between the app and the client. If a connection does appear, check the matched rule, policy selection, and node status.

Turn off TUN for comparison and confirm that the underlying network and system proxy work. Then check the logs for DNS timeouts, resolution failures, or routing errors. Make sure DNS is enabled in the configuration, that upstream servers are reachable through the intended route, and that the TUN DNS hijacking settings are compatible with the current core. A synthetic address returned by fake-ip is normal and doesn’t mean the configuration is broken. After changing the DNS mode or filters, clear the client and system DNS caches and establish new connections. If only a few apps are affected, consider filtering fake-ip for the relevant domains instead of copying an entire DNS configuration from an unknown source.

If a port is in use, quit other proxy clients and check whether an old core process is still running in the background. Use your system’s network or process tools to identify what’s using the port; don’t terminate an unfamiliar system process. If you change the mixed port, also update any apps where you entered that port manually. If internet access stops after you close the client, check the system network settings for a manual proxy still pointing to localhost. Turn it off and test again. If the issue continues, check whether the TUN service and routes have been restored, and restart the device normally if needed. Before closing the client next time, turn off traffic capture to help prevent network settings from being left behind if the process is force-quit.