Clash: From Beginner to Advanced

1. Clash Core Concepts

How Clients, Cores, and Servers Work Together

Clash generally refers to an ecosystem of clients and configurations built around proxy cores, not one specific interface. A graphical client handles configuration imports, system proxy settings, node selection, and logs. The core listens on local ports, reads rules, and establishes connections. mihomo is a commonly used core in this ecosystem. A client opening successfully only confirms that the client started; it does not prove that the core is working or that a remote node is reachable.

A server node is a remote endpoint that forwards traffic. Installing a client does not provide usable nodes, and a subscription is not a proxy protocol—it is a way to deliver configuration or node information. Troubleshoot these separately: can the client manage the configuration, can the core accept connections, and can the node complete a remote handshake? Treating every issue as an installation failure often leads to repeated reinstalls without addressing the actual fault.

Trace a Request from Start to Finish

When an app makes a request, traffic reaches the core through the system proxy, the app's own proxy settings, or TUN. The core evaluates rules against the destination domain, address, and other conditions, then routes the connection through a direct policy or a proxy group. The group selects a node, which forwards the request to the destination. The response travels back the other way. Traffic entry, rule evaluation, and egress node are separate layers; enabling one does not mean the others are configured correctly.

In a configuration, proxies defines nodes, proxy-groups organizes how they are selected, and rules determine which policy handles a connection. Every name referenced by a rule must match a node, proxy group, or built-in policy. Similar-looking names are not interchangeable: capitalization, spaces, and punctuation can all affect references. When reading an unfamiliar configuration, start with the entry ports, then find the group names and final catch-all rule. This is more useful than memorizing fields from the first line down.

Distinguish Nodes, Policies, and DNS Results

A region in a node name is usually a provider's label; it does not prove where the egress IP is located. A latency test reflects the result of a specific probe, not overall download speed. A proxy group is a way to select a node, not another server. DNS resolves names to addresses and can also affect rule matching. Distinguishing these pieces helps explain why switching nodes, changing DNS, and editing rules produce different results instead of treating them as the same setting.

Configuration snippets in this guide cover individual fields. Unless explicitly stated, they are not complete subscriptions to import as-is. Existing configurations usually include nodes and client-specific settings that would be lost if you replaced the whole file. For unfamiliar terms, consult the Glossary; for your first connection, follow the Getting Started Guide in order. Establish a working baseline before adding advanced features so you have a clear point of comparison for every change.

2. Choose a Client for Your Platform

Start with Your Platform and How You Plan to Use It

For everyday desktop and mobile use, consider Clash Plus first, then compare other clients based on your platform and workflow. Choose based on OS compatibility, configuration management, required protocols, and traffic-capture capabilities—not screenshots. Before installing, check the platform and architecture in the Download Center. Don't assume that a button or menu name in a guide for one OS applies to another. The same rule concepts may carry over, but service installation, network permissions, and background operation often differ.

On Windows, compare Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is no longer maintained; treat it as an archived reference for existing setups, not the default choice for a new device. On macOS, options include Clash Plus, Clash Verge Rev, and FlClash. ClashX Meta should likewise be treated as an archived, unmaintained client. An app that still launches is not necessarily maintained: pay particular attention to new OS permission requirements and ongoing protocol compatibility.

On Android, options include Clash Plus, Clash Meta for Android, FlClash, and Surfboard. Surfboard uses a different configuration format from Clash YAML, so don't assume the same subscription will work in every client. For iOS, check the Clash Plus App Store listing. Its official website is clashplus.io. For Linux desktops, consider Clash Verge Rev or FlClash. On headless servers and routers, a standalone mihomo deployment is usually a better fit.

Check the Core in Use When Comparing Features

To verify protocol support, check both the core the client actually uses and the fields in the subscription. Seeing a protocol name in the interface does not mean the current core can parse every parameter provided by the service. When an import fails, keep the error details and client name; they're more useful than noting the app icon alone. Don't run multiple proxy cores at once to test compatibility: they may compete for ports, system proxy settings, or virtual adapters, preventing an otherwise valid configuration from working.

