Clash from Zero to Mastery: Clients, Subscriptions, and Rule-Based Routing

1. Core concepts: clients, cores, and traffic flow

The first step in understanding Clash is not memorizing configuration fields, but separating three layers: the client interface, the proxy core, and the external subscription service. The client displays configuration files, proxy groups, connection status, and system switches; mihomo is the core that parses YAML, matches rules, and establishes proxy connections; the subscription service supplies one or more sets of nodes and routing policies. Different applications may use similar interface labels, but different cores, configuration formats, or system-interception methods can produce different results.

A typical web request is handed by an application to the system network stack, then enters the core through the system proxy, enhanced mode, or TUN interception enabled by the client. The core reads the active configuration, processes DNS, matches rules, selects a proxy group, and establishes an outbound connection before returning the response to the application. In rule mode, a domain may be resolved by DNS first or matched directly by name; the exact behavior depends on the DNS mode, sniffing settings, and configuration syntax. Therefore, seeing that the client is running does not mean every application is using the proxy.

1.1 The difference between configuration files, proxy groups, and nodes

A node is a specific outbound connection definition containing a server address, port, and protocol parameters. A proxy group selects from multiple nodes or other policy groups; common types include manual selection, automatic selection, failover, and load balancing. A configuration file combines proxies, proxy groups, rules, DNS, ports, and related settings. One node can be referenced by multiple proxy groups, and one proxy group can include another group as a member. If a policy group appears without usable options, the nodes may not have parsed successfully, or the referenced names may not match the actual proxy names.

A proxy port and a mixed port are not interchangeable. An HTTP port accepts HTTP proxy requests, while a SOCKS port accepts SOCKS requests; a mixed port usually supports both common protocols. System proxy settings generally need a mixed port or the HTTP port explicitly identified by the client. If the control port is entered by mistake, the browser may report a connection failure even though the client itself is still running. The control port is for external APIs or interface communication, not ordinary web traffic.

1.2 Establish an observable troubleshooting sequence

When troubleshooting, follow this order: determine whether the application sent the request, whether the system handed it to the client, whether the client matched a rule, whether the proxy group selected a valid outbound, and whether the remote connection succeeded. Do not begin by changing numerous DNS or rule settings. First inspect the target domain in the client’s connections, logs, or request list. If there is no record at all, the issue is likely with the system proxy, TUN, or the application’s own proxy support. If the request is logged but matches DIRECT, the configuration is behaving as written and the rule order should be checked. If it reaches a proxy group but every connection fails, investigate the nodes, network, and TLS.

2. Choose a client: install by platform, core, and interception scope

Choose a client by platform and intended scope first, then by interface preference. Windows, macOS, and Linux generally need a desktop client for system proxy settings, configuration management, and log viewing. Android requires support for the mobile VPN interface, while iOS uses the App Store to install Clash Plus. For servers, transparent routers, or environments that need long-running background operation, running the mihomo core directly is more suitable, although it lacks the graphical configuration tools of desktop clients and requires more maintenance.

This site places Clash Plus first for each platform because it offers broad coverage and suits users who prefer a consistent workflow. Clash Verge Rev, FlClash, Clash Nyanpasu, ClashX Meta, and other clients each focus on different platforms. Software that is no longer maintained may still run on older devices, but it should not be the first choice for a new installation. Before installing, verify the system architecture and package format: Windows commonly uses an installer or archive, macOS requires choosing between Intel and Apple Silicon, and Linux requires a format supported by the distribution.

2.1 Three checks before installation

First, check the platform architecture. A Windows ARM64 device cannot directly run software built only for AMD64, and Apple Silicon and Intel versions should not be mixed on macOS. Second, check the client’s permissions. System proxy settings, startup launch, and TUN commonly require additional system privileges; opening the installer successfully does not mean those permissions have been granted. Third, verify the configuration source. Copy the URL only from a trusted subscription entry point, and do not paste a web page URL, control-panel URL, or an entire block containing extra instructions into the subscription field.

