FlClash FAQ and Troubleshooting

FlClash is a cross-platform graphical client built with Flutter. It manages subscriptions, edits configurations, switches policies, and controls the system proxy. The mihomo core handles protocol connections, rule matching, DNS processing, and TUN forwarding. When troubleshooting, distinguish interface settings from core status: an interface that opens normally does not mean the core started successfully.

FlClash is available for Windows, macOS, Android, and Linux. Use the download center as the source of truth for available packages and architectures. Windows typically offers a standard desktop installer; macOS users should choose between Intel and Apple Silicon builds; Android users should select a package matching the device architecture; Linux users should confirm the format and permissions for their distribution and desktop environment.

Rule mode matches domains, IPs, processes, or rule sets from top to bottom according to the configuration's rules, then sends traffic to the corresponding policy group. It is the best choice for everyday use. Global mode sends most manageable traffic through one proxy policy, making it useful for temporarily testing a node. Direct mode bypasses the proxy and helps determine whether a problem comes from the local network or the proxy path. Switch back to Rule mode after testing.

A subscription URL is a remote configuration endpoint published by a service provider. A configuration is the complete YAML content fetched and parsed by the client. A node is a specific proxy outbound defined in that configuration. A policy group organizes multiple nodes or other policy groups for manual selection, automatic testing, or failover. After importing a subscription, select the configuration and choose the node to use in its policy group.

Open the configuration or subscription page, choose Add from URL, paste the complete subscription URL, save it, and run an update. After the download succeeds, select the newly added configuration and wait for the core to finish loading. Then open the proxy or policy page and choose a node. If the URL returns a login page, error page, or empty response in a browser, confirm its status with the subscription provider instead of repeatedly importing it.

First confirm that the FlClash core is running, then verify that the system proxy switch was actually written to Windows settings. Some browsers, downloaders, and development tools use their own proxy configuration and may ignore the system proxy. Check whether a browser extension is overriding the proxy settings as well. Try disabling the app's manual proxy, restarting the target program, and comparing the exit IP on a detection page. If nothing changes, use TUN mode to narrow down the cause.

TUN creates a virtual network interface and changes routing, so desktop systems generally require administrator privileges. On Windows, exit the client and restart it as an administrator. On macOS, approve the network extension or follow the system authorization prompts. On Linux, confirm that the kernel supports TUN, the current user has the required network capabilities, and the device node is available. Restart the core after granting permission instead of repeatedly toggling the switch.

Some UWP apps are affected by app-container network isolation and may be unable to reach a local listening address even when the system proxy is enabled. Look for the UWP loopback option in FlClash's tools or system settings and remove the loopback restriction for the Store apps that need network access. Fully exit and reopen the target app afterward. If only one app fails, also check whether it uses private DNS or private-network restrictions.

Enable automatic updates in the subscription or configuration details, then choose a reasonable interval based on the provider's schedule. Refreshing too often will not make nodes faster and may trigger rate limiting. If the subscription requires a proxy to update, assign an available policy to the update task. If the current configuration is invalid, switch to a configuration with working connectivity or temporarily use Direct mode, then run one manual update and inspect the returned error.

Client latency tests usually measure the time needed to connect to a specified test address. They reflect reachability and response speed at that moment, not actual download bandwidth. Repeated timeouts mean that at least one of the node, test address, or local network is unavailable; occasional high latency may be caused by network jitter. Consider page loading, real transfers, and multiple test runs together instead of choosing a node based on a single latency number.

First make sure dns.enable is enabled in the configuration, and confirm that nameserver, fallback, or nameserver-policy points to trusted, reachable DNS services. When using TUN, also check whether DNS hijacking covers system requests. If domain resolution fails, temporarily disable the browser's secure DNS and clear the system DNS cache before trying again. Avoid running multiple local DNS tools at once, as requests may bypass the intended path or cause port conflicts.

Open the connection log and find the website's domain, destination IP, matched rule, and final policy. Clash rules are matched from top to bottom, so a broad rule placed too early may intercept a later, more specific rule. Check whether the domain was resolved to an IP and then matched an IP rule, and verify that the rule set downloaded successfully. When adjusting overrides, start with a narrow test rule rather than changing the entire rule order at once.

Copy the subscription URL into a browser or another controlled environment and confirm that it still returns configuration content. Common causes include an expired or reset URL, an endpoint requiring a particular network, DNS failure, an update request incorrectly routed through an invalid proxy, or a response that has become a login page. Once the URL is confirmed valid, remove leading and trailing spaces in FlClash, switch the update proxy or temporarily use Direct mode, then run a manual update and inspect the log.

Switch to Direct mode first to confirm that the local network and DNS are working, then check the system clock, subscription validity, and core log. When every node times out at once, suspect local network restrictions, DNS, a stopped core, an unreachable test address, or an invalid subscription before deleting nodes one by one. You can also change the test address and close other proxy tools to rule out port conflicts and chained proxy loops.

A successful connection only indicates that the node handshake may have completed; DNS, rules, and the route to the target site still need checking. Test the same node in Global mode first, then compare it with another node. If an IP address works but the domain does not, focus on DNS. If only a specific website fails, inspect its matched rule and policy in the connection log. In system proxy mode, confirm that the target app follows system settings; in TUN mode, check routing and the virtual network adapter.

Start with the first clear error in the startup log. For a port conflict, close other Clash clients, proxy tools, or programs using the same mixed-port, and change the port in the configuration if necessary. For configuration parsing errors, check YAML indentation, spaces after colons, duplicate fields, and unsupported fields. Validate the configuration before restarting the core. If TUN is enabled, also verify permissions and the virtual network adapter status.