Clash FAQ
Config & Troubleshooting

The core parses configuration, matches rules, and establishes connections. A GUI client manages subscriptions and settings, and displays logs. mihomo continues the Clash.Meta development line, and its supported protocols and fields don’t fully match those of the original Clash. Settings may be located in different places depending on the client, so note the client name, core type, and operating system when troubleshooting. Matching interface versions don’t guarantee that two devices support the same protocols.

The client is a connection tool; its installer usually doesn’t include usable remote connection details. A subscription or config file provides server addresses, authentication parameters, proxy groups, and routing rules. Before importing, confirm that the provider’s format is supported by your core. A webpage or account dashboard isn’t a subscription URL. Subscription URLs may contain account credentials, so don’t post them on forums, include them in screenshots, or submit them to online converters. If you need help, share only an error description with sensitive details removed.

Rule mode checks the configuration’s rules in order. The matched policy determines whether a connection is proxied or goes direct, making this the best choice for everyday use. Global mode sends connections handled by the core through the selected global policy. It can help you quickly check whether a routing rule is causing an issue, but it doesn’t automatically capture traffic from every app. Direct mode connects to destinations without a proxy for traffic handled by the core; it doesn’t quit the client. When troubleshooting is done, switch back to Rule mode and make sure no temporary test option is still selected in a global or rule-based policy group.

A system proxy registers a proxy address with the operating system and affects apps that follow that setting. Some apps use their own proxy settings or ignore the system proxy entirely. TUN uses a virtual network interface and routing to capture eligible traffic, making it a better fit when you need to cover other apps, but it depends on permissions, routes, and DNS settings. When setting things up, first test the subscription with the system proxy, then enable TUN if needed. Running both at once isn’t necessarily better; test them separately when troubleshooting so you can identify where traffic enters.

In the client, open Subscriptions, Config, or Profiles, choose the option to import from a URL, paste the full subscription URL from your provider, and download or update it. Seeing a config name doesn’t mean it’s active: set it as the current config, confirm that its policy groups contain selectable outbound options, and choose a suitable node. Then switch to Rule mode, enable the system proxy, and use a browser to access the service you need. If you see a parsing error, check the subscription format first rather than repeatedly changing your connection password.

Check the core log first to distinguish a permissions issue from a virtual adapter creation or route setup failure. Windows clients typically require service mode to be installed and running. On macOS, you may need to approve a network extension or grant administrator access. On Linux, requirements depend on the client service and network management permissions. Prefer the client’s service installation option, and don’t run all your apps with elevated privileges long-term. If you’re using another VPN or virtual network adapter, disconnect it and test again. Once permissions are confirmed, check your TUN settings.

Keep the field name and line number from the error log, then inspect the surrounding lines. YAML indentation must use spaces and stay consistent at each level; add a space after list markers, and check colons, quotes, and policy group names. If the error reports an unknown proxy type or unsupported field, check what your core supports instead of just changing indentation. Back up the config, make one change at a time, and reload it. Subscription-generated configs may be overwritten on the next update, so make lasting changes through the client’s override or merge feature.

Startup launch only means the client will try to start. It doesn’t necessarily enable the system proxy, TUN, or a background service. After restarting, confirm that both the client process and core are running, then check that the current config has loaded, the system proxy is enabled, and the TUN service is working. On some desktop systems, startup apps launch only after you sign in. If the network isn’t ready yet, a subscription update may fail; wait for the connection, then update manually so a startup timing issue isn’t mistaken for an invalid subscription.

Use the client’s rule override, extended config, or config merge feature instead of editing temporary files generated by a subscription download. Rules are usually matched from top to bottom, so put specific domains before broad rules and the final catch-all rule. The target policy name must exactly match an existing policy group. Save and reload, then check the connection list to see which rule matched the request. Existing connections may keep using the old policy, so create a new connection to verify the change. Keep a backup so you can restore it if traffic is routed incorrectly.

A latency test measures how long a request to a specific test address takes. It doesn’t show available bandwidth or predict how every service will perform. Download speeds also depend on server load, network congestion, packet loss, the destination site, and your local connection. Compare nodes on the same network, against the same destination, and at similar times. First check whether the service opens reliably, then assess sustained transfer speeds. Don’t keep switching nodes based only on the lowest ping. If only one site is slow, check which rule and outbound policy its traffic actually uses.

Both devices must be on a LAN where they can reach each other. On the computer, allow LAN connections, make sure the listener isn’t restricted to the local loopback address, and allow the proxy port through the firewall only on trusted networks. On the other device, enter the computer’s LAN IP and actual mixed-port value—not 127.0.0.1. A manual HTTP proxy usually covers only apps that follow that setting; it doesn’t route all traffic. Turn off sharing when you’re done to avoid exposing an uncontrolled proxy on a public network.

Fake-IP mode assigns domains addresses for internal mapping, allowing the core to associate later connections with their domain and apply routing rules. These aren’t the destination servers’ real addresses, so a DNS lookup result alone doesn’t prove DNS is broken. If printers, NAS devices, or internal domains aren’t working, check your local DNS and domain suffix first. Then configure fake-ip-filter and the relevant resolution policy according to your core’s documentation. Clear the relevant DNS cache and reconnect after making changes so old cached results don’t skew your tests.

Check your device’s clock and basic internet connection, then ask your subscription provider to confirm your account, subscription validity, and whether the URL has been reset. A 401 usually indicates an authentication failure; a 403 means the request was denied, but check with the provider for the specific cause. If you get a login page instead of config content, obtain the correct subscription URL. For timeouts, check whether subscription updates use a direct or proxied connection. Don’t post the full URL publicly or enter it on an untrusted converter site to try to fix it.

Turn off the proxy first and confirm your local network can connect to the internet. Then check that the config updated successfully and your device’s clock is correct. If the test address is unreachable, all nodes may appear to time out, so check access to real services alongside the core logs. If only one node fails, check its status. If all connections fail during DNS resolution or the handshake, check DNS, authentication details, and core protocol support in turn. Change one thing at a time and disconnect other VPNs; changing the port, DNS, and mode all at once makes the cause hard to identify.

Check the client’s connection list first. If a connection appears but goes direct, check your rules and selected policies. If there’s no record, check whether the app uses the system proxy. Browser extensions, in-app proxy settings, and proxy bypass lists can override system settings. Make sure the proxy address and port in your OS match the current listener, especially after changing mixed-port. Command-line tools may also use their own proxy environment variables. Once a regular browser request reaches the core, consider TUN for apps that don’t follow system proxy settings.

Some AppContainer apps are isolated from the network and can’t access a local loopback proxy directly. First confirm that a regular desktop browser can reach the destination through the same proxy. Then use the client’s UWP loopback tool to add an exemption only for the apps that need it; this usually requires administrator access. Not every Store app is a UWP app, and not every connection failure is caused by loopback restrictions. If an exemption doesn’t fix it, check the connection logs, the app’s proxy support, and firewall settings. Don’t grant access to every app in bulk.