Clash FAQ

Clash is the name of a project in the proxy ecosystem; mihomo is a core that supports Clash-compatible configurations and continues to add features. Graphical clients handle subscription management, policy selection, system proxy settings, and logs, while the core typically handles the actual connections. Different releases of the same client may include different cores, so the interface name alone does not tell you whether a configuration field is supported. Before troubleshooting, check the client name, core name, and versions in the About page or startup logs, then consult the matching configuration docs. Don’t copy configuration sections from another core into your current file.

Rule mode is usually best for everyday use. Connections are matched against rules in order and sent to the specified policy group, DIRECT, or REJECT. Global mode routes connections handled by the client through the global policy; it does not automatically proxy every process. The system proxy or TUN determines which traffic is handled. Direct mode sends handled connections straight to their destinations, which can help with comparisons during troubleshooting. When testing, change only the mode—not DNS or nodes at the same time. Compare connection records for the same destination to tell whether the difference comes from routing rules or the exit.

A client is a connection and traffic-routing tool; installing one does not provide a working proxy exit. Get subscriptions from servers you manage, services provided by your organization, or providers that explicitly authorize your use. Publicly shared free nodes may stop working quickly or log connection data, so avoid using them for sensitive activity. Before importing a subscription, check its source, validity period, and client compatibility. This site does not provide node subscriptions. Subscription URLs often contain account identifiers, so treat them like credentials. When asking for help, redact the full URL, node passwords, and personal information; don’t post your configuration file.

A system proxy registers an HTTP or SOCKS proxy endpoint with the operating system. Whether an app uses it depends on how that app handles networking; some games, command-line tools, and apps with their own network stack ignore it. TUN takes over traffic through a virtual network interface and routes, usually covering more apps, but it requires appropriate permissions and coordination with DNS, routing, and other VPNs. First verify that the system proxy works, then enable TUN if your apps need it. TUN does not speed up nodes or fix a failed exit, expired subscription, or server-side connection rejection.

Start by noting the HTTP status code and parsing error in the update log. A 403 usually means the server refused the request, but only the provider can confirm why. Check your account status, subscription validity, and client type. If parsing fails, make sure the URL returns a compatible configuration—not a login page, error page, or plain list of nodes. If your client lets you choose whether updates use Direct or the proxy, test both once to rule out an unreachable download route. Keep the old configuration if it still works; don’t repeatedly delete and recreate it. When contacting the provider, share only error details with sensitive information redacted.

Check the indentation, colons, and list hyphens near the reported line. YAML uses spaces for indentation; don’t use tabs. Next, determine whether the error is a syntax error or a field validation error: syntax errors prevent the file from being parsed, while validation errors often mean a policy name is missing, a node field is absent, or the current core doesn’t support a feature. Check that names referenced in proxy-groups and rules match exactly, and that MATCH is the last rule. Change one thing at a time, then run the configuration check provided by your client. Don’t upload files containing account details to public online parsers.

Check the logs first to distinguish a failed virtual interface, insufficient permissions, and a routing conflict. Windows clients usually need their service mode installed or running; some can also be launched as an administrator. macOS may require authorization for a helper service, while Linux depends on service permissions and whether /dev/net/tun is available. Follow your client’s instructions and grant only the permissions it needs; don’t run scripts from unknown sources. Disable other VPNs that are taking over routes and try again. If the interface starts but you still can’t connect, check DNS and routing rather than repeatedly escalating permissions.

Choose a graphical client if you need a system tray, subscription management, and visual policy selection. For servers and routers, you can deploy the mihomo core to suit your environment. Run uname -m to check the architecture: x86_64 usually means AMD64, and aarch64 usually means ARM64. Then choose a deb, rpm, or other format actually provided by the project for your distribution. Don’t guess the package based only on the processor brand. After installation, check desktop dependencies, service permissions, and configuration paths. A running core doesn’t mean the system is routing traffic through it; check the proxy endpoint or TUN routes too.