System architecture determines whether an installer will run correctly. Choose the build for Apple Silicon or Intel, as appropriate, and check the processor architecture on Windows and Linux as well. Android ARM64 and ARM packages are not interchangeable in every case; if unsure, check your device specifications and the download page. Installation failures can also result from OS requirements or restrictions on the installation source. Don't start by changing proxy settings—these issues occur before traffic forwarding begins.

Once you've chosen a client, get one app working before considering a migration. Keep the original configuration file, subscription source, and any important proxy group selections; copying node names from the interface is not enough. For a side-by-side comparison of platform options, see Client Comparison. After migrating, disable autostart and the system proxy in the old client so both apps don't take control of the network after the next reboot.

3. Install the Client and Check Ports

Set Up a Minimal Working Environment

Download the installer for your OS and architecture from the Download Center, then follow the system prompts. On first launch, locate the configuration page, core status, and logs. Don't immediately enable the system proxy, TUN, LAN sharing, and complex overrides all at once. The priority is to confirm that the client can start the core and locate the configuration it actually uses. If it requests a network extension or service permissions, review the prompt and grant what's needed rather than repeatedly dismissing security warnings.

Desktop clients may run the graphical interface and background service separately. Closing a window may not stop the core, and quitting the tray app may not remove the background service. Check for other running proxy apps before and after installation. If the interface reports a port conflict, identify the process using the port before taking action; don't randomly terminate every network-related process. On mobile, when prompted for VPN access, confirm that the requesting app is the client you just installed. Most systems allow only one standard VPN session to control this connection at a time.

Local Ports Are Not Node Ports

mixed-port is the local entry point that apps on this device use to connect to the core. It accepts both HTTP and SOCKS proxy requests. A node's server port is specified in its subscription entry and serves a different purpose. This example binds the local entry point to the loopback address, for use on this device only. The number is illustrative, not a universal default. When configuring an app to use the proxy, use the listening port currently shown by the client.

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

When a browser or tool uses the local proxy, the address is typically 127.0.0.1, and the port should match the core's actual listening port. Do not enter a remote node's address here. If other devices on your LAN need to use the proxy, assess the listening address, access controls, and firewall scope separately. Enabling allow-lan alone does not complete the setup. An exposed proxy can be used by other devices and consume your traffic allowance.

Check Service Status in the Startup Logs

On Windows, run Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue in PowerShell to inspect listeners and connections on this example port. On Linux, use ss -lntp to check what's listening. If nothing appears, confirm that the core started and that the client hasn't changed the port. If a listener does appear, verify which process owns it; a process using the same port is not necessarily the current client.

If the core exits immediately after starting, check the first configuration error in the logs. Later connection refusals are often just a consequence of the failed startup. Common causes include YAML indentation, duplicate fields, unreadable configuration files, and incorrect group references. Fix one issue, reload, and check the next first error rather than changing many fields at once. For system permission issues, use the client's service management controls instead of adding unrelated settings to the subscription file.

A successful installation means the core runs continuously, the current port has a known owner, the logs show no repeated restarts, and the system's regular internet connection still works directly. Save the configuration directory and startup method; you'll import a subscription in the next section. If the network stops working after closing the client, check whether the system proxy still points to a local port whose listener has stopped. Restore direct access before troubleshooting the installation so a stale proxy setting isn't mistaken for a system-wide network failure.

4. Import Subscriptions and Manage Configurations

Check What the Subscription Provides

A subscription URL may return a complete Clash YAML configuration, a node list only, or another format. A complete configuration typically includes nodes, proxy groups, and rules and can be imported as a selectable profile. A node collection may need to be paired with a provider in the main configuration. Base64 is just an encoding; it does not guarantee compatibility. Before importing, confirm which format the provider supports instead of simply checking whether the URL opens in a browser.

In the client's configuration or subscription page, add a remote profile, paste the full URL, and save it. Once downloaded, select that profile as the active configuration. Adding an entry without activating it is a common oversight. After activation, check that proxy groups appear and contain nodes rather than being empty. If the client shows download and update times, note the last successful status—but clicking Refresh does not prove that the server content was downloaded and applied.

