The Complete Clash User Guide

Understand Clash Core Concepts First

Before taking action, separate the concepts of client, core, configuration file, subscription, node, proxy group, and rule. Many seemingly complex problems come from mixing up two of these layers. A client launching successfully does not mean a usable configuration is available. A successful subscription import does not mean that configuration is active. Even with a configuration selected, you still need to choose the node used by the proxy group. And once the system proxy is enabled, only applications that honor system proxy settings will automatically send traffic to Clash. Checking this chain one layer at a time is more effective than repeatedly reinstalling everything.

What the Client, Core, and Configuration Each Do

The client is the graphical interface you interact with. It handles subscription imports, setting changes, connection logs, and system proxy control. The core is the program that parses the configuration and processes connections; Mihomo is one commonly used compatible core. Configuration files are usually YAML text containing ports, proxy nodes, proxy groups, rules, DNS settings, and more. When a graphical client starts the core, it passes the currently selected configuration to the core. As long as the syntax is valid, the core processes traffic in the order defined by that configuration.

Failures at these three layers look different. If the client will not open, check installation, permissions, and system compatibility. If the client opens but reports a configuration parsing error, inspect the YAML format or subscription content. If the core is running but webpages do not load, continue by checking the system proxy, proxy group selection, rule matches, and node availability. Identify the affected layer first instead of attributing every problem to a failed node.

How Subscriptions, Nodes, and Proxy Groups Relate

A subscription URL is a remote address provided by the configuration provider. After requesting it, the client receives the configuration content and saves it locally. A node is an individual proxy endpoint in that configuration, typically containing a server address, port, and protocol parameters. A proxy group organizes multiple nodes and can select among them manually, by latency testing, or through failover logic. Rules generally point to a proxy group such as “Node Select” or “Auto Select,” rather than directly to a node; the group then determines the final endpoint.

Seeing a node list does not mean the current connection is using one of those nodes. First select the subscription configuration, then open the proxy page and inspect the main proxy group, switching it to an appropriate node. If the group is set to DIRECT, matching connections go straight to the destination. If it is set to REJECT, they are refused. With automatic selection, the result depends on the group’s test URL, interval, and candidate nodes. Node sources are not part of the client itself, and Clash does not generate usable routes automatically after installation.

System Proxy and TUN Coverage

The system proxy is a set of proxy address settings provided by the operating system. Browsers and many desktop applications read these settings and send HTTP or SOCKS connections to Clash’s local listening port. It is simple to configure with a clearly defined scope, making it the best starting point for first-time use. Some games, command-line tools, store apps, and software with custom network stacks do not read the system proxy, so they may continue connecting directly even when the switch is enabled.

TUN mode receives more system traffic through a virtual network interface, so its coverage is usually broader than the system proxy. It also involves administrator privileges, routing tables, DNS interception, and compatibility with network security software. The safest order is to verify the subscription and nodes through the system proxy first, then enable TUN if needed. Changing the subscription, DNS, rules, and TUN all at once makes it difficult to identify the source of a problem.

Choose a Client by Platform and Usage

The Clash ecosystem includes multiple graphical clients and cores that can run independently. Choose based first on the operating system, then on whether you need TUN, rule editing, subscription management, a desktop tray, or other features—not simply on interface appearance. The download page groups options for Windows, macOS, Android, iOS, Linux, and the Mihomo core, and its client list matches the recommendations here. For first-time use, choose a graphical client with clear maintenance status and complete controls. Consider running the core directly only for servers and routers.

Recommended Approach by Platform

Clash Plus supports Windows, macOS, Android, and iOS, making it the recommended cross-platform option in this guide. It suits users who want similar workflows across devices and provides common subscription and proxy settings in one place. Windows users can also choose Clash Verge Rev, FlClash, or Clash Nyanpasu. Clash for Windows is no longer maintained and should be limited to existing setups or legacy configuration migration, not used as the starting point for a new installation.

On macOS, alternatives to Clash Plus include Clash Verge Rev and FlClash. ClashX Meta is no longer maintained; existing users should export or record their subscription details before moving to a maintained client. On Android, options include Clash Plus, Clash Meta for Android, FlClash, and Surfboard. Mobile operating systems impose tighter limits on background activity and battery usage, so check VPN permissions, background activity, and battery optimization after installation. On iOS, use the App Store version of Clash Plus; see the iOS download section for the relevant entry.

