A proxy client built with Flutter and powered by the mihomo core. Find downloads and look up configuration fields based on the settings you use.
Free forever
Open-source code
Documentation in Chinese
mode: rule
INTERFACECross-platform Flutter interface
ENGINEmihomo (Clash Meta) core
LICENSEGPL-3.0 open-source license
Settings and traffic flow
The client manages configuration; the core parses rules and establishes connections. The window below is a static settings illustration. Its values explain how the fields relate and do not represent default settings after installation. Select a feature to see its relevant settings and limitations.
Settings
System proxy
TUN mode
Allow LAN connections
Mixed port7890
Outbound modeRule / Global / Direct
Active configurationSubscription + local overrides
DNS modefake-ip
IPv6
Log levelinfo
Rule mode and proxy group selection
mode: rule routes connections by matching rules from top to bottom, then sending each connection to the associated proxy group on the first match. Domain suffixes, destination addresses, and rule providers can each route traffic through a proxy or directly. After importing a configuration, check that the groups contain available outbounds, then review connection logs to confirm which rules matched. Unlike a global proxy, rule mode can keep local services on a direct route. Rule names must reference existing proxy groups. Place custom rules before fallback rules so they are not preempted.
Traffic routing beyond the system proxy
The system proxy works for apps that honor the operating system's proxy settings. TUN uses a virtual network interface to capture traffic that matches its routing conditions, making it useful for some command-line tools and apps that ignore system proxy settings. Before enabling it, check administrator permissions, virtual network interface authorization, and whether another VPN is active. Routing, excluded subnets, and DNS settings also affect what gets captured, so the switch alone cannot confirm that every app is proxied. For troubleshooting, establish a working baseline with one capture method, then add TUN to avoid changing several variables at once.
Keep subscription updates separate from local changes
Subscription files provide nodes, proxy groups, and rules; local overrides preserve device-specific settings. Changes made directly to a file generated from a remote subscription may be overwritten on the next update. To pin a port or add rules, first check the client's override options, merge order, and final effective configuration. Maps and lists may be handled differently, and appending is not the same as replacing. When migrating another Clash client's configuration, check that the core supports its protocol fields; a similar interface does not guarantee full configuration compatibility.
Proxy access from devices on the same network
allow-lan controls whether LAN connections are accepted, while mixed-port provides a port that listens for both HTTP and SOCKS traffic. Before sharing access, check the listen address, firewall, and devices' subnet. On other devices, enter the host's LAN address and port. Enabling LAN access alone does not configure other devices to use the proxy. This setup is useful for temporary testing on trusted networks. Restrict allowed sources and configure authentication as needed; do not expose the listening port to the public internet through router port forwarding.
DNS resolution and connection matching
Fake-IP assigns synthetic addresses to domains, then the core uses its mapping to identify connection targets so domain rules can route traffic. These are not real server addresses, and Fake-IP is not the same as encrypted DNS. If local device discovery, corporate intranet access, or a specific app stops working, check the DNS servers, fake-ip-filter, and how system DNS is intercepted. IPv6 also depends on address resolution and actual routing; changing just one field may not be enough. Choose between Fake-IP and redir-host based on network requirements rather than assuming one mode is always faster.
Trace errors to the stage where they occur
log-level: info is suitable for everyday monitoring. Temporarily switch to debug for closer inspection, then restore the previous level once you have reproduced the issue. A port conflict occurs while listening; DNS failures happen during resolution; a connection timeout also requires checking the destination and outbound. Timestamps, matched rules, and proxy groups are more useful for diagnosing issues than repeatedly switching nodes. Remove subscription URLs, credentials, and private domain names before sharing logs. Client logs describe runtime behavior; a single error does not prove that the entire network is unavailable.
Settings determine what traffic is captured, rules determine where it goes, and proxy groups determine the outbound used. Check all three together. If a browser works but a terminal does not, first check whether the terminal uses the system proxy. If only some domains fail, inspect DNS and rule matches instead of immediately reinstalling the client.
Choose a download for your operating system, then select a client and processor architecture. FlClash offers clients for Windows, macOS, Android, and Linux. The iOS link points to another app in the Clash ecosystem, not an iOS build named FlClash. Different clients may use similar core configuration, but system permissions, subscription merging, and background behavior vary and should be checked separately.
For your first installation, keep only one client running. Quit the old client and check that the system proxy has been restored before launching the new one. This helps avoid port conflicts, stale proxy settings, and duplicate traffic capture. Before upgrading or migrating, save local rules and override files; a subscription link may not include every setting stored on your device.
For desktop work and development. Check your processor architecture in system information first. After installation, review firewall prompts and check whether the mixed port is already in use. The system proxy is usually a good starting point for a basic connection; enable TUN only if your apps need it.
Choose a build for Apple Silicon or Intel. On first launch, follow the system prompts to authorize the app. If connections fail, check the proxy status in Network settings and make sure no other network extensions are still running.
Check your device architecture and system requirements before installing. The first connection requires VPN authorization. If the app stops working in the background, review battery optimization and background activity permissions. Running another VPN app at the same time may change which traffic is captured.
The download page links to Clash Plus on the App Store and the official site at clashplus.io. After installation, follow the app's setup flow to add a configuration and approve VPN access. Check that your subscription format is supported before importing; desktop settings may not carry over directly to mobile.
Desktop users can choose a graphical client by distribution and package format; server and router users can explore the core section. A desktop system proxy may not cover terminal processes, so check environment variables, listening ports, and service permissions separately.
The download page brings together client options, system requirements, and maintenance status. Choosing an installer and configuring network access are separate steps; even with the right build, you still need to import a valid configuration.
Start with one verifiable connection, then add rules and advanced settings. This is a preview of the recommended sequence; see Getting Started for exact steps and common snags. Installing a client does not automatically provide a working proxy service—you still need a usable configuration.
01 / PROFILE
Import a valid subscription or local configuration
Add a subscription URL in configuration management, or import an existing YAML file. Once it finishes downloading, select it as the active configuration and check that its proxy groups appear. A URL opening in a browser does not guarantee that it returns a compatible configuration. If import fails, determine whether the cause is an unreachable network, a login page, or invalid YAML.
Subscription URLs may contain access credentials, so keep them private. After the first import, test the original configuration before adding complex overrides. If the node list is empty, check the subscription's validity and response content; the appearance of a connection button does not confirm that the configuration imported successfully.
02 / ROUTING
Choose an outbound and capture method
Start in rule mode and select an available outbound from a proxy group in the configuration. On desktop, begin with the system proxy; if you need to cover apps that ignore it, configure TUN by following a guide. On mobile, approve VPN access when prompted by the operating system. Avoid running another VPN at the same time, as both may compete to capture traffic.
Rule mode routes traffic according to the configuration, global mode is mainly useful for comparison and troubleshooting, and direct mode bypasses proxy outbounds. Switching modes will not fix an expired subscription or add missing nodes. Change one setting at a time and note the results before and after to identify which field actually affects the outcome.
03 / VERIFY
Check what matched after connecting
Connect, visit the destination you want to test, then check its domain, matched rule, and outbound in the connection log. Test both a local service and a destination that should use the proxy to confirm the capture scope. If some apps work and others do not, first check whether the failing apps use the active proxy route instead of repeatedly running speed tests or switching nodes.
Connection timeouts, DNS failures, and port conflicts occur at different stages. Note when the issue happened and save the relevant logs, then check the corresponding settings. After quitting the client, also check whether the system proxy has been restored. Otherwise, apps may still point to a local port that is no longer listening, making the whole network appear to be down.
If you already have a configuration for another Clash client, keep a copy of the original file. Migrate gradually, checking nodes, proxy groups, rules, and DNS along the way instead of copying every client-specific setting at once.
FlClash is a graphical client in the Clash ecosystem, with a cross-platform interface built using Flutter. To understand how the projects relate, distinguish the client, the core, and the configuration format: the interface imports configurations, displays status, and manages settings; the core handles resolution, rules, and connections. Two apps using mihomo do not necessarily share the same override order, permission handling, or configuration storage location.
Clash Meta is a historical name commonly encountered when researching this ecosystem; mihomo is the name currently used by the related core project. When following an older guide, map its intended action to the current fields, then check whether your client provides the same option. Menu labels in a guide may no longer match your installation, and claims about core capabilities should be verified against the project's documentation.
Open-source repositories provide a verifiable record
FlClash source code, commit history, release notes, and issue discussions are available in the project repository. The open-source license describes the terms for use and distribution; commits show code changes; and the issue tracker is for reproducing and discussing specific behavior. These sources are more useful than feature labels alone when checking whether a setting applies, but open-source status is not a promise of compatibility with every network environment.
Before reporting an issue, note your operating system, capture method, reproduction steps, and the stage where the error occurs. Include logs only after removing sensitive information. Do not share full subscription URLs, proxy credentials, or configurations containing private addresses. A clear, minimal reproduction helps distinguish an interface issue from core behavior or invalid subscription content—and avoids rounds of guesswork based on screenshots alone.
Check client upgrades and subscription updates separately
A client upgrade typically changes the interface, packaging, or bundled core; a subscription update fetches configuration content again. These operations affect different things. If a protocol field is unrecognized, check whether the core supports it. If nodes have expired or the subscription returns an error, check the subscription service. An app upgrade will not extend a subscription, and refreshing a subscription is not a substitute for upgrading the app.
Before upgrading, note the mixed port, capture method, and local overrides, and save a recoverable copy of your configuration. Afterward, check in order that the configuration loads, proxy group selections are preserved, and the system proxy or TUN captures traffic as expected. If the problem occurs only on a specific network, compare DNS, routing, and firewall conditions before considering a rollback. Avoid upgrading, changing subscriptions, and rewriting rules all at once, or it will be harder to pinpoint the cause.
Use the downloads page to find software, the configuration reference to check behavior, and Getting Started to build a minimal working setup. Each addresses a different need: choosing, understanding, or configuring. To compare client configuration management and platform support, visit Choosing a Client and pick based on your use case, not just the interface.
Configuration and troubleshooting articles
Articles are listed by publication date, newest first. If you've already made your first connection, explore subscription parsing, DNS modes, and client selection. If you haven't imported a configuration yet, start with Getting Started to establish a working baseline before making advanced changes.
Troubleshoot expired subscriptions and parsing failures in four stages: URL accessibility, response format, YAML syntax, and node protocol compatibility. Each section explains what to check and how to fix it. First confirm what the server actually returns, then decide whether to change network settings or configuration fields instead of blaming every import error on the client.
Learn how Fake-IP address pools and domain lookups work, and how redir-host differs in resolution timing and leak risks. Includes fake-ip-filter syntax and LAN scenarios where Fake-IP may not be suitable. Understanding the difference between synthetic addresses, real DNS results, and final outbounds makes it easier to see why domain rules do—or don't—match.
Compare popular clients across core updates, platform support, interface, and subscription and override management. Find recommendations for desktop work, mobile, Linux servers, and more. Start by identifying your operating system and configuration needs, then compare everyday workflows to reduce the effort of reworking rules and permissions after migration.