Subscription URLs may contain access credentials, so treat them like account information. Hide the full URL in screenshots, and remove query parameters and authentication details before sharing logs. Don't paste a private subscription into an unfamiliar online conversion site; the service may be able to read the URL and node details. For format conversions, use an output format explicitly supported by the provider, or convert in a controlled environment and inspect the result.

Separate Local Changes from Remote Updates

The source file for a remote configuration is usually replaced on the next update, so edits made directly to its rules may not persist. Client features such as overrides, merges, or extensions can preserve local changes, but merge order varies by client. Before using them, confirm whether they append to an array or replace it, and inspect the final effective configuration. A rule appearing in the editor does not prove that it's in the file the core is currently reading.

This mihomo snippet defines a remote node collection and is only for setups where the provider supplies compatible content. The example domain illustrates the structure and does not provide real nodes; replace it with a valid URL of your own. The main configuration must also define a proxy group that references the provider. For a standard full subscription, use the client's remote configuration option rather than splitting it into multiple files yourself.

proxy-providers:
  remote:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote

Troubleshoot Update Failures and Switch Between Profiles

When a subscription update fails, determine whether the download failed or the response couldn't be parsed. For download failures, check the current network, subscription validity, and whether the request mistakenly depends on a proxy that isn't working yet. For parse failures, check whether the response is a webpage, login prompt, or unsupported format. Don't save an error page returned by the service as YAML and then try to fix its indentation. Keep the last working configuration so you have a clear fallback if an update fails.

Name profiles by purpose and record their source, compatible clients, and local extension locations. Proxy group names may change when you switch profiles, and previous node selections might not carry over; recheck the current mode and default group. Set automatic update intervals according to the provider's guidance—there's no need to refresh constantly by hand. For format differences, see Subscription URLs, YAML, and Base64 Explained. For organizing multiple configurations, see How to Manage Multiple Profiles.

5. Choose a Proxy Mode and Verify the Connection

Modes Choose a Policy, Not the Traffic Entry Point

Rule mode routes traffic according to the rules in the configuration and is suited to everyday traffic splitting. Global mode generally sends traffic that has entered the core to the global selector. Direct mode routes traffic entering the core through a direct policy. These modes determine how the core handles connections it has already received. If an app isn't using the system proxy and isn't covered by TUN, switching to Rule or Global mode won't make its traffic enter the core. That's a crucial distinction when troubleshooting.

The system proxy is a set of proxy settings provided by the OS to apps; it does not force all network connections through a proxy. Some apps follow it, others use their own proxy settings, and some connect directly. First test with a browser known to support the system proxy, then check other apps. An app or command-line tool bypassing the proxy does not by itself mean the system proxy is broken—it may not read that setting at all.

Check the Entry Point, Rule, and Egress

After importing a configuration, select a node in the main proxy group, enable the system proxy, and make a new browser request. Check the connection panel for the destination domain, matched rule, and policy chain. Existing long-lived connections may continue on their previous route, so create a new connection after switching nodes. If there is no corresponding request in the logs, check the app's traffic entry and proxy port before changing remote node settings.

You can explicitly specify the local HTTP proxy from the command line. Make sure the example port matches your actual configuration and that the destination service is reachable. Receiving an HTTP response only proves that this particular request used the specified entry point. To determine whether it went through a remote node, check the rules and connection records. If the rule selects DIRECT, traffic may still exit through your current network even though the command used the local proxy.

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

When testing websites, distinguish connectivity, egress IP, and service availability. A page loading does not mean all its resources use the same route, and a changed egress IP does not guarantee access to a particular service. Providers may restrict access based on account, region, device, or business policies. First confirm that a node can establish a connection, then compare how the service actually works. For guidance on latency and traffic multipliers, see How to Choose Clash Nodes.

Windows UWP Loopback and App Exceptions

