Clash FAQ
Subscription, Proxy, and Connection Troubleshooting

Clash is a widely used name in the proxy core and configuration ecosystem. mihomo is an open-source core implementation in this ecosystem, while graphical clients provide interfaces for subscriptions, proxy groups, logs, and system settings. Similar interface names do not mean clients use the same core or support every configuration field. Before choosing a client, check its platform, maintenance status, and core compatibility, then decide whether you need TUN or LAN sharing. When troubleshooting, note both the client name and core details; saying only that you use Clash is often not enough to determine whether a field is supported.

Usually, yes. A client reads configuration and handles connections; installing it does not provide proxy service. Subscription links typically come from a service provider and may contain personal access credentials, so treat them as sensitive. Before importing one, check that its format is supported by the core in use, that the subscription is still valid, and that your account has remaining usage. This site provides client downloads and configuration guides; it does not create subscriptions or nodes. When asking for help, share only the error text—not a full subscription URL, QR code, or configuration file containing personal credentials.

Rule mode routes connections according to the order of the rules and is best for everyday use. Global mode usually sends connections entering the core through the global proxy group, making it useful for brief comparison tests. Direct mode connects those traffic flows straight to their destinations. Global mode does not take over the entire computer: apps that bypass the system proxy or TUN may still bypass the client. After testing, switch back to Rule mode and check the connection list to see which rule matched the destination domain. Changing modes will not fix an expired subscription, an invalid account, or an unreachable node, and it cannot replace checking the underlying network.

mixed-port is a combined port that the core uses to accept HTTP and SOCKS5 proxy connections. A common example is 7890, but use the value in your configuration. The system proxy sets a proxy address in the operating system and mainly affects apps that follow that setting. TUN uses a virtual network interface to capture traffic that meets its routing conditions and requires the appropriate permissions and network components. If you’re new to this, start with the system proxy and confirm that your browser works, then test TUN if your apps need it. You don’t have to enable both at once; testing them separately makes port, permission, and routing conflicts easier to pinpoint.

Open the client’s configuration or subscription page, create a subscription, and paste the full URL. Save it, update it, and set the new configuration as active. To import a local file, choose the file import option and confirm that both the extension and contents are actually YAML—not a web page saved after a failed download. Once the import succeeds, open the proxy groups, choose an available policy, and enable the system proxy. If you edit a local file, keep a copy of the original and check the indentation; don’t mix tabs and spaces. Button names vary between clients, but follow these steps in order: import the configuration, enable it, choose a policy, and route traffic through the client.

Check the update message first and distinguish an HTTP status code from a connection timeout or configuration parsing error. A 401 or 403 usually means you should check access permissions, link credentials, or account status. For a 404, verify that the URL is complete and that the provider hasn’t changed the endpoint. These errors can also come from an intermediary gateway, so check with the provider. For timeouts, test your basic connection and whether the subscription download uses a direct or proxied route. An HTML response or YAML parsing error may mean you received a login page or content in the wrong format. Don’t repeatedly post the link publicly to test it. If its credentials have been exposed, reset the subscription URL in your provider account.

Turn off TUN and confirm that the regular system proxy works. Then check whether the client offers an option to install or repair its service, or authorize a network extension. On Windows, installing or starting the service usually requires administrator approval. On macOS, follow the system prompts to allow the relevant network component. On Linux, permissions and routing requirements depend on how the client was installed. After granting access, restart the client and check the logs for permission or device creation errors. Don’t leave the firewall disabled as a workaround. If another VPN, virtual network adapter tool, or TUN client is running, quit them one at a time and test again to avoid competing routes.

Importing a configuration and authorizing a system VPN are separate steps: the configuration provides proxies and rules, while system authorization lets the client create a network tunnel. On the first connection, make sure the permission prompt was triggered by the client you’re using, then confirm it and complete any device verification requested by iOS. For example, you can open the App Store from the Clash Plus download page and find product information at clashplus.io. If the connection still fails after authorization, check that the configuration is enabled, a proxy group is selected, and no other VPN is using the connection. Check the client’s documentation for supported subscription formats; a file name alone doesn’t establish compatibility.