For Linux desktop environments, choose Clash Verge Rev or FlClash. On headless servers, software routers, and containers, you can run the Mihomo core directly, but you must prepare the configuration, service management, and log access yourself. Running the core alone does not provide a graphical interface or configure the desktop system proxy, so it is better suited to users who already understand ports, routing, and configuration structure.

Graphical Client or Standalone Core?

Graphical clients are suited to everyday desktop and mobile use. Subscription updates, proxy group switching, connection inspection, and system proxy and TUN controls are all available in the interface, making the current state easier to verify when something goes wrong. A standalone core suits environments managed with systemd, Docker, or scripts. The benefit is deployment flexibility; the trade-off is maintaining configuration paths, startup arguments, log rotation, and restart policies yourself.

If you only need browsers and everyday apps to access the network according to rules, do not choose a core simply because it offers “more features.” Learn rule mode, proxy groups, and connection logs with a graphical client first, then migrate to a server environment when needed. Conversely, if the target device has no desktop, must run continuously, and receives configuration from an automated system, a graphical interface is unnecessary.

What to Preserve When Migrating from an Older Client

When migrating from Clash for Windows or ClashX Meta, the most important items to preserve are the original subscription URL and any custom override rules you wrote. Do not copy only the client cache directory: different clients organize configuration directories, databases, and interface settings differently. If the subscription is still accessible, importing it again by URL in the new client is usually safer. If the configuration contains local rule sets or scripts, back up those files separately and verify that the new core supports their syntax.

After migration, close the old client to prevent both programs from changing the system proxy or competing for the same port. Check the taskbar, menu bar, and background processes to ensure only one core remains, then start the new client. Import the subscription, select the configuration, choose a proxy group, and enable the system proxy in that order. Keep the old client temporarily for comparison if needed, but do not run both at once.

Complete Installation, Permissions, and First Launch

The goal during installation is not to change every advanced setting immediately, but to put the client, core, and system permissions into a verifiable state. After installation, launch the client once and confirm that the main interface opens, the core is running normally, and no port conflict is reported before importing a subscription. If an error appears on first launch, resolve installation or permission issues first rather than masking a lower-level failure with repeated configuration imports.

Windows Installation and Port Checks

Windows users should choose an installer matching their system architecture and complete the setup wizard. If Windows asks whether to allow the app through the firewall, authorize it according to the current network type. Sharing the proxy with devices on the local network is not required for first-time use, so there is no need to enable LAN access in advance. Launch the client from the Start menu and check whether the core starts successfully. If you plan to use TUN, you may later need to install a service or initialize the virtual network interface with administrator privileges.

A port conflict is a common first-launch problem on Windows. Clash configurations often use local HTTP, SOCKS, or mixed listening ports. If an older proxy tool is still running in the background, the new core may be unable to bind to the same port. Exit other proxy clients first, then restart Clash. To investigate further, use PowerShell to view the process listening on a port:

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,7892 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess>

Different configurations may use different ports; the actual listening value shown in the interface is the one that matters. Do not change the system proxy based on habit simply because 7890 is a familiar value. Graphical clients usually write the correct address to the system settings automatically.

macOS Security Prompts and Network Permissions

After installing on macOS, move the app to the Applications folder and launch it from there. The system may ask you to confirm the app’s source, add a network configuration, or enter an administrator password. The system proxy only changes network proxy settings, while TUN or broader traffic takeover generally also requires a helper service. Each authorization should correspond to the operation currently being performed. If you cancel a prompt, the client may still open, but the related switch will not work.

Menu bar clients can easily coexist with older proxy programs. Check the menu bar icon and Activity Monitor to confirm that the old core has exited. If the system proxy switch turns itself off immediately, first check the client log for permission errors, then see whether another network management tool has overwritten the network settings. After switching between Wi-Fi, Ethernet, and a hotspot, the active network service may change; if necessary, toggle the system proxy off and on again.

Android and iOS VPN Authorization

Mobile clients typically take over traffic through the system VPN interface. When you connect for the first time, the system displays a VPN configuration or connection request; the client can work only after you approve it. A VPN indicator in the Android status bar usually means the system interface is established, but you still need to verify the configuration and proxy group. If the connection stops soon after the app goes into the background, open the system battery settings, allow background activity, and remove the client from overly aggressive battery restrictions.