Some sandboxed Windows apps are subject to network isolation and may not be able to reach a loopback proxy on the same device. Consider a UWP loopback exemption only after confirming that the app uses the system proxy, a browser test works, and the app's traffic is not reaching the core. If the client offers a loopback management tool, grant access to the specific app rather than changing settings for all apps. A loopback exemption addresses a local access restriction; it won't fix an invalid subscription, a timed-out node, or a rule pointing to the wrong policy.

If an app has its own proxy settings, check whether they conflict with the system settings. Turn off the system proxy before stopping the client so the OS doesn't keep connecting to a stopped port. If Global mode works but Rule mode doesn't, compare the policy chains and use the rules section to find the issue. If explicit proxy tests fail for every node, check the nodes and network first. For a first-run check, see the Connection Checklist; don't judge by the color of a single toggle.

6. Write Custom Clash Rules

Rules Match from Top to Bottom; the First Match Wins

Rules are ordered, not an unordered set of conditions. The core typically checks from top to bottom and applies the policy for the first match. Put specific exceptions before broad rules, and leave the catch-all rule at the end. Once MATCH catches all remaining connections, ordinary rules below it never get a chance to handle them. When changing traffic routing, check rule order and policy names—not just whether the syntax parses.

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, and GEOIP uses geographic IP data. Domain rules require the core to have the relevant domain information; address rules depend on the destination IP and related data. One domain rule cannot cover every access method. In particular, when an app connects directly to an IP, uses its own DNS resolver, or reuses connections, check the actual destination in the connection panel.

Test Rule Order with a Narrow Exception

This snippet sends documentation domains direct, routes code-hosting domains through PROXY, then handles Chinese IP addresses and remaining traffic. PROXY must already be defined in the active configuration. On the address rule, no-resolve prevents an extra DNS lookup just for that match; it does not disable DNS for the whole configuration. The example illustrates rule order only. Check each rule against your network and intended use.

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

After adding a rule, reload the configuration and make a new connection. Check the matched rule, destination domain, and final proxy group to confirm the change is active. If an earlier rule matches, adjust the order or narrow its conditions. If the destination appears only as an IP, check how the app resolves names and review the DNS path. For a service that uses several domains, don't add a rule for just the homepage; check connections for login, API, and resource domains as well.

Rule Providers and the Limits of Local Overrides

As your rule list grows, you can use rule-providers for rule collections and reference them in rules with RULE-SET. The collection's behavior type must match its contents; don't mix domain lists, IP lists, and classical rules indiscriminately. If a remote collection fails to update, the core may continue using its cached copy. Seeing a collection in the interface does not prove it was downloaded successfully just now. Check its update time, logs, and the rules matched by actual connections.

When merging subscription rules with local rules, the final order matters most. Some overrides replace the entire rules array; others insert rules at the beginning or end. Appending an exception after MATCH usually won't work. For long-term maintenance, keep local rules limited to clear, personal adjustments and record why each was added. Copying an entire external ruleset can add duplicates and outdated categories, making it harder to tell which layer needs fixing when something goes wrong.

Test rules with one request that should go direct and another that should use a proxy, so fixing one site doesn't disrupt other services. If you choose REJECT, make sure you're blocking the intended connection and not a dependency such as login. Remove private domains and internal network details before sharing a configuration. Once you're comfortable with common matches, try platform-specific conditions such as process rules. Process detection support and permission requirements vary by OS, so results on one device are not guaranteed to apply everywhere.

7. Configure TUN and DNS

How TUN Differs from the System Proxy

TUN uses a virtual network interface and routing to capture traffic, including some apps that ignore the system proxy. It is not a way to speed up nodes. Enabling it changes both the traffic entry point and DNS path, so do so only after a standard proxy connection works. Depending on the OS, TUN may require a background service, administrator privileges, or network extension approval; mobile clients usually use the system VPN interface. Available settings depend on the core used by the client and the options it exposes.

Before enabling TUN, make sure no other VPN or TUN app is controlling the same routes. Note whether your local network, internal domains, and key services work before turning it on, then compare them one at a time. Corporate VPNs, virtual machine subnets, and remote administration connections can conflict with automatic routing. Don't change routing in your only remote session; prepare a local console or a separate recovery path first so you don't lose access.

