Clash FAQs
and Troubleshooting

The core handles proxy connections, DNS resolution, and rule matching, while a graphical client manages configuration imports, proxy groups, and system proxy settings. Mihomo is an actively maintained compatible core in the Clash ecosystem, but clients may bundle different cores and support different configuration fields. When troubleshooting, note the client name and core version under Settings → About or Core Information; saying only that Clash is installed isn’t enough. A configuration that works in another client may use fields your current core doesn’t support. If you see unsupported or unknown field, adjust the configuration to match your core instead of repeatedly reinstalling the client.

The client and subscription service are separate; installing the app doesn’t provide proxy servers. Import your own configuration file or a Clash-compatible subscription from your provider. In the Configuration or Profiles page, choose New → Import from URL. Once it downloads, select that profile, then choose a proxy group on the Proxies page. Don’t use your provider’s login page URL as the subscription URL, or treat a single share link as a complete YAML configuration. The token in a subscription URL is an access credential: hide it in screenshots, support requests, and public logs. If it’s exposed, reset the subscription link in your provider’s dashboard.

Rule mode is usually best for everyday use: traffic is matched against rules one by one and sent to the corresponding proxy group. Global mode sends requests that reach the core through the global proxy selection, but doesn’t automatically capture traffic from every app. Apps that don’t use the system proxy, TUN, or an explicitly configured proxy may bypass the core. Direct mode sends connections that reach the core straight to their destinations. Global isn’t faster; it only changes routing, not the quality of the connection. For a quick comparison, test the same node in Rule and Global mode. If only Rule mode fails, check the matched rule and proxy group. Switch back to Rule mode afterward, and make sure the global and service-specific groups aren’t using different nodes.

A latency test measures the response time of a small request to a specific target, not sustained download bandwidth. The test target, timeout, and whether traffic goes through the proxy all affect the result. Low latency doesn’t guarantee enough capacity during peak hours. First confirm your connection is using the node you tested, not a different one selected by an automatic proxy group. Then compare downloads of the same file at the same time of day. Speed can also be limited by the destination site, local Wi-Fi, inter-network congestion, or your provider’s data cap. Avoid repeatedly testing every node at high frequency, which can add load or trigger limits. A timeout only means that test failed; check real-world access and connection logs before concluding a node is completely down.

First distinguish a download failure from a configuration parsing failure. If logs show 401 or 403, check whether the subscription link was reset, your plan expired, or the provider is restricting requests. A 403 can also come from access protection; it doesn’t necessarily mean the password is wrong. For connection timeouts, check the system clock, confirm the current network can reach the subscription domain, and make sure updates aren’t routed through a proxy that’s no longer working. If your client lets you change the update route, temporarily try Direct mode. If the download succeeds but import fails, check whether the response is a login page or error message instead of YAML. Copy a fresh Clash-compatible link from your provider’s dashboard. Don’t remove query parameters or post the full URL in a public forum.

Check the line number and field path in the error, then inspect that line and the one above it. YAML indentation uses spaces, not tabs. List items need a hyphen, keys need an English colon, and values containing special characters may need quotes. Common issues include full-width punctuation copied from another source, placing fields under dns at the top level, or defining rules twice at the same level. Back up the original file, fix one issue at a time, then use the client’s configuration checker. If syntax validation passes but the client reports a missing proxy or proxy group, check the referenced names; that’s not an indentation issue. Remote subscriptions may overwrite local edits when updated, so use the client’s override or merge feature for lasting changes.

First confirm that your client and core support TUN, then check the startup log for the specific failure. On Windows, you may need to install or enable the client’s service mode and, for initial setup, follow its instructions to run the required steps as an administrator. On macOS, you may need to approve a background service or network extension, depending on the client. On Linux, check whether /dev/net/tun exists and whether the service has permission to create interfaces and change routes. Running the entire desktop app with elevated privileges indefinitely shouldn’t be your only solution. Temporarily disable virtual network takeover by other VPNs to avoid route conflicts. Enable only one traffic-capture method at a time. Once the log confirms the interface was created, check DNS and app connectivity.

Confirm that you allowed Android’s VPN connection request at startup and that the client shows a running notification. Usually, only one VPN can be active for an Android user at a time. Another VPN or filtering app that uses the VPN interface may replace the current connection. If the connection drops only when the screen locks, go to Settings → Apps → the client → Battery and allow background activity or set battery usage to Unrestricted. Also check your device manufacturer’s settings for auto-start, background activity, and app locking; menu names vary. Leaving the app in the recent-apps list doesn’t add it to an allowlist. If the notification remains but traffic stops, check the logs for a network switch or failed node reconnection, and test Wi-Fi and mobile data separately.