Usually, only one app can occupy the system VPN interface at a time. If the device already has a corporate VPN, another proxy client, or a privacy tool, starting Clash may disconnect one of them. Decide which connection should remain active instead of enabling multiple competing VPNs. On iOS, the corresponding entry appears in system settings after you add the VPN configuration. Before deleting the client, check the system VPN list as well if you want to remove the connection configuration completely.

Linux Desktop and Core Operation

Choose the package matching your distribution for a Linux graphical client. If the app launches but cannot set the system proxy, check whether the desktop environment supports automatic proxy updates. GNOME, KDE, and lightweight desktops store proxy settings differently, so compare the address and port manually in the desktop network settings when necessary. With Wayland or sandboxed environments, also check tray icon and permission restrictions; these interface issues do not necessarily affect the core.

When running the Mihomo core directly, first prepare a dedicated working directory and save the configuration as a readable file. Start it in the foreground so you can observe the logs. A common launch form is shown below; replace the path with the actual directory on your machine:

mkdir -p "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

Once you have confirmed that the configuration loads successfully, consider handing it over to a service manager such as systemd. For initial testing, do not run it in the background immediately; otherwise configuration parsing errors and port conflicts may be buried in service logs. Servers should also limit the listening scope of control and proxy ports. If they are intended for local use only, bind them to the loopback address.

Import a Subscription and Build a Recoverable Workflow

Importing a subscription means handing a remote configuration to the client for management. Before starting, prepare the complete subscription URL and make sure copying it did not add spaces, line breaks, or explanatory text. A subscription is a configuration source; it should not be pasted into a node name, proxy port, or controller address field. Different clients may call the entry “Configuration,” “Subscription,” “Profiles,” or “Config,” but the essential process is the same: download the configuration by URL, save it locally, and make it the active configuration.

Standard URL Import Steps

Open the configuration or subscription page and choose to create a configuration from a URL. Paste the complete link into the address field. Use a short, recognizable name, such as one based on purpose or device; displaying the full URL as the name is not recommended. Submit it and wait for the client to download the content. A successful import usually creates a new configuration entry with an update time or update button. Next, click the entry to make it active. Some clients do not select an imported configuration automatically, which is a common reason users can see a subscription but no nodes.

After enabling the configuration, open the proxy page, confirm that the main proxy groups are present, and select a node. Then enable the system proxy and run a basic browser test. Treat the workflow as four separate steps—“download the configuration,” “select the configuration,” “choose a node,” and “enable traffic takeover”—rather than assuming setup is complete because a subscription entry exists. For a complete illustrated walkthrough, see How to Import a Clash Subscription URL.

Check Whether the Client Accepts the Link Format

Common subscription content includes Clash YAML configurations, node lists, and formats that must be converted before Clash can recognize them. After requesting content by URL, the client passes it to the configuration parser. If the response is a login page, error page, empty text, or unsupported format, the interface may report a parsing failure rather than a simple network error. In that case, copy a link specifically intended for Clash or Mihomo from the subscription provider’s page instead of using a web page URL.

A basic YAML configuration usually contains fields such as ports, proxies, proxy groups, and rules. The example below shows the relationships between them and contains no real node information:

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Node Select
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,Node Select

YAML is indentation-sensitive and normally uses spaces; do not mix in tabs. When a subscription is generated by a remote service, do not edit the original file manually. To add custom rules, prefer the client’s override or merge feature so local changes are not overwritten on every update.

Handle Updates by Response Type

A subscription update timeout means the client did not complete the request within the allowed time. Possible causes include the current network being unable to reach the subscription URL, DNS resolution problems, or an update request that needs to go through an existing proxy. First try opening the provider’s management page over the original network to confirm that the service is reachable. If the client offers an “update through proxy” option, try it when a usable configuration already exists. During a first import, no usable configuration is available, so the subscription URL must be reachable through the current direct connection.

A 404 or similar resource-not-found response usually means the link path has expired, the token has changed, or the URL was copied incompletely. Retrying will not repair the address; return to the subscription source and generate a new link. For unauthorized or access-denied responses, check the account status, link permissions, and service-side restrictions. For more troubleshooting organized by error type, see Fix Failed Subscription Updates.