Treat DNS as an End-to-End Path

DNS involves more than setting a server address: consider which component makes the query, which route it takes, how the answer reaches the app, and when rules use the resolved address. In fake-ip mode, a domain is assigned a virtual address that the core maps to the real destination; it is not the node's egress address. Some internal services and device discovery features need real addresses. Set exceptions for those cases rather than disabling mapping for every domain.

This mihomo snippet demonstrates how TUN capture relates to built-in DNS. The DNS listener is restricted to the local loopback address, and whether the example upstream is reachable depends on your network. Merge it only while preserving existing nodes, rules, and client-specific settings. If the client already has DNS and TUN controls, adjust them in the interface first and check the resulting configuration to avoid two sources repeatedly overriding the same fields.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

The port in dns-hijack applies to the relevant traditional DNS requests; it does not automatically handle every encrypted DNS protocol. A browser or app that uses encrypted DNS may change which domain information is visible and how rules are evaluated. During troubleshooting, note these settings and temporarily use a consistent DNS path to compare results. If a DNS upstream requires a proxy, avoid a circular dependency where resolving the proxy node itself relies on that not-yet-established proxy connection.

Roll Back Based on Symptoms; Change One Layer at a Time

If all apps lose connectivity after enabling TUN, turn TUN off first and check whether the original system proxy setup works again. Then investigate routing, permissions, and logs. If domains fail but direct IPs work, focus on DNS. If only internal services fail, check private network routes and internal DNS. If one app is affected, examine its protocol and connection path. Change one layer at a time so you can tell which change fixed the problem.

After stopping TUN, check that the virtual interface, routes, and system DNS have returned to normal. A webpage loading again does not rule out stale connections in background apps, and stacking multiple traffic-capture tools to patch gaps is not a sound long-term fix. A thorough check covers regular web browsing, apps that ignore the system proxy, internal network access, and reconnection after waking from sleep. If you only need a proxy for your browser, the simpler system proxy setup may be all you need; there's no reason to expand the maintenance burden just to enable advanced options.

8. Maintain Configurations and Troubleshoot Issues

Keep a Working Baseline You Can Restore

The goal of routine maintenance is to know what's currently in use and be able to recover from a failed change. Record at least the client name, core source, active profile, local entry port, and override location. Keep remote source configurations separate from personal extensions, and back up rules that can't be recovered from the subscription. Backups may contain node credentials and subscription URLs, so store them securely rather than uploading them to a public repository or sharing them casually.

Client updates, core updates, and subscription updates are three separate changes. A client update may change service management or merge behavior; a core update may change supported fields; a subscription update may change nodes, group names, and rules. When a problem appears, first identify which layer changed most recently. Don't upgrade the client, replace the subscription, and rewrite DNS in the same troubleshooting session. Even if connectivity returns, the cause will be hard to identify or reproduce.

Break “No Internet” into Specific Symptoms

If there are no connection records at all, first check whether the app's traffic reaches the local entry point and whether the system proxy points to the correct port. If there are records but node connections time out, check node status, remote address reachability, and network restrictions. If name resolution fails, inspect DNS requests and node address resolution. A specific HTTP error means the connection may have reached a service; distinguish proxy authentication problems from destination-side refusals and account restrictions.

After switching networks or waking from sleep, old connections may still depend on an interface that's no longer available. Make a new request first, then try restarting the core; you don't need to delete the configuration immediately. If a public network requires a captive portal sign-in, complete that first and then restore the proxy. Otherwise subscription updates and node checks may fail together, making every route look unavailable. On mobile, check background restrictions and confirm that the OS isn't stopping the client process or network session when the screen locks.

Keep Logs Useful and Limit Their Scope

Use informational logging for everyday use. Temporarily increase detail when troubleshooting, reproduce the issue once, then restore the previous level. Leaving verbose logging on can increase disk writes and may capture domains, paths, and connection metadata. When reporting a problem, include the steps to reproduce, OS, time of the error, and a few relevant log lines. Remove subscription URLs, credentials, and private network details. “It doesn't connect” without the entry point, policy, or error type is rarely enough to diagnose the issue.