After the download finishes, launch the client without immediately enabling the system proxy, TUN, and browser extensions at the same time. First confirm that the interface loads and that configuration files or an empty configuration list are visible, then proceed one setting at a time. This leaves only one variable per step, making it clear whether a problem comes from installation, import, or system interception. Installation paths, log paths, and configuration storage locations vary by client. When moving to another device, prefer the client’s export function rather than copying an unknown cache directory.

2.2 The trade-off between graphical clients and running the core directly

Graphical clients suit personal computers because they provide configuration updates, proxy-group switching, connection logs, and system-proxy controls. Running the core directly suits routers, servers, and containers: files and commands reduce desktop dependencies, but you must handle process supervision, file permissions, log rotation, and packet forwarding yourself. The configuration concepts are similar, but a desktop button should not be assumed to correspond to a directly reusable command-line argument.

3. Import subscriptions: generate, update, and roll back configurations

A subscription URL is essentially a URL that returns configuration content. After requesting it, a client may receive complete YAML, an encoded collection of nodes, or a configuration generated by the server for a particular client type. Import it through the client’s Subscription Management, Configuration Files, or a similar entry point rather than treating the URL as an individual node. After the first import, check that the configuration name, proxy count, proxy groups, and rules appear before enabling it.

Before importing a subscription, keep a copy of the currently working configuration. Many clients overwrite the old file during an update; if the new content is empty, malformed, or uses different proxy-group names, a rollback file can restore a working state. After updating, do not rely only on a success message. Open the configuration details and check the update time, parsing status, and proxy-group members. Some providers return HTTP success with a login page or error message in the body. In that case, the client may report only a parse failure, so inspect the response content from the subscription URL to find the real cause.

3.1 The minimum checks after importing

First, check whether proxy groups have members. Common primary-group names include “Node Selection,” “Proxy,” or a provider-defined name; different names do not imply different functions. Second, check that the group’s current selection is a real node or an available child policy group, not a deleted name. Third, check that rules are present. A configuration without rules can still work in global mode, but in rule mode requests may all fall through to the default policy. Fourth, check that the DNS section fits the current network, especially with fake-ip enabled: LAN devices and some local services may need additional rules.

More frequent subscription updates are not necessarily better. An update downloads the configuration again, rebuilds proxy groups, and may trigger node health checks. For everyday use, follow the provider’s recommended schedule; if the configuration is stable, there is no need to click repeatedly just because the client displays a reminder. When an update fails, keep using the old configuration, record the time and error text, and then check connectivity, subscription permissions, URL encoding, and the type of response returned by the server.

3.2 A layered approach to configuration files

Think of a configuration as three layers: a base file, subscription content, and local overrides. The base file defines shared settings such as ports, logging, and DNS; subscription content supplies nodes and proxy groups; local overrides adjust rules, add LAN direct connections, or change the mode. Clients differ in the names and merge behavior of override features, so confirm the final generated configuration before editing rather than inspecting only a fragment in an editor. If the client supports configuration validation, validate the file after saving and before enabling it.

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

proxies: []
proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Node Selection

The snippet above shows the configuration skeleton: the mixed port handles local HTTP and SOCKS requests, rule mode processes requests in order, LAN access is not exposed externally by default, and the final MATCH acts as a fallback. It is not a complete configuration for any subscription provider and cannot replace the node content supplied by that provider. When editing YAML, pay close attention to indentation, spaces after colons, and list nesting; one stray tab or incorrect indent can make the entire file unparsable.

4. Proxy modes: how to verify rule, global, and direct connections

The proxy mode determines how requests enter policy selection. Rule mode matches the rules from top to bottom and passes a match to the specified proxy group. Global mode usually sends every request to one proxy group instead of relying on domain rules to choose DIRECT or a proxy. Direct mode bypasses the proxy. Button labels vary slightly between clients, but the verification method is the same: inspect the active mode, selected proxy group, and actual result for an individual request together.