Automatic Update Intervals and Local Backups

Automatic updates do not need to run too frequently. Nodes and rules change only when the server-side content changes; repeated requests in a short period increase the chance of failure and make it harder to tell which update result is active. For everyday devices, use an hourly interval offered by the client. Update manually when immediate synchronization is needed. If the node list looks abnormal afterward, check the configuration update time and try switching back to the previous usable local configuration.

Treat the subscription URL as sensitive configuration data because it may provide access to the configuration associated with an account. Hide the full address in screenshots. When troubleshooting, share the error type and a log excerpt rather than publishing the link. Backups can include the subscription URL, custom overrides, and notes about client settings. Node lists generated by a remote subscription can usually be downloaded again, so there is no need to copy an entire cache directory between devices.

Understand Rule, Global, and Direct Proxy Modes

Proxy mode determines how a connection chooses an endpoint after entering Clash. It does not determine whether traffic reaches the client; the system proxy or TUN handles takeover. Mode selection also does not change whether a node itself is available. With these boundaries clear, troubleshooting becomes much easier: no requests at all in the connection log points to traffic takeover; requests with the wrong endpoint point to mode, rules, or proxy groups; a request choosing a proxy but failing points to the node or destination network.

Rule Mode for Everyday Use

Rule mode checks the rules in the configuration from top to bottom. The first matching rule determines whether the connection goes to a strategy group, connects directly, or is rejected. Common criteria include domains, domain suffixes, IP addresses, geographic databases, process names, and rule sets. This lets LAN resources, local services, and common direct-access sites stay direct while sending connections that need a proxy to a designated proxy group, balancing routing control with local-service compatibility.

Rule mode is not the same as “automatically deciding everything.” Its decisions come from the configuration, and both rule coverage and order affect the result. When a new domain is not yet included in a rule set, it eventually falls through to the final MATCH rule. If one website uses the wrong endpoint, find its domain in the connection log, check which rule it matched and which strategy was selected, then decide whether to add a custom rule instead of switching to global mode permanently.

Global Mode for Comparison Tests

Global mode generally sends all intercepted connections to the global proxy group. It is useful for briefly testing whether rules are responsible for a problem. If a site fails in rule mode but works in global mode, the node and traffic-takeover chain are probably working, so inspect rule matches or DNS results next. If global mode also fails, check the node, port, permissions, and network environment first.

Global mode does not mean that every bit of operating-system traffic is necessarily intercepted. With only the system proxy enabled, apps that ignore system proxy settings may still connect directly; TUN is needed for broader coverage. Global mode may also send LAN devices, printers, development services, or resources available only on the local network through the proxy. It is therefore better as a testing tool or temporary choice for a specific need, not a permanent switch for every problem.

Direct Mode for Recovery and Baseline Checks

Direct mode bypasses proxy endpoints for connections that enter Clash. It can confirm whether the original system network works and can temporarily stop proxying while leaving the client running. If ordinary websites remain inaccessible after switching to direct mode, the problem may be local DNS, the system network, residual proxy settings, or TUN routing rather than a remote node.

Before exiting the client, close the system proxy and TUN first, then quit the program. If the process is force-terminated, the system proxy may still point to a local port that no longer exists, causing every app that follows system proxy settings to lose connectivity. Restart the client and turn the switches off normally, or clear the proxy address in the system network settings. Direct mode and disabling traffic takeover are not identical: direct mode still sends the connection through the core before accessing the destination directly, while disabling takeover stops sending that traffic to the core.

Manual, Automatic, and Failover Proxy Groups

A select proxy group lets the user manually choose a node or another group. The result is stable and easy to understand, making it suitable for a primary endpoint. A url-test group periodically requests a test URL and chooses a candidate with suitable response performance; the result reflects that test target and does not represent every website. A fallback group checks availability in order and moves to the next candidate when the current one fails, making it suitable when continuity matters.

When an automatic group switches frequently, existing connections do not necessarily migrate smoothly, and login sessions or downloads may be affected. Do not set the test interval too short or add an unlimited number of candidates. For accounts or services that require a fixed endpoint, a stable manual group is easier to keep consistent. Proxy groups may also contain nested groups, so inspect them layer by layer instead of assuming the outer group name reveals the final node.

Master Rule Order, Routing Syntax, and DNS Coordination