The system proxy switch only writes a proxy address to the operating system; it doesn’t confirm that the core is listening. Check the logs for the actual listening address and port for mixed-port, then compare them with the HTTP and HTTPS proxy settings in your system network settings. Browser extensions, custom proxy settings, and app-specific network options can override the system settings; disable those overrides while testing. After visiting a site, check the client’s Connections page: no entries means the request never reached the core. If an entry shows DIRECT, check the rules and proxy group instead of toggling the system proxy again. Some apps don’t use the system proxy and need explicit proxy settings or TUN. Also check the proxy bypass list: excluded domains won’t be routed through the proxy.

Find out what’s using the port before changing it. On Windows, run netstat -ano | findstr :7890 and look up the process by PID. On macOS or Linux, use lsof -nP -iTCP:7890 -sTCP:LISTEN. If another client instance is using it, exit that instance normally rather than ending an unfamiliar system process. If you need a different port, use the configuration below to change the mixed port to 7891 and keep it available only to the local machine. Save and reload the configuration, then confirm the core is listening. Turn the system proxy off and back on to sync the address; also update the browser, terminal, and other tools with explicitly configured proxy settings. If the client has a separate port settings page, use the effective configuration and logs to confirm the final value.

mixed-port: 7891
allow-lan: false

To connect your phone to a proxy port on your computer, you’ll usually need to enable allow-lan and configure the listener to accept connections from your local network. Other devices can’t connect if it listens only on 127.0.0.1. Both devices must be on a trusted local network that allows them to communicate. On your phone’s Wi-Fi settings, set the manual HTTP proxy to your computer’s local IP address and actual mixed-port, not 127.0.0.1. Allow only the necessary network traffic through your computer’s firewall, and configure proxy authentication if your core supports it. Never expose the proxy port to the internet through router port forwarding. Some Wi-Fi networks isolate clients, so devices on the same network may still be unable to reach each other. A phone’s HTTP proxy also won’t capture traffic from every app or protocol; first test basic connectivity in a browser.

First check whether the app actually relies on the local proxy. Some UWP or AppContainer apps are restricted by network isolation and can’t access a local loopback address, so a working browser doesn’t rule out this issue. If your client offers a UWP loopback or Loopback tool, add a loopback exemption for the affected app if needed. You can also run CheckNetIsolation LoopbackExempt -s to list current exemptions, then follow the Windows tool’s instructions to add the app using its exact package family name. This usually requires administrator privileges. Don’t disable isolation for every app, and don’t treat loopback exemptions as a universal connectivity fix. If TUN resolves the issue, investigate the original system proxy path. If it still fails, check the app account, DNS, and matched rules.

First confirm that your local network works with the proxy turned off. Then check that your subscription is valid, you have remaining data, and your system date and time are correct. Test a node while checking the logs to distinguish a server connection timeout, TLS handshake error, and DNS lookup failure; each needs a different fix. If only the built-in test fails, try a known-accessible test URL and open the target site yourself so a faulty test URL isn’t mistaken for a complete outage. Make sure you aren’t running two proxy clients or VPNs at once. If the same node works on another network, investigate restrictions or local routing on the current network. If it fails across multiple devices and networks, check with your provider about server status.

Possibly, but check the logs first for lookup failures, timeouts, or unexpected IP addresses. The system’s nslookup command usually queries the system resolver, which may not follow the same DNS path as apps routed through the core. So a successful result doesn’t prove the core’s DNS is working. Check dns.enable, enhanced-mode, and nameserver in the active configuration, and confirm the upstream resolvers are reachable on your current network. With fake-ip, also check that TUN, DNS interception, and app caches are configured to work together. After changing modes, restart affected apps and clear their DNS caches. Don’t paste in an unfamiliar DNS configuration or assume adding fallback will always fix DNS poisoning. Restore the subscription’s original configuration, change one field at a time, and check the result for the same domain.

The most common cause is that the system is still pointing to a local proxy that’s no longer listening. On Windows, check the manual proxy under Settings → Network & Internet → Proxy. On macOS, check HTTP, HTTPS, and SOCKS under System Settings → Network → your current connection → Details → Proxies. Turn off only settings you’ve confirmed the client added; note any existing corporate proxy before changing it. If you set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY in your terminal, check both the current session and your shell startup files. If you were using TUN, restart the client, turn off TUN, then quit normally so it can clean up routes and DNS. If the issue persists, record the current network configuration and reconnect before considering a full network reset.

Keep your configuration and logs before considering a reinstall. Check the client’s data directory or system crash report for the last lines before the crash. Look for configuration parsing errors, a core that won’t start, permission denials, or missing graphics runtime components. If you recently edited the configuration, back it up and restore the last working version. If the client still crashes, confirm the installer matches your system architecture and check whether security software quarantined the core files. Don’t disable security protection system-wide as a permanent workaround. Before reinstalling, back up your subscription, overrides, and proxy group selections; reinstalling may not remove corrupted user data. When reporting the issue, include the client and core versions, system details, reproduction steps, and redacted logs—but never subscription credentials.