Check whether the client provides an override or extended configuration feature, and add rules somewhere subscription updates won’t overwrite them. Rules are matched from top to bottom. For example, place DOMAIN-SUFFIX,github.com,PROXY before any broader rule that could match the domain first, and make sure PROXY is the name of an existing policy. Save and reload the configuration, then check the match record for a new connection; existing long-lived connections may not immediately restart under the new rule. If it still doesn’t match, confirm that the app’s traffic passes through the core and check the actual domain in the logs. A website’s main domain and its resource domains may differ.

A latency test measures the response time to a particular test target. It doesn’t measure sustained throughput or guarantee that every site uses the same route. First compare direct and proxied connections on the same network, to the same target, and at around the same time. Check the connection list to confirm the expected proxy group is in use. Then look at Wi-Fi signal strength, background downloads, server congestion, account speed limits, and regional content delivery differences. Don’t keep switching nodes based on a single best latency result. A video connection may continue using its previous policy, so reconnect playback after switching. If a speed test site is unreachable, that alone doesn’t mean the node is down.

Connect your phone and computer to the same trusted LAN. In the computer’s client, allow LAN connections, confirm allow-lan is true, make sure the listening address accepts LAN connections, and note the actual mixed-port value. On your phone, enter the computer’s LAN IP address and that port in the Wi-Fi manual proxy settings. Don’t enter 127.0.0.1—it points to the phone itself. Allow the inbound port through the computer’s firewall only for the network profiles that need it. This mainly affects apps that honor the Wi-Fi HTTP proxy setting and does not guarantee that all traffic will be captured. Turn sharing off when you’re done, and don’t expose the proxy port to the public internet.

Starting the client at login usually launches the app, but may not enable the system proxy, restore TUN, or select the last-used configuration. These behaviors are controlled by separate client settings; there is no universal YAML setting for connecting at startup. Check launch-at-login, connect-on-startup, and service status, then restart the computer to verify. Subscription rules and proxies may be replaced during updates. Save local changes using the client’s supported override, merge, or separate configuration feature. Export a working copy and note the fields you change. If behavior changes after a client update, first check whether your settings were retained. Don’t keep appending the same content to the original subscription file.

Make sure the core is running, the current configuration is enabled, and the system proxy address matches the actual listening port. A system proxy pointing to 127.0.0.1 works only if the client is listening on the local machine. Next, check whether a browser extension, app-specific proxy, auto-configuration script, or another proxy tool is overriding the system settings. Open the connection list and make a new request. If it appears, check the rules and policy; if not, check whether the app reads the system proxy settings. Command-line tools, some games, and Store apps may need separate proxy settings or a TUN test. The system proxy switch alone cannot confirm that all traffic is being captured.

Some UWP apps restricted by app containers may be unable to access a local loopback proxy, but Store apps don’t all behave the same way. First confirm that a regular browser works through the same proxy, then check whether the affected app actually needs to connect to a local proxy. If your client provides a UWP loopback tool, you can grant an exemption to a specific app as needed; administrator approval is usually required. You can also run CheckNetIsolation LoopbackExempt -s to view existing exemptions. Don’t grant exemptions to every app in bulk. If you use TUN, check routing and DNS separately: loopback exemptions aren’t a universal fix for Windows app connectivity issues.

Turn off the proxy to check your basic network connection. Then confirm that the subscription is up to date, your account is active, and the selected proxy group isn’t using a dead node. timeout means the connection didn’t complete in time; possible causes include packet loss, an unreachable address, server status, or DNS resolution. connection refused usually means the destination port rejected the connection, though it can also mean the local proxy port isn’t listening. Check whether the address in the error belongs to the node server, the destination site, or the local loopback interface before deciding what to investigate. Compare with another known-working connection and note when the error occurred. Don’t assume every timeout is caused by a rule, or change the port, DNS, and mode all at once.

First check whether the issue affects only one domain, then look in the logs for resolution failures, upstream DNS timeouts, or a rule match that shouldn’t have happened. With Fake-IP enabled, getting a reserved address in a DNS lookup may be expected; that alone doesn’t prove DNS is broken. The key question is whether the core handles the subsequent connection. If LAN domains, games, or specific apps have compatibility issues, add a targeted fake-ip-filter after checking what the configuration does, or compare with another supported DNS mode. Reload the configuration after changes, then flush the DNS cache using your system’s standard method and reconnect the app. Don’t stack multiple DNS interception tools or replace all upstream addresses without a clear reason.