This snippet shows the field hierarchy, not a complete proxy configuration. PROXY contains only DIRECT for now; to use it, import working nodes and add them to a proxy group.
Platforms
5
Core
mihomo
Configuration
YAML
Core protocol
GPL-3.0
Clash client downloads by platform
Check your operating system and processor architecture before choosing a GUI client. Clash Plus is the featured option for Windows, macOS, Android, and iOS; on Linux, start with Clash Verge Rev. Clients handle configuration and system integration, while the core parses fields and establishes connections. Similar interfaces don't guarantee identical configuration support.
Windows
A good fit for desktop users who want system tray controls, system proxy support, and easy profile switching. If you're looking for a Clash for Windows alternative, compare Clash Plus and Clash Verge Rev, and check architecture requirements, service permissions, and TUN support. Keep your existing configuration before migrating; import it and test it before replacing your current setup.
Check System Information to see whether your Mac has Apple silicon or an Intel processor, then choose the matching installer. System proxy and network extension permissions vary, so follow the client prompts on first launch. You can migrate an existing configuration, but review startup behavior, proxy handling, and local file paths in the new client.
Mobile clients typically route traffic through the system VPN interface. Check your device architecture before installing and approve the system prompt before connecting. If the connection drops when the screen locks, check battery optimization and background restrictions. Per-app proxying is a client feature; it is separate from YAML rules that route traffic by domain or destination address.
Open the Clash Plus App Store listing from the download page; the official site is clashplus.io. After importing a subscription, check that the client recognizes its nodes and proxy groups before allowing it to add a VPN configuration. Some low-level network settings available on desktop may be managed by the system on mobile, so check the features supported by your client.
Desktop users can compare Clash Verge Rev and FlClash, choosing a package for their Linux distribution. For servers and routers, see the mihomo core options and manage services and configuration paths yourself. Before enabling transparent proxying, understand the routing, DNS, and permission requirements. When working remotely, keep an administrative connection available for recovery.
The installer provides a client, not a working proxy service. Subscription URLs often contain credentials, so keep them on trusted devices and remove sensitive values before sharing configuration files or logs. Browse all clients →
Configuration field guide
A connection's path has six layers: entry point, mode, DNS resolution, nodes, policies, and rules. Use this guide to work through them in order, with a plain-language answer followed by the relevant YAML. Each example is a standalone snippet, not a complete subscription; manually selecting a field stops automatic rotation.
Port fields define a local listening endpoint, not the port on a remote node. port accepts HTTP proxy connections, socks-port accepts SOCKS connections, and mixed-port accepts both on the same port. This example listens on the local machine only; configure the app to use the local address and the corresponding port. A common mistake is starting the core without setting the app to use the proxy. Another is having two clients compete for the same port. Before allowing LAN access, check the bind address, firewall, and authentication—not just one toggle.
mode: rulelog-level: info
rules:
- GEOIP,CN,DIRECT
- MATCH,PROXY
How do I choose a mode?
For everyday, rule-based routing, use rule; the core chooses an exit according to rule order. global uses the GLOBAL policy, while direct connects without a proxy. The mode applies to connections that reach the core; it does not automatically route every app through the proxy. Global mode also doesn't guarantee traffic uses a remote node—check the current GLOBAL selection. You can temporarily switch modes to compare results while troubleshooting, but note the original setting first. A client may change the mode through its runtime API, so the value in the configuration file may not match the active mode.
fake-ip returns a mapped address to the app, allowing the core to associate later connections with the original domain. redir-host returns the resolved IP address instead. These modes affect domain recognition and app compatibility; they don't speed up a node. This example enables the core's DNS, but whether system queries reach it also depends on the client's DNS interception settings. If a LAN device or specific app misbehaves, first check the query path and cache, then consider excluding the domain. Changing the enhanced mode without checking system DNS may leave the actual resolution path unchanged.
How are proxies different from a subscription URL?
proxies stores settings for individual proxy nodes; a subscription URL retrieves a configuration or a set of nodes. A node typically needs a name, protocol, server, and port; authentication and transport fields vary by protocol. This example points to a local SOCKS service to illustrate the structure—it isn't a working remote node. Common mistakes include putting a subscription link in the server field, using the wrong data type for a port, or selecting a protocol unsupported by the current core. Once defined, a node must also be referenced by a proxy group or rule to carry traffic.
proxy-groups combines nodes and other proxy groups into selectable exits. select lets you choose manually, url-test selects based on probe results, fallback checks entries in order for an available option, and load-balance distributes connections according to a strategy. Choose a probe target that reflects what you actually need; a lower result in one test doesn't mean everything will be faster. This example depends on the previously defined example-socks. Names must match exactly, groups must not reference each other in a loop, and a group name should not be mistaken for a protocol type.
rules are checked from top to bottom. Once a rule matches, its policy is applied and later rules are not checked. Put specific domains and LAN addresses before broader rules, and use MATCH as the catch-all at the end. The target policy must be an existing node, proxy group, or built-in action. If an app behaves unexpectedly, check the domain, destination address, and matched rule in the connection details instead of adding duplicates. Domain recognition also depends on DNS and how traffic enters the core; valid rule syntax alone doesn't guarantee a match.
For your first setup, get the shortest path working: the configuration loads, a policy has an exit, and the app can connect. Don't change ports, DNS, TUN, and rules all at once. Change one layer at a time so you can identify the cause if something breaks. Here are the three steps in the full Getting Started guide.
Import a configuration
Open the client's configuration or subscription manager and add a subscription URL from a trusted provider, or import a local YAML file. After it updates, check that the configuration is selected and that nodes and proxy groups appear. If parsing fails, inspect indentation, colons, and list structure near the reported line; reinstalling the client won't fix invalid content. A successful subscription download also doesn't guarantee that every node can connect.
Choose a mode and exit
Start in rule mode, find the main proxy group referenced by your rules, and select a working node. On desktop, enable the system proxy and check that its port matches the current client; on mobile, allow the VPN connection when prompted. TUN is useful for apps that ignore system proxy settings, but it involves routing and permissions. Get the standard proxy path working first so an app interception issue isn't confused with a node failure.
Verify the connection
Open the target site and check the client's connection list for the app, destination domain, matched rule, and final exit. A page loading doesn't prove traffic was routed as intended, and a successful speed test doesn't guarantee a specific site will work. If the browser works but the terminal doesn't, check whether the terminal reads proxy environment variables. If everything times out, check the local network and node status first. Turn off any extra logging you enabled for testing.
Keep a verified working configuration, then add app-specific routing or automatic policies one step at a time. You can switch back to the baseline to see whether an issue comes from a new change or the network. Read the full guide →
The Clash ecosystem and mihomo core
To determine whether a configuration will work, check core and field support—not just the client name. This site organizes client downloads and Chinese-language field explanations; it is not affiliated with or endorsed by any client development team. Open-source code, project documentation, and runtime logs are the best sources for verifying how features behave.
Project history and compatibility
The Clash ecosystem has continued to develop through community forks since the original project stopped being maintained. YAML files, policy selections, and local settings from an older client may not transfer unchanged to a new one. mihomo carries forward and extends related configuration capabilities, but older cores may not recognize newer protocols or fields. When using an example, check which core its documentation targets before applying it to your setup.
Clash for Windows and ClashX Meta are marked as archived, unmaintained entries in the download list. For a new device, consider an actively maintained option. If you depend on an older setup, check system compatibility and protocol requirements rather than choosing by a familiar interface alone. See how to choose a client →
Clients, cores, and service providers
Clients handle configuration imports, tray menus, subscription updates, and system proxy settings. The core reads configurations, resolves domains, matches rules, and creates outbound connections. Service providers maintain remote servers and subscription content. Each can fail independently. A connected status in the interface confirms only a local state; it doesn't prove the remote service is available or that every app's traffic is being routed.
If a node behaves differently across clients, compare the core, protocol parameters, and DNS interception method. If the same client behaves differently on different networks, consider the network operator, routing, and server-side restrictions. Isolating the problem by layer is more likely to produce a repeatable answer than replacing the entire configuration.
Open-source licensing and project references
mihomo is released under the GPL-3.0 open-source license. Its source code, commit history, and issue discussions are available in the project repository. The core's license does not mean every GUI client uses the same license; check each project's terms before distributing or modifying it. Open-source code makes implementation review possible, but it doesn't replace checking the software's source, permissions, and network behavior.
When investigating a field's behavior, start with the relevant documentation, then verify it against logs. When reporting an issue, include your operating system, client name, core details, a minimal configuration, and reproduction steps. Don't share full subscription URLs, credentials, or connection records that could identify you. A concise reproduction makes it easier to distinguish configuration problems from software bugs.
Updates and configuration retention
Client updates, core updates, subscription updates, and rule resource updates are four separate operations. Updating a client may also change its core; updating a subscription may replace nodes and proxy groups; updating rule resources affects only the corresponding match sets. Before updating, check which layer will change and keep a rollback copy of your configuration and custom content.
For long-term maintenance, manage remote subscriptions separately from local overrides and document what each rule does. After proxy group names change, check that custom rules still reference valid targets. If you change DNS mode, clear the relevant cache if needed before testing so old mappings don't skew the results. Once the configuration loads, verify the update with a real connection.
Browse the mihomo source code
If Git is installed, run the command below to clone the public repository for review. Cloning the source code does not install or launch a client. Most users can choose a GUI client directly from the download page.
Use the field reference to look up individual settings; these articles walk through how to investigate specific problems. Here are the three latest by publication date, covering system proxy access, log evidence, and managing multiple configurations.
If websites or command-line tools still bypass the proxy, check browser extensions and proxy settings, the terminal's http_proxy environment variable, and alternatives such as TUN mode.
Learn what each log-level setting outputs, how to interpret common messages such as dial tcp timeouts, i/o timeout, and unmatched rules, and how to use logs to track down a problem.
Learn what Profile means in a client, how remote subscriptions differ from local YAML files, and how to name, update, and switch between multiple configurations while preserving custom rules.