If a node probe succeeds but an app still fails, test with the same app or service and check whether it uses UDP, multiple domains, or its own DNS resolver. A probe target and the actual service are different destinations, so different results are not contradictory. Don't use Global mode as a long-term workaround for broken rules. Compare routes briefly if useful, then restore the intended mode and fix the relevant conditions so internal services, update servers, and other apps aren't routed unexpectedly.

At the end of a maintenance session, turn off debugging features you no longer need, remove duplicate startup entries, and confirm the system returns to the expected state when the client exits. Keep a short record of each successful change: which rule you changed, what symptom it addressed, and how you verified it. Check these notes next time instead of copying an unfamiliar configuration all over again. A stable configuration isn't defined by how many fields it has, but by whether each change has an observable reason and result.

9. Build a Verifiable Path to Advanced Use

Move from a Single Device to a Maintainable Setup

After completing the first eight sections, explore advanced topics to meet specific needs. If you switch nodes often, learn how proxy groups make decisions. If you maintain duplicate rules, look into rule providers. If you need an always-on service, learn command-line operation and service management. Don't copy every field from an external configuration into your own environment. A setting that makes sense on a router may not suit a mobile device; understand its prerequisites, permissions, and rollback method first.

In a proxy group, select is for manual choice, url-test compares candidate nodes using a specified probe, and fallback chooses according to availability and order. Automatic selection does not guarantee service quality, and a successful probe does not mean every destination will work. Specify the probe URL, check interval, and candidate pool, and avoid frequent tests just to watch rankings change. If you need a consistent service region, manually pinning a suitable route may work better than frequent automatic switching.

Validate a Command-Line Deployment Before Running It as a Service

On a headless Linux system, first test the configuration in the foreground and confirm the logs and file paths. Then set it up under a service manager such as systemd. Keep the program's working directory separate from its configuration directory, and use a stable location for relative rule-provider paths. The commands below assume mihomo is on your executable path and the current directory contains a complete configuration. Passing a syntax check only means the configuration can be read; it doesn't guarantee that nodes, DNS, or destination services are reachable.

mihomo -t -d ./mihomo-data -f ./config.yaml
mihomo -d ./mihomo-data -f ./config.yaml

Once foreground operation works, configure the service user, working directory, configuration path, and restart policy according to your OS. Avoid running everything as a privileged user by default. If TUN requires specific network capabilities, grant only what's necessary for the deployment. When checking service logs, distinguish a process exit from a failed network request; an invalid configuration will not fix itself by restarting repeatedly. For a comparison of desktop and command-line setups, see Two Ways to Deploy Clash on Linux.

Assess Management Interfaces and Network Sharing Separately

The external controller is a management endpoint, not a regular proxy entry point. If you need a control panel, restrict it to localhost or a trusted network and configure appropriate authentication; never expose it directly to the public internet. LAN proxy access also needs its own access scope and firewall rules. The controller, subscription credentials, and proxy authentication protect different things. Setting up one does not secure the others, so check each listening address separately.

A router or gateway deployment affects other devices and carries much greater risk than a single-device setup. Start with a test device and an out-of-band rollback plan. Confirm how subnets, DHCP, DNS, and egress routing fit together before expanding the traffic capture. Working IPv4 does not mean the IPv6 route is also correct, and one successful webpage test says nothing conclusive about UDP. Each expansion should cover direct traffic, proxied traffic, and internal network services—not just one external website.

Finish by creating an acceptance checklist for your environment: core startup, subscription updates, direct rules, proxy rules, DNS, network changes, and recovery after the client exits. Change one major variable at a time and keep the before-and-after logs and configuration diff. If an experiment fails, restore the last known-working setup before investigating. To repeat the shortest connection workflow, return to the Getting Started Guide. To switch clients, check the Download Center first; changing apps is not a universal fix for network problems.