The client imports configuration, provides controls, and manages connections. The mihomo core parses rules, establishes proxy connections, and handles DNS. Understand the difference before deciding which layer to adjust. The snippets below illustrate the syntax; they are not complete configurations that can replace a subscription.
Connections follow the first matching rule
Rule mode maps domains, addresses, or rule sets to traffic policies. The core checks rules from top to bottom and stops at the first match, so specific domains usually belong before broader rules, with catch-all rules last. DIRECT means connect without a proxy; REJECT blocks the connection. Proxy policies must reference a node or policy group that actually exists in the configuration. Unlike global mode, rule mode lets you choose an exit for each type of traffic. If a site does not behave as expected, check the matched rule in the connection log before changing its order. Avoid changing several conditions at once.
Manage exit selection separately from routing rules
Policy groups give rules a stable target name and can contain nodes or reference other policy groups. Use manual selection for a fixed exit, or automatic testing to choose a reachable route based on test results. A latency test measures one request to a specific address; it does not represent download bandwidth or the speed of every site. After importing a subscription, check that the group has usable options and that your rules reference it. This example shows a manual group only. In practice, replace the direct option with a node name from your configuration, matching it exactly.
Check DNS resolution and connection routing separately
DNS determines how a domain resolves to an address; routing rules determine which path a connection takes. Check both. Enabling DNS in the core does not mean the operating system and every app will use it. Browser secure DNS, the system resolver cache, and other networking tools can change the actual path. fake-ip mode uses mapped addresses to preserve domain information; troubleshoot compatibility issues against the specific app. This example enables only a local listener and basic resolution. Record the original settings before making changes, then reconnect and confirm that DNS requests reach the intended resolver instead of relying only on whether a page loads.
System proxy works with apps that honor proxy settings. TUN uses a virtual network interface and route control to capture a wider range of connections. It is useful when you need to handle traffic from multiple apps, but also involves system permissions, network interfaces, and DNS routing. First confirm that a standard proxy connection works, then grant the client the service permissions it needs. Automatic routing is not a universal solution; check for route conflicts, especially if you already use a VPN, virtual machine networking, or a secondary router. If your connection drops, turn off TUN to restore the original route and check the logs rather than repeatedly switching nodes.
YAML uses indentation to define structure. Incorrect keys, list markers, or policy references can prevent a configuration from loading. Subscription updates often regenerate the configuration, so direct edits to generated files may be lost on the next update. For rules you need to keep, use the client's supported override feature where possible. When troubleshooting, note the error line, current configuration, and action that triggered the issue, then restore settings one at a time. Keep logging at a reasonable level for everyday use and revert temporary increases promptly. Before sharing logs, remove subscription URLs, credentials, and personal browsing records; include only the context needed to explain the issue.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
Start with your operating system and processor architecture, then compare client interfaces and features. Similar names do not guarantee the same installers, configuration extensions, or update methods. If you are new to Clash, start by comparing Clash Plus. Linux desktop users can look at Clash Verge Rev first. Installer details are on the downloads page; this page provides links by platform.
Windows
Check your processor type in system information first. After installation, import a subscription, confirm that a policy group is available, and then enable the system proxy. Set up service mode and TUN only if you need to capture traffic from more apps. Troubleshoot firewall prompts, occupied ports, and leftover proxy settings separately. Archived clients are for legacy compatibility; software that is no longer maintained should not be the default choice for a new device.
Check About This Mac to see whether your device has an Apple silicon or Intel processor, then download the matching build. On first launch, follow the system prompts to authorize network features, then check the menu bar status and active configuration. If connections fail after waking from sleep or switching networks, check the proxy and network service status first. The archived ClashX Meta download is listed separately from actively maintained clients.
Use an installer that matches your device's architecture. When starting a connection, confirm the system VPN permission. Typically, only one VPN service can run at a time in the same user profile. If a background connection drops, check battery optimization, background activity, and the manufacturer's power-saving restrictions. Per-app proxying and routing all device traffic are different settings; test changes in the apps you intend to use.
Clash Plus is available on the App Store. Its official website is clashplus.io. After importing a configuration supported by your service provider, confirm system VPN permission and select a policy. Whether a connection works also depends on subscription validity, node reachability, and your current network. The system VPN indicator shows connection status; by itself, it does not confirm that all requests are routed as expected.
For desktop environments, choose Clash Verge Rev or FlClash and check which package format your distribution uses. Whether system proxy settings take effect depends on the desktop environment and app support; command-line tools may need separate configuration. Server and router users can use the mihomo core and manage the service, configuration directory, and permissions themselves without installing a desktop interface.
Import a subscription and connect for the first time
A client is not a proxy service. Before you begin, get a valid subscription URL or configuration file and confirm that your provider supports the selected client's configuration format. Do not submit subscription URLs to unfamiliar conversion sites; they may contain credentials that grant access to your account.
Install a client and import a configuration
Open the client's configuration or subscription page and choose to import from a URL or local file. Save it and wait for the configuration to load, then check that proxy groups and nodes appear. If you see a parsing error, make sure the downloaded file contains configuration data—not a login page, error message, or format intended for another client. Do not enable the system proxy yet.
Choose a policy and enable a connection method
Choose an available exit in a proxy group and start with rule mode for everyday use. On desktop, enable the system proxy; on mobile, allow the VPN connection when prompted. Enable TUN separately if needed, and check its permissions. Change one setting at a time and keep the original state available so you can tell a node issue apart from a local routing problem.
Test connections and keep troubleshooting details
Visit the site or app you actually need while checking the matched rule and exit on the connections page. Then test a destination that should connect directly to confirm that not all traffic follows the same route. If the latency test passes but a page will not load, check DNS, the destination service, and whether the app supports proxies. Turn off the system proxy before exiting the client to avoid leaving an unreachable local proxy configured.
The Clash ecosystem and the open-source mihomo core
When choosing a client, distinguish the project, the core's capabilities, and the service provider. The same toggle may work differently across clients; check the actual core and the relevant project's documentation to confirm support for a configuration option.
Project history and naming
The Clash ecosystem includes separate projects for proxy cores, graphical clients, and configuration tools. After the original Clash project stopped being publicly maintained, the community continued developing related implementations for compatible configurations and new features. mihomo continues the development line of the Clash Meta core. A client with Clash in its name is not necessarily maintained by the same team or built on the same core. To check a project's status, review its own releases, issue discussions, and documentation rather than judging by its name alone.
Open-source licenses and project resources
The mihomo code is released under the GPL-3.0 license. Its repository provides source code, issue tracking, and release history—useful resources for understanding feature changes, investigating known issues, and checking configuration syntax. The core's open-source license does not mean every graphical client, app store app, or subscription service uses the same license. Read each project's license before using, modifying, or distributing its code. For everyday use, the published documentation can help with troubleshooting; you do not need to compile the code yourself.
Clients, cores, and subscription services
A graphical client turns user actions into configuration and displays logs, connections, and policy choices. The core processes traffic, while a subscription service provides nodes and related settings. Installing a client does not make a subscription valid, and a successful node test does not guarantee that a particular service will work. When something goes wrong, identify whether the failure is in configuration download, parsing, network access, or the remote connection. This helps keep expired accounts, destination-site restrictions, and local settings from being mistaken for one another.
Update order and recovery
Client updates, core updates, subscription updates, and rule database updates are separate operations. Before updating, save a working configuration and any custom overrides, read the release notes, then verify your existing rules and commonly used apps. If the new configuration fails to load, restore the last working version. If only one site has a problem, check its matched rule instead of immediately reinstalling the entire client. Keep persistent custom settings in an override location explicitly supported by the client so subscription refreshes do not overwrite them.
Configuration guides and platform troubleshooting
Get a basic connection working first, then consult guides for the specific issue. Latency readings, system proxy status, and matched-rule records describe different parts of the connection; no single metric can confirm that the entire route is working.
Explore the URL Test handshake, test URL selection, and timeout behavior. Learn why low latency does not mean high bandwidth, and how to assess node quality using page loads, file transfers, and real-world traffic.
Follow each step, from choosing an installer and authorizing service mode to enabling the system proxy. Covers security software blocks, occupied ports, and UWP loopback issues, with checks organized by where the failure occurs.
Learn where geodata files come from, how to configure automatic updates, and how to replace files manually. Covers GEOIP and GEOSITE matching, and explains why database loading and rule order need to be checked separately.
