Clash FAQs

The client handles configuration imports, system proxy settings, and the user interface. The core parses the configuration, matches rules, and establishes connections. Clash Meta is a fork developed from the original Clash, and mihomo continues along that core lineage. A client with Clash in its name does not necessarily use the same core. If a protocol is unsupported or a field triggers an error, check the core name on the client's About page, then consult the documentation for that version. Don't judge compatibility by the interface name alone.

A client is a networking tool; installing it does not provide a proxy service. You generally need to import a subscription URL you’re authorized to use or enter the details for a server you manage. First check that a configuration file appears on the configuration page and is enabled, then see whether the proxy group references a proxy or proxy collection. A configuration containing only DIRECT can route traffic directly, but it won’t create proxy nodes. Downloading a client and obtaining server connection details are separate steps.

Rule mode checks rules from top to bottom; the first match determines where the connection goes, making it suitable for everyday traffic routing. Global mode sends connections that reach the core through the selected global policy. Direct mode connects those requests straight to their destinations. Start with Rule mode, then check the connection log to see which rule matched. Global mode won't automatically proxy apps whose traffic never reaches the core, and it doesn't replace system proxy or TUN traffic capture.

These are different ways to route traffic, and you don't need to enable both by default. The system proxy works mainly with apps that honor the operating system's proxy settings. TUN captures traffic through a virtual network interface, usually covering more apps and sometimes requiring administrator privileges. For your initial setup, enable only the system proxy. Once nodes and rules work, enable TUN if your apps need it. If you use both, follow the client's instructions. If something goes wrong, turn one off to narrow down the cause.

They serve different roles. Core projects maintain network-processing code, client projects build the graphical interface and system integration, and subscription providers supply server connection details and manage service availability. Clash Config Guide provides client download links and setup instructions; it doesn't issue subscriptions or restore expired accounts. When searching for the official Clash site or free Clash proxies, check who runs the page and what it's for. Don't submit subscription keys to unknown conversion sites or feedback forms.

Ubuntu desktop users can start with a Linux-compatible graphical client to import subscriptions, switch policies, and view logs. Headless servers are better suited to running mihomo directly under systemd. Before downloading, use uname -m to check your processor architecture and confirm the package type. Don't let a desktop client and a standalone core use the same proxy port. When moving to a service-based setup, check the service account, configuration directory, and file permissions again.

Make sure you copied the full subscription URL, not the account dashboard address, and check for spaces or line breaks around it. Then review the update log: 401 or 403 usually points to an authorization issue; for 404, check whether the URL has changed; for timeouts, check your network and the route used for the update. If content downloads but parsing fails, the response may be a login page or an unsupported format. When contacting the provider, share only the status code and a brief error summary—never the full subscription URL.

Back up the working file first, then check the lines around the line number in the log. The reported location can be caused by indentation on the previous line or an unclosed quote. YAML uses spaces for indentation, not tabs; align list-item hyphens with their sibling fields. In this guide, general is a section heading for basic settings, not a top-level key; fields such as mixed-port belong at the root level. If the syntax is fixed but the core still reports an unknown protocol or field, check core support instead of repeatedly changing indentation.

Check the log first to distinguish a virtual network adapter creation failure from a route update failure or a missing device. On Windows, follow the client's instructions to install service mode and grant permission. On Linux, check whether /dev/net/tun exists and whether the process has the required network administration privileges. Containers also need the host to explicitly provide the device and permissions. Don't loosen permissions on every directory to solve a network permissions issue. After making changes, restart the core and confirm that the virtual interface, routes, and DNS routing are actually working.

If you edit a configuration generated from a remote subscription directly, the next update may overwrite your local changes. Use the client's override, merge, or extension feature to keep custom rules separate from the subscription source. After merging, inspect the effective configuration and confirm that rule order and policy group names are correct. Rules that need priority usually go before catch-all rules. Merge behavior varies by client, so when switching clients, don't just copy the override file—check the result too.