Rule routing is Clash’s core capability and the first place to look when some websites work while others do not. Rules are matched one by one in their configured order, and matching stops at the first hit. A broad rule placed too early can therefore hide a more precise rule below it. A common design is to handle LAN traffic and explicit exceptions first, then specific domains or rule sets, followed by IP-based rules, and finally use MATCH for everything else.

How to Use Common Rule Types

DOMAIN matches a complete domain and is useful for a single host. DOMAIN-SUFFIX matches a domain and its subdomains. DOMAIN-KEYWORD has a broader scope and can produce false matches, so use it only when the domain structure is unstable and the keyword is sufficiently distinctive. IP-CIDR matches IPv4 networks, while IP-CIDR6 is for IPv6. GEOIP uses an IP geolocation database, and RULE-SET references an external or built-in rule collection.

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,example.com,Node Select
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,Node Select

In the example, no-resolve means that matching the IP rule does not trigger an additional lookup for the domain, which is useful for known local networks. In a real configuration, preserve the subscription’s existing rule structure and place only necessary exceptions where they belong. If the client supports rule overrides, use them to merge changes automatically after subscription updates. Direct edits to a downloaded configuration will likely be overwritten at the next update.

Trace Rule Problems from Connection Logs

When troubleshooting a website, first close or pause unrelated apps, revisit the target page, and filter the connection log by domain. The log usually shows the destination host, matched rule, strategy group, and route. If an unexpected direct rule matched, look for an overly broad domain suffix or geographic rule. If the request falls through to MATCH, the earlier rules did not cover it. If it reached the expected proxy group but ended on DIRECT, inspect the group’s current selection.

Modern webpages contact multiple domains. A working main domain does not mean that static assets, login APIs, and image hosts use the same strategy. If adding one main-domain rule does not complete the page, identify related domains from failed requests instead of adding broad keywords blindly. Browser developer tools and the Clash connection log complement each other: the former identifies the failed request, while the latter shows which route it took.

Why DNS Affects Rule Results

DNS converts domain names into IP addresses. If an app resolves a name before traffic enters Clash and sends only the IP, domain-based rules may not receive the original host information. If the result is affected by the network environment, the connection may reach the wrong address even when the node works. Clash’s DNS module can process queries according to the configuration and use modes such as fake-ip or redir-host to preserve the domain mapping.

fake-ip mode returns a temporary address from a reserved range to the application. The core then uses its mapping to recover the real domain and apply rules. It generally provides strong domain-rule recognition, but some LAN devices, older apps, or programs that depend on real IP addresses may need to be added to the filter list. redir-host is closer to returning the real resolution result and is straightforward from a compatibility perspective, but its domain mapping and connection recognition work differently. Do not switch modes simply because one name looks unfamiliar; if the subscription’s DNS configuration is stable, keep the existing setting.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

This example shows how the fields relate; it does not mean every network should use the same upstream address. A subscription may use DoH, DoT, system DNS, or a nameserver-policy that routes queries by domain. Record the original values before editing. If all domains stop resolving afterward, restore the subscription defaults first, then check for conflicts on listening ports such as 1053, system firewall blocks, and whether TUN DNS hijacking points to the correct port.

IPv6, LAN, and the Boundaries of Custom Rules

When a device has IPv6 connectivity, an app may prefer AAAA records. If the configuration handles only IPv4 while the system connects directly over IPv6, the endpoint may differ from expectations. Whether to disable IPv6 depends on complete support from the node, core, and local network, so disabling it is not a universal answer. A safer approach is to use connection logs to confirm whether the problematic request uses IPv6, then decide whether to add rules, adjust DNS responses, or temporarily disable that path.

When accessing a router, NAS, printer, or development server, ensure that private address ranges and local domains remain direct. In a TUN environment, preserve LAN routes so local connections are not sent to a remote proxy. Allowing LAN devices to connect to Clash’s local proxy is a separate feature that changes the listening scope. Enable it only when sharing is actually needed, and pair it with firewall restrictions on trusted networks. Do not confuse “accessing the LAN” with “exposing a proxy to the LAN.”

Enable TUN When Needed for Broader Traffic Takeover