Rule mode is suitable for everyday use because LAN traffic, commonly used services in mainland China, and destinations that require a proxy can be handled separately. Global mode is useful for short tests: when the rule result is uncertain, send the target to a known working proxy group to determine whether the problem is the rule or the connection itself. Direct mode helps establish the underlying network condition and diagnose whether the proxy is causing certificate, DNS, or login problems. Switch back to the appropriate mode after testing, or browser behavior may differ from normal.

4.1 Confirm that the mode is working from the logs

After selecting a mode, open the connection log and visit a clearly defined test URL or refresh an existing page. The log typically shows the requested domain, matched rule, selected proxy group, and final outbound. If the request matches DIRECT, first check whether rule mode is active and whether a rule explicitly requires a direct connection. If it reaches a proxy group but the page will not open, switch to another working node in that group and see whether the error changes. If no request appears in the log, traffic has not entered the client; check the system proxy, the browser’s separate proxy settings, TUN status, or whether the application uses its own network path.

Do not use “the page opens” as your only verification. A browser may use cached data, IPv6, its own proxy settings, or an existing connection. Disable the cache and reload, or confirm in the client’s connection log that a new request was actually made. For command-line testing, explicitly specifying the proxy port is more reliable than depending on system environment variables:

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --socks5-hostname 127.0.0.1:7890 https://example.com/

The first command uses an HTTP proxy; the second uses SOCKS5 and resolves the domain through the proxy. If the HTTP command fails but SOCKS5 succeeds, the port protocol or client listener may be mismatched. If both fail, inspect the node connection and logs. The domain in the example is only for demonstrating command syntax; for real testing, choose a reachable target that permits command-line requests.

4.2 The difference between system proxies, application proxies, and TUN

A system proxy usually affects browsers and desktop applications that honor the system setting. It is easy to enable and disable, but programs that ignore system proxies may still connect directly. An application proxy is configured inside the program; browser extensions, development tools, and terminals may each use a different entry point. TUN intercepts traffic at a lower network layer and provides broader coverage, but it involves virtual adapters, system permissions, routes, and DNS, so configuration errors have a wider impact. Start troubleshooting with the system proxy, and consider TUN only after confirming that the target application is covered.

5. Rule-based routing: match order, proxy groups, and custom rules

The key to rule-based routing is order. The core evaluates rules from the top; once a request matches, evaluation stops and the request is handed to the policy group or action on the right, such as DIRECT or REJECT. A broad rule placed first can therefore override a more precise rule below it. When creating a custom rule, define the target and scope first, choose the rule type second, and place it correctly last. Do not add a broad MATCH rule merely because one domain fails to open.

Common rule types include DOMAIN for an exact domain match, DOMAIN-SUFFIX for a domain and its subdomains, DOMAIN-KEYWORD for keyword matching, IP-CIDR for IPv4 ranges, IP-CIDR6 for IPv6 ranges, GEOIP for IP geolocation matching, and PROCESS-NAME for process-name matching. Support for process names, network stacks, and sniffing varies across core versions and platforms, so confirm the capabilities of the active client first. The broader a rule is, the more likely it is to match unintended traffic; prefer exact domains or clearly defined suffixes.

5.1 How to organize proxy groups

A useful structure separates “manual selection” from “purpose-based routing.” The manual-selection group contains concrete nodes or an automatic-selection group and determines the current outbound. Purpose-based groups send categories of requests to the manual-selection group, DIRECT, or another group. For example, ad blocking, LAN traffic, streaming media, and fallback requests can each have their own group. When nodes change, only the manual-selection group needs adjustment while the rule structure stays stable. If every service group lists many nodes directly, name changes after a subscription update create maintenance work in multiple places.

Proxy-group names are reference keys in the configuration and must match exactly, including capitalization, spaces, and punctuation. The following example shows a small structure:

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Automatic Selection
      - DIRECT

  - name: Automatic Selection
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - Node One
      - Node Two

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,Node Selection
  - GEOIP,LAN,DIRECT
  - MATCH,Node Selection