Decide whether to match one exact domain or an entire domain suffix. DOMAIN matches an exact domain; DOMAIN-SUFFIX matches that domain and its subdomains, so it has a broader scope. The rule's target must be a valid outbound, such as an existing proxy, policy group, or DIRECT, and the rule must come before broader rules that might match first and before MATCH. Save and reload the configuration, close existing connections, then visit the domain and check the connection log to see which rule matched. Existing long-lived connections usually won't switch to the new outbound just because you changed a rule.

Some command-line tools read only their own options or proxy environment variables, not the desktop proxy settings. First try a one-off test with curl --proxy http://127.0.0.1:7890 https://example.com, replacing the port with your actual mixed-port. If it works, follow the tool's documentation to set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, and check that NO_PROXY doesn't exclude the destination. Variables set in a terminal aren't automatically passed to an already-running background service; systemd services need their own environment configuration.

First confirm that dns.enable is on, then distinguish among app requests, system DNS, and upstream resolution by the core. Enabling DNS in the core alone won't automatically capture every system query; a browser's built-in encrypted DNS may also use a separate route. Check the logs, system resolver settings, and TUN DNS routing configuration one by one. If needed, temporarily disable the browser's custom DNS for comparison. A DNS test page showing a resolver's location isn't, on its own, enough to prove a DNS leak.

Allow LAN access in the client, then check the core's listening address and make sure the firewall allows the port in use. Other devices should connect to the LAN address of the machine running the client, not 127.0.0.1, which always points to the device itself. Share only on a trusted LAN, and configure authentication and source restrictions if the client supports them. Don't forward the proxy port to the public internet from your router, and don't expose the external-controller management interface just to share the proxy.

A speed test usually checks one request to a specific address; it doesn't prove that every site, protocol, or outbound will work. Check whether a connection appears in the log when you visit the site, then confirm that the matched policy group uses the same node as the speed test. Test DNS resolution, the target site, and another site separately to identify whether the issue is DNS, a specific site, or the node's connection. Don't keep switching nodes based on a single latency reading. Keeping the error type and matching rule from a failed connection makes troubleshooting easier.

Make sure the core is running and that the system proxy address and port match mixed-port. Visit the target, then check the connection log. If there's no entry, check whether the app ignores the system proxy, a browser extension overrides it, or the system is still using a PAC address left by another tool. If an entry shows DIRECT, check the mode and rules instead of changing the system proxy again. For apps that don't support system proxy settings, try TUN after confirming the basic configuration works.

Turn off the proxy and test your basic network connection, then confirm that the subscription is still valid and the node list has updated. Start the core again and check the system clock, server DNS resolution, and handshake errors in the log. If only one protocol fails, check core support and whether your current network allows UDP traffic. If all nodes fail at once, check shared dependencies first, such as DNS, an incorrect outbound interface, or another proxy tool. Try a different network for comparison, but don't assume every server is offline based only on a timed-out speed test.

Close any duplicate client instances and check whether a standalone core or systemd service is still running in the background. On Ubuntu, use ss -ltnp to see TCP listeners, then check process details to identify what's using the port. Don't kill an unknown system process. If you need to keep both services, change mixed-port and update the system proxy, browser settings, and terminal environment variables to match. Also distinguish the proxy port from the external-controller management port: changing the management port won't resolve a proxy listener conflict.

Some apps in the UWP sandbox are subject to loopback restrictions and may not connect to a proxy at 127.0.0.1, but this doesn't apply to every Store app. First confirm that a browser works through the same proxy, then check whether the app appears in the connection log. If it is a loopback restriction, use the client's exemption tool or run CheckNetIsolation as an administrator to exempt the relevant package. Note what you change so you can undo it later. TUN is another option, but you don't need to remove the restriction for every app.

Don't ignore it or disable certificate verification to restore access. First check the system clock and time zone, then verify that the domain, certificate issuer, and validity dates in the warning match the site you're visiting. Next, close packet capture tools or other network filtering software and compare direct access, another node, and another network. Ordinary proxy forwarding doesn't require installing an unfamiliar root certificate. If the issue occurs only through one outbound, don't submit account or payment details through it. Keep the error message and continue troubleshooting.