TUN mode creates a virtual network interface and uses routing to send more connections to Clash. It is useful for games, command-line tools, store apps, and situations requiring unified handling of TCP and UDP traffic when those applications ignore the system proxy. TUN expands coverage but does not fix failed nodes, invalid subscriptions, or poorly designed rules. Before enabling it, verify the configuration through system proxy mode and record the existing DNS and proxy settings so you can quickly revert if needed.

Four Checks Before Enabling TUN

First, confirm that the current configuration can access ordinary sites through the system proxy in rule mode. Second, close other VPNs, virtual-interface proxies, and network tools that may modify routes, preventing competing takeover layers. Third, confirm that the client has administrator privileges or that the required service is installed. Fourth, save the configuration in use and learn exactly where to disable TUN, disable the system proxy, and quit the client. After these preparations, enable TUN and wait for the virtual interface to initialize.

Windows clients often use a service mode to obtain permission to modify routes. If the switch immediately resets, check for messages about service installation, insufficient privileges, or driver initialization failure. macOS may require a network extension or helper service. Android and iOS already use the system VPN interface, so their traffic-takeover implementation differs from desktop clients and may not expose a TUN switch with the same name.

What Common TUN Parameters Mean

auto-route automatically adds the required routes and suits most desktop clients. When disabled, you must manage how traffic enters the virtual interface yourself. auto-detect-interface attempts to identify the interface currently providing connectivity, which helps when switching between Wi-Fi, Ethernet, and hotspots. dns-hijack sends specified DNS requests to the core’s DNS module to reduce DNS bypasses. strict-route enforces routing more strictly; it may improve leak prevention but can affect multiple network interfaces, virtual machines, and LAN access.

The stack parameter selects the TUN network-stack implementation. Depending on the system and client, options may include system, gVisor, or mixed. system is generally closer to the operating system’s network stack, with performance and compatibility depending on the platform. gVisor uses a userspace network stack and behaves differently in isolation and compatibility for some environments. mixed combines handling by protocol. Unless there is a specific problem, use the value recommended by the client instead of switching repeatedly to chase theoretical differences.

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

This example shows only the general structure. Support for specific fields depends on the current core and client. A configuration generated by the graphical interface may also include an interface name, MTU, included routes, and excluded routes. When using subscription overrides, verify that the merged result does not define the tun section more than once, as later fields may override earlier settings.

Verification Order After Enabling

After enabling TUN, keep the system proxy disabled at first so it is clear which path is handling traffic. Visit an ordinary webpage and check whether domain requests appear in the connection log, then test an app that previously ignored the system proxy. Next, check LAN devices, DNS resolution, and common login services. If webpages work but the LAN does not, focus on private-network routes and strict-route. If no domains resolve but direct IP access responds, focus on DNS hijacking, listening ports, and upstream resolution.

Command-line tools can help inspect system routes, but do not delete an entire route table manually unless you understand the effect. On Windows, use route print or PowerShell to inspect interfaces. On macOS and Linux, use netstat -rn, route -n get, or ip route. Compare the default route and virtual interface before and after enabling TUN to confirm that traffic actually enters it. For a fuller explanation and walkthrough, see How to Enable Clash TUN Mode.

How to Exit Safely When Something Goes Wrong

If the network becomes completely unavailable after enabling TUN, disable TUN first and wait for routes to recover. Then disable the system proxy and quit the client. If connectivity still does not return, reconnect to Wi-Fi or Ethernet so the system can obtain its address and DNS again. Check for leftover system proxy settings and an interface that is still enabled. Do not repeatedly reinstall multiple clients while offline; old services, old interfaces, and new settings will make the situation harder to diagnose.

After waking from sleep, changing networks, or returning from a company network to a home network, automatic interface detection may temporarily retain an old route. Toggle TUN off and on once so the client rebuilds the interface. If the issue is tied to a particular network type, record the physical interface, DNS, routes, and logs before deciding whether to use interface exclusions, route exclusions, or a different stack. Route-priority conflicts are especially common when a corporate VPN and TUN run together, so define clearly which tool handles each destination range.

Build a Routine for Maintenance, Troubleshooting, and Advanced Work

After configuration is complete, stable use depends on repeatable maintenance habits rather than constant parameter changes. Keep a verified baseline: one working subscription, an explicit proxy group selection, rule mode, a functioning system proxy, and TUN enabled only when needed. After updating the client, subscription, or custom rules, check whether this basic chain still works. If several layers change at once, it becomes difficult to return to a known-good state.