A url-test group tests availability according to its configuration and selects the member with the better result, but reachability of the test URL does not guarantee that every destination is reachable. The interval should not be set too short either. A select group is chosen manually. The node names in the example must actually exist in the proxies section and cannot be copied into a configuration that has no such nodes.

5.2 How to validate a custom rule

After adding one rule, do not immediately add another. Save and reload the configuration, visit a domain clearly within the target scope, and confirm the rule text and proxy group in the log. If it does not match, the domain may use a different suffix, the request may use an IP address, DNS results may not have been sniffed, or an earlier rule may have handled it first. If it matches but the connection still fails, rule matching has succeeded; inspect the proxy group and outbound connection instead of continuing to edit rules.

When there are many rules, use comments to divide them by purpose, but do not place unparsable explanatory text in critical fields. For rule sets generated by a subscription, first confirm their update status and reference names before adding local rules. If local and subscription rules conflict, decide which has priority and check the final configuration again after updates. The FAQ on this site covers common troubleshooting paths for empty proxy groups, ineffective rules, and subscription update failures.

6. TUN mode: virtual adapters, DNS, and system traffic interception

TUN mode receives system-level traffic through a virtual network interface and forwards it according to the core’s configuration. It can cover applications that ignore system proxy settings, making it useful when endpoint traffic needs centralized handling. At the same time, it operates closer to the system network layer than a normal system proxy and changes routing and DNS behavior when enabled. TUN is not a “faster proxy mode”; it is a different traffic entry point. Before enabling it, make sure the ordinary system proxy works and that the client has permission to create a virtual interface.

Enabling TUN usually involves three issues: device permissions, route interception, and DNS. Desktop systems may request administrator approval, while Android establishes a local VPN through the system VPN permission. Linux may require kernel modules, capabilities, or root access. Route interception determines which destinations enter TUN; the meanings of settings such as auto-route and strict-route vary by client and core configuration. Incorrect DNS handling can send domain resolution through the local network, causing rule decisions to differ from actual connections or preventing LAN domains from resolving.

6.1 A recommended activation order

First disable unnecessary third-party VPNs, network accelerators, and browser proxy extensions to prevent virtual interfaces from competing. Confirm that the client can reach a test target through ordinary system-proxy mode, then enable TUN and grant the requested system permission. After activation, test the LAN gateway, an ordinary website, and a destination that clearly requires a proxy. Observe resolution, connection logs, and changes in rule matches for each. If only LAN access fails, check LAN rules, route exclusions, and DNS first. If all networking fails, disable TUN and restore the system proxy before investigating permissions and the virtual interface.

On mobile devices, a VPN icon only shows that the system VPN has been established; it does not mean the configured nodes are usable. Per-app proxying may let some applications bypass the VPN, and battery optimization may stop it in the background. On Android, check background battery restrictions, the always-on VPN option, and the app-routing list. On iOS, network interception depends on the system extension provided by the app itself, so desktop TUN concepts should not be applied directly to mobile devices.

6.2 Understanding DNS behavior and fake-ip

fake-ip mode assigns virtual addresses to domains so the core can continue applying rules by domain name. It is useful when consistent domain identification is needed, but some LAN domains, local printers, corporate intranets, and applications that require real addresses may be incompatible. For such cases, add LAN suffixes, private addresses, or specific domains to DIRECT or fake-ip-filter as appropriate; use the fields documented for the active configuration and client. Do not disable all DNS handling to fix one LAN device. Narrow the scope of the problem first.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

This configuration illustrates how common fields relate to one another; it does not replace the complete DNS server list required by a real platform. Whether stack, auto-route, and enhanced-mode are available depends on the supported range of the active core. After editing, run a syntax check and change only one field at a time. If TUN cannot start on a particular platform, disable enhanced mode in the client settings and return to the system-proxy path for everyday use.

7. Everyday maintenance, troubleshooting, and advanced paths