Find the actual request in the connections panel and check its destination domain, destination IP, matched rule, and final exit—not just the browser’s address bar. Rules are evaluated in order, so a broad DOMAIN-KEYWORD or GEOIP rule, or an earlier MATCH, can override a more specific rule later on. If the connection shows only an IP, DNS mappings or sniffing results may also affect domain rules. Temporarily add an exact-domain rule above the relevant broad rules, then close the existing connection and try again. Once you confirm the match, clean up your permanent rules. Don’t switch to Global mode as a substitute for checking routing.

Changes made directly to a subscription-generated configuration may be overwritten the next time it updates. To keep rules, DNS settings, or policy changes, use the override, merge, or config script mechanism supported by your client. First check whether it expects a full configuration or a partial snippet. Arrays may be replaced rather than appended, and rule placement affects matching. Back up the original configuration before editing, then check the effective configuration after updating—not just what appears in the editor. Don’t copy another client’s override syntax verbatim; merge behavior varies between clients.

First distinguish launching the client after login, starting a background service with the system, and restoring the system proxy after startup. These may be controlled by separate settings. On desktop, enable startup in the client and check whether proxy settings persist. If you use TUN, make sure its required service can start automatically. After rebooting, check the process, active configuration, and a real connection record; a system tray icon alone doesn’t confirm that everything is working. For Linux systemd services, also check the service user and configuration path. If a subscription update fails because the network isn’t ready at startup, try updating it manually once you’re online.

Connect the computer and other devices to a local network where they can reach each other. Enable LAN access in the client, then check allow-lan, bind-address, and the listening port. On each device, use the computer’s LAN IP as the proxy address—not 127.0.0.1—and enter the HTTP or mixed-port from the active configuration. If the connection still fails, check inbound firewall rules, guest network isolation, and whether the computer’s IP address has changed. Expose the listener only on trusted networks, set authentication if needed, and restrict allowed sources. Don’t expose the proxy port to the public internet or disable the entire firewall to troubleshoot.

Turn off the proxy first and check whether the device can access the internet normally. Then check whether the subscription has expired, the node address resolves, and the system clock is correct. A failed latency test means only that the test request didn’t complete; it doesn’t prove the node is completely unusable. Check actual web requests alongside the core logs. If only one node fails, try another known-working exit. If they all fail, focus on DNS, network restrictions, authentication details, and conflicts with other VPNs. Testing on different networks can help narrow it down; change one condition at a time and keep the logs from when the error occurred.

Confirm the core is running and that its listening port matches the value registered with the system. Then check whether the app’s requests appear in the connections panel. A browser may use its own settings or a separate proxy extension, while command-line tools may read only environment variables such as HTTP_PROXY and HTTPS_PROXY. An HTTPS in the variable name doesn’t mean the proxy endpoint itself must use HTTPS. Check the proxy bypass list, old proxy software, and app-specific settings, then restart the app. If it ignores the system proxy, configure a proxy endpoint in the app or, once basic connectivity works, use TUN and verify which traffic it handles.

Some AppContainer apps are restricted by loopback isolation and can’t connect directly to a proxy endpoint on the same device. First confirm that a regular browser works through the same proxy. Then use the client’s UWP loopback tool to exempt only the apps that need access; the tool may require administrator privileges. You can also run CheckNetIsolation LoopbackExempt -s in an administrator terminal to see existing exemptions, but don’t enable loopback for every app. After adding an exemption, fully close and restart the affected app. If it still fails, check the system proxy, app error code, and connection logs. A loopback exemption won’t fix subscription or node issues.

Turn off TUN but leave the system proxy enabled for comparison. Then check the virtual interface, default route, DNS listening address, and whether dns-hijack is actually working. If domains fail but IP addresses work, start with DNS resolution. Browser Secure DNS, encrypted DNS in the operating system, or another VPN may bypass the expected route. fake-ip mode requires both domain mappings and routing; changing enhanced-mode alone isn’t enough. After making changes, close existing connections and resolve the domains again, then retest using connection logs and a DNS test. The location of a resolver shown on a test page is only a clue; location alone doesn’t prove a DNS leak.