Three Layers of Routine Updates

Client updates, core updates, and subscription updates are three different things. A client update changes the interface, system integration, and core-management behavior. A core update may change configuration syntax, protocol support, and network handling. A subscription update refreshes only the remote configuration, nodes, and rules. When a problem appears, record which layer changed most recently. If proxy groups disappear after only a subscription update, inspect the new configuration first. If the TUN service fails after a client update, check permissions and service status.

For everyday use, update subscriptions on a relatively long fixed interval and confirm afterward that the current configuration is still selected. Before upgrading the client, note the subscription URL, custom overrides, and important settings. Do not delete the old configuration immediately; first test browser access, connection logs, LAN access, and TUN. On long-running devices, restart the client once during a maintenance window to catch service auto-start, permission, or configuration-loading problems early.

Narrow the Scope with Logs and Connection Records

Connection records answer “where did this request go?” Logs answer “what happened while the core processed it?” When a site uses the wrong endpoint, start with the connection log. For subscription parsing, port binding, DNS queries, TUN initialization, and network errors, logs are more useful. Keep the log level at info during normal troubleshooting; it usually contains enough detail. debug generates many records and should be enabled only temporarily to reproduce a short-lived problem, then disabled again.

When extracting logs, keep a small amount of context before and after the error, and remove subscription URLs, authentication fields, device identifiers, and unnecessary browsing records. Common keywords include timeout, connection refused, network unreachable, address already in use, parse error, and permission denied. They point respectively to timeouts, remote rejection, missing routes, port conflicts, configuration parsing, and permission problems. Handle the error category first, then consider changing clients.

A Reliable Troubleshooting Tree

1. Check the original network. Disable the system proxy and TUN, then verify that ordinary local and commonly used sites are reachable. If the original network is failing, resolve Wi-Fi, Ethernet, captive-portal, or system-DNS issues first.
2. Check the core. Start the client and look for configuration parsing errors, port conflicts, or permission failures. If the core is not running, later mode and node settings cannot take effect.
3. Check the configuration chain. Review the subscription update time, selected configuration, main proxy group, and final node. Update the subscription manually if necessary, but do not repeat requests continuously.
4. Check traffic takeover. Enable the system proxy and make a new request while watching the connection log. No record usually means the app does not use the system proxy or the local port settings are wrong.
5. Check rules and the endpoint. Compare the results in rule and global modes, and inspect the rule matched by the target domain. If global mode works but rule mode fails, focus on routing.
6. Check TUN last. Enable TUN only after the basic chain works, then test DNS, LAN access, UDP, and sleep/wake recovery separately. Do not add multiple variables at once.

For symptom-specific troubleshooting, open Troubleshooting and choose the relevant section for system proxy, subscriptions, TUN, or connection issues. When describing a problem, include the platform, client name, takeover method, proxy mode, whether requests appear in the connection log, and the error type. This is much more useful than simply saying “the internet does not work.”

What Is Actually Worth Backing Up

Useful backups include a list of subscription URLs, custom rule overrides, custom DNS snippets, core service configuration, and brief notes about important settings. If the client supports exporting settings, use that as a supplement, not the only recovery method. When moving between clients, the most portable items remain the subscription URL and standard YAML snippets.

Add the reason for every custom configuration change. Note which service a domain rule addresses, why a LAN range is excluded, or which network environment a TUN parameter targets. When reviewing the setup months later, these notes help determine whether a rule is still needed. Configurations without documented reasons tend to accumulate until duplicates, conflicts, and confusing ordering appear.

Move from Everyday Use to Advanced Configuration

Follow the order in which connections are processed: learn select, url-test, and fallback proxy groups first; then study rule sets and rule providers; next understand fake-ip, split DNS, and IPv6; finally explore TUN routing, process rules, and standalone core deployment. Each stage should address a clear scenario, so there is no need to enable everything at once. Being able to explain from the connection log why a request chose a particular endpoint matters more than memorizing many parameters.

For use across multiple devices, maintain stable custom rules in a separate override file instead of modifying the remote subscription directly. In server environments, also learn about minimal listening scopes, service-user permissions, configuration-directory permissions, log management, and fallback after startup failure. Graphical-client users can learn basic YAML to understand merge results and parsing errors, but routine edits should still use the client’s structured controls whenever possible.