Stable use depends on three principles: rollback, observability, and minimal changes. Rollback means keeping the most recent configuration that connected successfully. Observability means knowing where to check logs, rule matches, and system-proxy status. Minimal changes means adjusting one related setting at a time. With these principles in place, most failures can be narrowed to configuration parsing, system interception, rule evaluation, or the remote connection, without repeatedly reinstalling the client.

7.1 A repeatable troubleshooting sequence

First confirm that the client process and active configuration are correct. If the configuration did not load successfully, restore the last parsable file. Second, check the listening port, whether another program is using it, and whether the application expects HTTP, SOCKS, or a mixed port. Third, confirm that requests enter the client by checking the connection list or log; if there is no record, do not change the nodes yet. Fourth, confirm the rule match and proxy-group selection, distinguishing DIRECT, REJECT, proxy groups, and empty groups. Only then investigate node connections, DNS, TLS, and the remote service.

If the browser reports a proxy connection failure, first check that the system proxy still points to the local machine and the correct port. If only one application fails, check whether it uses a separate proxy, its own DNS, or is blocked by a firewall. If every application fails but the client log contains no requests, the problem is at the interception layer. If the log shows a refused connection, investigate the proxy group or node. Only after a connection is established but certificates or page content are wrong should you examine TLS, system time, the certificate chain, and the target site’s response.

7.2 Configuration updates and log management

Before updating a subscription, record the configuration name and current proxy group. Afterward, compare group names, node counts, and rule status. Do not treat node count as a quality metric, and do not assume a longer list means a better configuration. Temporarily increase the log level while troubleshooting, then return it to a moderate setting to avoid generating excessive files. Desktop clients store logs in different locations; when an error repeats, copy a short section containing the time, target, and cause rather than uploading the full configuration or a subscription URL containing account information.

Configuration files may contain sensitive content generated by a subscription. Before sharing logs or requesting help, remove subscription URLs, authentication details, unnecessary identifying fields from node addresses, and local paths. You can retain field names, rule order, port types, and error text so others can understand the structure, but do not publish the complete access URL. If you suspect that a subscription URL has been exposed, regenerate it on the provider’s server rather than merely clearing browser history.

7.3 Moving from personal computers to advanced configurations

After mastering the basics, progress in this order: learn rule mode and proxy-group references, understand the boundaries of DNS and fake-ip, then study TUN, routing, and LAN exclusions, and only afterward consider router, transparent-router, or server deployment. Each step should build on the previous one and be verifiable. Copying a complex configuration directly into a local setup often introduces several unknown variables at once, making it difficult to tell whether a failure comes from core capabilities, platform permissions, or configuration syntax.

Router deployment also requires attention to forwarding paths, gateway placement, DHCP, IPv6, firewalls, and which devices bypass the router. If the core listens only on localhost, LAN devices cannot access it; exposing it directly to an untrusted network expands the management and proxy entry points. Server deployments require process supervision, log rotation, and upgrade rollback. A desktop client’s “system proxy” button cannot replace a router’s traffic-forwarding rules. For this part, validate the setup in an isolated environment before gradually moving it into a home network.

7.4 Troubleshooting record template

For each troubleshooting session, record the platform, client name, current mode, whether TUN is enabled, whether the configuration was just updated, the target domain, the error text in the log, and the one change already attempted. This is far more useful than saying “it suddenly stopped working” and prevents repeating the same path. For further reading, start with the categorized answers in the FAQ, then return to the corresponding chapter here. Specific cases such as Windows UWP loopback restrictions, HTTPS certificate errors, and proxy-mode differences are also covered in Windows UWP apps not using the Clash proxy and Troubleshooting HTTPS certificate errors.

Clash configuration capabilities come from several layers working together. Reliable use is not about memorizing a template that never changes, but about building habits of observation and verification. Stabilize the basic connection first, then add rules, DNS, and TUN gradually; keep a record of every change and a rollback point for every update. To install a package, visit the Clash download page and choose your platform. For first-time setup, return to the quick-start tutorial to complete the main workflow.