Clash User Guide: Subscriptions, Rule-Based Routing, and TUN

Core concepts: distinguish the kernel, client, and configuration file first

Clash is not a single installer

When people say “Clash,” they may mean the proxy kernel, a graphical client, or an entire toolset built around the Clash configuration format. The kernel reads configuration, establishes proxy connections, matches rules, and forwards traffic; the graphical client turns configuration, logs, proxy groups, system proxy settings, and updates into a clickable interface. mihomo is a widely used successor kernel in the Clash ecosystem, and many newer clients use it for protocol, rule-type, TUN, and DNS support. This distinction matters: the same subscription may place controls in different locations across clients, while the kernel-level handling of proxy nodes, proxy groups, and routing logic is often similar.

Configuration files usually use YAML. They can include ports, proxy nodes, proxy groups, rules, DNS, and TUN settings. A subscription is a remote configuration source: the client stores the subscription URL, downloads the provider-generated configuration when needed, and passes it to the kernel. The subscription URL is not a “connect” button, and a node name is not the same as the final exit. Requests are matched against rules first, then the selected proxy group chooses a specific node or DIRECT. Troubleshooting therefore requires separating three stages: whether the remote subscription downloads, whether the kernel parses the configuration, and whether traffic reaches an available policy.

How a request passes through Clash

Take a browser request as an example. The browser first hands it to the system network stack. When the system proxy is enabled, applications that support system proxy settings send HTTP or SOCKS requests to the client’s listening port; with TUN enabled, more IP traffic first enters a virtual network interface. Once the kernel obtains the destination domain or address, it checks rules from top to bottom. After a match, the request is handed to the specified policy. That policy may be a specific node, a manual selector, a latency test group, a fallback group, DIRECT, or REJECT. The selected node then connects to the remote server using its protocol, and the response returns to the application along the same path.

This path explains common symptoms: if a browser works but a game does not, the game probably ignores the system proxy and may need TUN; if every site fails but subscription updates succeed, the configuration downloaded correctly and the issue is more likely the node, policy, or local traffic interception; if only certain domains fail, check rules, DNS, or restrictions imposed by the destination service. Do not repeatedly reinstall the client. First identify whether the failure is in subscription retrieval, configuration parsing, traffic interception, rule matching, node connection, or DNS resolution.

Choose a client by platform, kernel, and use case

Prefer a graphical client that is still maintained

When choosing a client, start with the operating system, then check maintenance status, kernel type, and required features. The download list here recommends Clash Plus for Windows, macOS, Android, and iOS, making it suitable for users who want similar workflows across platforms. Windows and macOS also support Clash Verge Rev and FlClash; Windows additionally has Clash Nyanpasu. Android users can choose Clash Meta for Android, FlClash, or Surfboard. On Linux desktops, use Clash Verge Rev or FlClash. Clash for Windows and ClashX Meta are no longer maintained; they are useful only for migrating legacy configurations and should not be the default for a new installation.

A familiar interface is not the only criterion. If you need TUN, process rules, rule sets, or newer configuration fields, confirm that the client’s kernel supports them. Clients built on the mihomo kernel are generally a better fit for the current configuration ecosystem, but permissions, configuration paths, tray menus, and system proxy behavior can still differ between mihomo clients. If a subscription relies on specific fields, follow the provider’s documentation first. When a field is unrecognized, check kernel compatibility before deleting or rewriting the configuration.

Desktop, mobile, and server use cases differ

Desktop clients commonly provide both a system proxy and TUN. The system proxy is simple and works well for browsers, messaging apps, and software that follows system proxy settings; TUN covers more traffic and is useful for applications that do not. Android clients usually intercept traffic through the system VPN interface and show a VPN status indicator; another VPN-style app generally cannot use the same interface at the same time. iOS likewise relies on system network extensions, so configuration entry points and background behavior are constrained by the operating system. On mobile, also check battery optimization, background restrictions, and per-app proxy settings.

Servers, soft routers, and containers are better suited to running the mihomo kernel directly. These environments usually do not need desktop dependencies for a graphical interface; management is handled through configuration files, command-line arguments, and an external control interface. A kernel package is not a ready-to-use desktop client: you must prepare configuration paths, the runtime user, service management, log rotation, and firewall rules yourself. For ordinary web browsing on a personal computer, prefer a graphical client. Choose a kernel-only setup when you specifically need gateway forwarding, a transparent router, or automated deployment.

Confirm the system architecture and package type

Most Windows desktops use x64; ARM64 is needed only for devices with ARM processors. On macOS, check the chip type under “About This Mac”: Apple silicon corresponds to arm64, while Intel processors use x64. Android packages may be split into arm64, arm, and universal builds. Most recent phones use arm64, but older devices and specialized emulators require the actual architecture. On Linux, check the package format as well as the architecture: Debian and Ubuntu commonly use deb, Fedora-based systems commonly use rpm, and a kernel archive requires manual deployment.

The download page lists all clients, platform links, and maintenance status. If an old client contains important settings, export the configuration or record the subscription URL, proxy-group choices, and custom rules before migrating. Client databases and settings directories usually cannot be copied over one another safely. The reliable approach is to import the subscription again, then restore custom content item by item.

Installation and initial setup: build a recoverable foundation

Clear conflicting state before installation

Before installing a client, quit any running proxy, VPN, or older Clash client, and confirm that no system proxy setting remains enabled. On Windows, check whether a manual proxy is still active in the system network settings; on macOS, inspect HTTP, HTTPS, and SOCKS entries in the current network service’s proxy settings. A leftover proxy often creates a misleading symptom: the new client has not started, but the browser still sends requests to a local port that no longer exists, making every webpage fail. The problem is not the installer; the old program exited without restoring the system proxy.

After desktop installation, launch the client but do not enable every advanced feature immediately. Confirm that the interface loads, the kernel starts, and the logs show no recurring errors before importing a subscription. The first TUN activation may request administrator privileges or install a virtual network component on Windows; macOS may ask you to allow a network extension or enter system credentials. Grant permissions only when the feature actually needs them. If permission is denied, the system proxy will usually still work, but TUN cannot create its virtual interface.

Identify the configuration directory and startup policy first

Graphical clients generally store settings, subscription indexes, kernel files, and logs in the user directory. Do not confuse the program directory with the configuration directory: uninstalling an app may not remove user configuration, and reinstalling over it may not reset settings. When something goes wrong, use the client’s reset, configuration-switching, or cache-clearing functions first. Delete the configuration directory only after backing it up and confirming that the database is damaged. Cleaning the user directory casually can also remove subscription URLs, scripts, custom rules, and proxy-group selections.

“Start at login” and “enable the system proxy at startup” are separate options. The first launches the client; the second changes the operating system’s proxy settings. On a mobile work device, you can enable client startup, but observe several reboots before enabling automatic traffic interception. On networks that require a captive-portal login, automatically enabling the proxy may prevent the sign-in page from appearing. Pause the system proxy, complete authentication, and then reconnect. Enable automatic TUN startup only after the base configuration is stable, so permission or DNS issues do not disrupt the entire network during boot.

Keep port responsibilities clear

Common Clash ports include the HTTP port, SOCKS port, and mixed port. A mixed port accepts both HTTP and SOCKS requests on one listener and suits most personal devices. Any unused port number is fine; changing it repeatedly does not improve “speed.” Allowing LAN connections lets other devices on the same network reach the listening port, so enable it only when sharing is actually needed, and restrict sources with the bind address, access controls, and the system firewall.

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

external-controller: 127.0.0.1:9090

The basic snippet above enables a mixed port, permits local access only, uses rule mode, and restricts the control interface to the local machine. Some clients generate these fields through the interface, so confirm whether saving will overwrite the file before editing manually. The control interface is used for communication between the graphical client and kernel and should not be exposed to an untrusted network. For everyday use, set the log level to info. debug provides more diagnostic detail for short-term troubleshooting, but increases log size and makes important events harder to spot when left on.

Verify the installation with a minimal loop

Run the basic verification in a fixed order: confirm that the kernel is running; import a known-good configuration; choose a node in a proxy group; enable the system proxy; then open an ordinary webpage in a browser. If it fails, check connection records and logs. No connection record means traffic never entered the client; a record showing DIRECT means a rule matched DIRECT; a proxy record followed by a handshake failure points to the node or network environment. After this minimal loop works, enable TUN, DNS hijacking, scripts, or complex rules one at a time to make troubleshooting much easier.

Importing and updating subscriptions: manage the full remote-configuration lifecycle

Subscription URLs, configuration files, and node links are different

A subscription URL usually returns a server-generated configuration that may include multiple nodes, proxy groups, rules, and DNS settings. A single node link describes only one proxy node and cannot provide a complete routing structure automatically. A local YAML file is a static configuration saved at a particular moment and does not follow remote changes by itself. Before importing, identify what you have: if the client asks for a URL, provide an HTTPS subscription address; for file import, choose a complete YAML file; with only a node link, use a client that can parse it from the clipboard or add it to an existing configuration.

A subscription URL is effectively a credential for accessing configuration and should not appear in screenshots, forums, or public repositories. Clients usually save it in a local configuration database. For multiple devices, import the subscription separately on each device or use the provider’s centralized management option. Do not place a configuration containing the subscription URL in a public sync directory. Use a test domain for example URLs, such as:

https://example.invalid/api/profile/clash?token=xxxx

A correct import workflow

Open the client’s “Subscriptions,” “Configurations,” or “Profiles” page and create a profile from a URL. Paste the link and give the profile an identifiable name. Set the update interval according to how often the configuration changes; everyday use rarely requires refreshing every few minutes. After saving, run one manual update and confirm that the client shows the profile name, update time, or proxy groups—not merely “added.” Then switch to this profile so the kernel reloads it. Some clients separate “download subscription” from “enable profile”; updating without switching may leave the old configuration running.

Do not delete the old profile immediately after importing. Check that key proxy groups exist, rule mode is available, and commonly used nodes are listed before testing the connection. Once the new profile is stable, keep the old one temporarily as a fallback. Give multiple profiles clear names such as “Daily subscription” and “Local rule testing” instead of leaving them all as config or default. Switching profiles changes proxy groups and rules, and a client may not map the old selection to the new profile, so confirm the exit group again after switching.

Troubleshoot update failures by layer

Start by identifying the error type. A timeout usually means the client cannot reach the subscription server; certificate or system-time errors can prevent HTTPS from being established; an unauthorized response usually means the URL expired or access conditions changed; a successful download followed by a parse failure means the response is not valid configuration, perhaps an HTML error page, encoding problem, or field unsupported by the current kernel. Paste the subscription URL into a browser environment where it is allowed to load and confirm that content is returned, but never publish that content. If the browser works and the client does not, check whether subscription updates are configured to use DIRECT, a proxy, or the current proxy.

“Update subscriptions through the proxy” can create a common loop: every node in the current profile is dead, but updating the subscription also requires the current proxy, so the client cannot fetch a new profile. Temporarily switch updates to DIRECT or use a working backup profile. Conversely, if the current network cannot reach the subscription server directly, update through an available proxy. Client labels vary; look under subscription, global, or network settings instead of repeatedly adding the same URL.

Automatic updates need a fallback

Automatic updates at startup suit stable configurations and reliable networks, but should not be the only maintenance method. If remote generation temporarily fails, an automatic update may replace a working configuration with broken content. A safer approach is to retain the most recent working profile, use a sensible update interval, and manually update and test before important travel or network changes. For locally maintained override rules, confirm that subscription updates will not overwrite them. If the client supports overrides, merging, or scripts, keep custom content in a separate layer instead of editing a subscription file that will be replaced.

Proxy modes: choosing between rule, global, and DIRECT

Rule mode is the everyday default

Rule mode checks each request target and sends traffic to different policies based on domains, IPs, processes, or rule sets. A common setup sends local networks and destinations that do not need a proxy through DIRECT, routes selected targets to proxy groups, and uses a final catch-all rule for anything unmatched. Its advantage is not “automatically choosing the fastest node,” but giving different traffic types different paths. The final node still depends on the matched proxy group. Rule mode is the best default for most daily use because it balances coverage, LAN services, and application-specific needs.

When rule mode makes some sites work and others fail, do not switch to global mode immediately. Find the request in the connection log and inspect its matched rule and policy. If it was incorrectly sent DIRECT, add a more precise domain rule; if it went to the wrong proxy group, adjust the rule target or group selection; if the log shows only an IP and no domain, check DNS mode, sniffing, or whether the application connects directly by address. Global mode can help diagnose: if the request works globally, the node is probably usable and the issue is in rules or DNS; if global mode also fails, check the node and traffic interception first.

Global mode is not a performance boost

Global mode usually sends all traffic that has entered the kernel to one global proxy group instead of choosing paths through ordinary routing rules. It is useful for briefly testing a node, reaching a target not covered by current rules, or deliberately sending all traffic through one path. It does not make applications that ignore the system proxy enter Clash, nor does it bypass operating-system permissions. If a program has no connection record in rule mode, global mode usually will not help; check the system proxy, the app’s own proxy settings, or TUN instead.

Using global mode long term can send local services, printers, LAN devices, and traffic that should be DIRECT through the proxy. Some configurations handle LAN addresses specially, but client behavior is not universal. When accessing a router panel, network storage, or development environment, restore rule mode and keep local subnets on DIRECT if traffic takes an unexpected route. In global mode, the exit depends on the current selection in the GLOBAL proxy group; it does not automatically mean the first node in the list.

Use DIRECT to recover and isolate problems

DIRECT sends traffic entering the kernel without using a proxy node. It is useful for captive-portal authentication, direct subscription updates, checking whether a local-network destination is reachable, and temporarily restoring ordinary connectivity. It is not identical to quitting the client: the client may still hold the system proxy or TUN interception, while forwarding simply changes to DIRECT. When investigating leftover system proxy settings, test both DIRECT mode and fully disabling interception. If DIRECT works but quitting the client does not, system DNS, proxy settings, or network-interface state may not have been restored.

How to verify after switching modes

After switching modes, make a new request instead of relying on an existing connection. Browsers may reuse connections and apps may retain DNS caches, so open a new private window, reload the target, or briefly restart the app. Then confirm the new request’s mode and policy in the connection list. If the client can close connections, do so after switching, but there is no need to restart the kernel repeatedly. Recording the mode, matched rule, proxy group, specific node, and error message is usually much more useful than noting only whether it opened.

When choosing a mode, distinguish the proxy mode from the traffic-interception method. Rule, global, and DIRECT determine how traffic is handled after entering the kernel; the system proxy and TUN determine which traffic can enter it. These are independent dimensions. Rule mode with TUN can cover more applications, while global mode with only the system proxy still covers only software that follows system proxy settings. This distinction resolves many apparently contradictory symptoms.

Rule-based routing: from match order to proxy-group design

Rules match from top to bottom; the first match wins

Clash rules have an explicit order. Each request is checked from the first rule, and once a rule matches, its policy is used immediately. More specific rules should therefore come first, while broad rule sets and the final fallback belong later. If a broad domain suffix or IP range appears too early, later precise rules can never take effect. When troubleshooting, do not merely confirm that a rule exists in the configuration; check where it sits relative to broader rules.

Common rule types include exact domains, domain suffixes, domain keywords, IP ranges, source addresses, destination ports, process names, and rule-set references. Domain rules require the kernel to obtain the target domain; if a request appears only as an IP, they may not match. IP rules must account for resolution results and IPv4/IPv6 differences. Process rules are useful on desktop platforms but depend on system permissions and client implementation, so core routing should not rely entirely on process identification.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - DOMAIN-KEYWORD,media,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DST-PORT,22,Direct-or-Proxy
  - MATCH,Final

In the example, an exact domain goes DIRECT first; example.org and its subdomains go to Proxy; domains containing media go to Media; local subnets go DIRECT; requests targeting port 22 go to a separate policy; and everything else is handled by Final. Policy names must exactly match the names in proxy-groups, including capitalization and spaces. no-resolve prevents some IP rules from triggering an extra domain lookup for matching, but whether it fits depends on the rule type and configuration goal.

Proxy groups decouple rules from individual nodes

Rules should point to clearly named proxy groups rather than hard-coding a node name. For example, a rule can target Media, Work, or Final, while the group chooses the actual node. When a subscription adds or removes nodes, the rule layer then remains intact. A manual group lets the user choose the exit; a latency-test group periodically requests a test URL and selects a node; a fallback group tries available nodes in order; and a load-balancing group distributes connections according to its algorithm. Each group solves a different problem, so behavior cannot be inferred from the name alone.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

url-test measures one request to a specified test URL. It does not represent video bandwidth, long-connection stability, or real-world performance for every destination. The test URL should remain reachable, return a small response, and roughly represent the network path used in practice. An interval that is too short creates unnecessary requests; one that is too long may miss node changes. tolerance reduces frequent switching when latency is close, preventing the group from bouncing between nodes. Automatic groups suit general browsing; important sessions or workloads needing a fixed exit are better served by a manual group.

Rule sets and remote providers

When there are many rules, use rule-providers to split categories into separate files referenced by the main configuration. This allows individual updates and makes rule sets reusable. Remote rules still carry risks: failed downloads, incompatible formats, and behavior changes after updates. Set a sensible update interval and local cache path, and check the logs after first enabling a provider. The rule-set type, behavior, and file format must agree. domain, ipcidr, and classical use different content structures; mixing them can cause parse errors or unexpected matching.

Use a minimal-override approach when changing rules: add an exact rule for a clearly identified problematic domain, verify the match, and only then consider expanding it to a domain suffix or rule set. Do not send an entire top-level domain through one policy because a single subdomain failed, and do not move the final MATCH rule upward. If the client supports overrides or merged rules, keep local rules in a persistent override layer so updates do not erase them. For how DNS interacts with rules, see Clash DNS Configuration Explained.

TUN and DNS: intercept more traffic while keeping resolution consistent

TUN solves the traffic-entry problem

The system proxy depends on applications actively reading the operating system’s proxy settings. Browsers and most desktop apps support this, but games, command-line tools, some store apps, and software with a custom network stack may ignore it completely. TUN creates a virtual network interface and routes more IP traffic into the kernel, covering a wider range of applications. It is not a new proxy mode: traffic entering through TUN is still processed by rule, global, or DIRECT mode, and the proxy group still determines the exit.

The first TUN activation may require administrator, network-extension, or VPN permission. On Windows, also check other virtual adapters, enterprise security software, and existing VPNs; on macOS, confirm that the network extension is allowed; on Android and iOS, TUN usually appears as a system VPN and conflicts with apps using the same interface. If the entire network stops immediately after activation, disable TUN to restore the basic connection, then inspect interface creation, route installation, and DNS-listener errors in the logs instead of switching nodes repeatedly.

What common TUN parameters do

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

auto-route makes the kernel add necessary routes automatically, while auto-detect-interface identifies the current outbound network interface and suits devices that switch between wired, wireless, and mobile hotspots. stack selects the TUN network-stack implementation; mixed is a common choice. If a platform has compatibility issues, test system, gvisor, or mixed according to the client documentation, changing one parameter at a time. dns-hijack sends eligible DNS requests to the kernel and reduces cases where applications bypass Clash DNS.

The addresses in the example only illustrate field structure. Choose actual DNS servers based on reachability, privacy requirements, and the configuration source. Do not simply add large numbers of nameserver and fallback entries; more servers do not necessarily improve reliability and can make query paths and troubleshooting harder to understand. If the subscription already supplies a DNS section, understand its logic before editing it. When a graphical toggle generates TUN settings, avoid writing conflicting DNS definitions in both the subscription and global settings.

fake-ip versus redir-host

fake-ip mode returns mapped addresses from a reserved range for domains, while the kernel keeps the original domain through the mapping and can match domain rules earlier. It usually provides strong routing control, but some LAN services, specialized apps, or programs that require real resolution results may need entries in fake-ip-filter. redir-host follows a more traditional resolution path and returns actual IPs before forwarding based on the result. Its compatibility model is more familiar, but domain retention and matching differ. Follow the client default and actual compatibility rather than switching repeatedly to pursue one label.

If a webpage works but a LAN device cannot be found, or an app cannot sign in while the browser works, check DNS logs, fake-ip filters, and local domain names. Keep exclusions precise—for example, target a specific local suffix instead of excluding every domain. After editing, clear the app’s DNS cache or reconnect; otherwise an old result may remain active. If encrypted DNS in the system, browser, or an enterprise DNS client is enabled, confirm that it is not bypassing Clash’s resolution path.

Locating common TUN conflicts

If the network goes completely offline after TUN is enabled, first check whether the virtual interface was created, the default route was installed, and the correct physical interface was detected. If only some apps fail, check whether their requests appear in the connection list and whether they were excluded from TUN routing. For LAN problems, inspect private-subnet rules and route exclusions. If TUN stops working after sleep and wake, the network interface may have changed without routes being refreshed. Disable and re-enable TUN to test recovery, then consider automatic interface detection or a client update.

Containers, virtual machines, game-acceleration tools, and enterprise VPNs can make the routing table much more complex. Temporarily quit other software that modifies routes and verify Clash TUN by itself; then restore each program one at a time to find the conflict. If a work environment requires an enterprise VPN, do not overwrite its routes without authorization. Prefer the system proxy or follow network-management requirements. TUN is meant to expand interception coverage, not forcibly change every managed network policy.

Routine maintenance and troubleshooting: establish a reliable check order

Focus maintenance on configuration, kernel, and system state

Once a Clash client is stable, there is no need to clear configuration or replace nodes constantly. Routine maintenance can follow four steps: update subscriptions as needed, monitor client and kernel maintenance status, check log size periodically, and keep a recoverable configuration source. After a subscription update, briefly verify commonly used proxy groups. Before updating the client, note the current configuration path and key toggles; afterward, confirm kernel startup, system proxy, and TUN status. An overwrite installation usually preserves subscriptions, but custom rules and local settings should still have a separate backup.

Logs help locate problems and should not remain at debug level indefinitely. Use info during normal operation to see configuration loading, listening ports, subscription updates, and connection errors. When a problem occurs, reproduce it once and read the logs around that time. Finding the first clear error is usually more useful than staring at the final line, because later errors may only be consequences. Before sharing logs, remove subscription URLs, node credentials, and personal paths; keep only the error type, relevant fields, and necessary context.

Use the scope of the failure to locate it

If no application can connect, switch to DIRECT and disable TUN first to check whether ordinary networking works; then verify kernel status and port availability. If only apps that follow the system proxy work, check TUN or the app’s own proxy settings. If only one site fails, inspect the matched rule, DNS result, and destination service. If only one node fails, compare another node in the same group. If subscriptions cannot update while existing connections work, limit the issue to the subscription URL and update route instead of resetting the entire client.

Latency tests reflect only a short request to the test URL. A node with low latency may still perform poorly for video or large files because of bandwidth, packet loss, congestion, or the destination route. Conversely, a slightly slower node may be more stable. Judge real-world performance using connection success rate, sustained transfers, destination response, and stability over time. For more on latency numbers and their limitations, see How to Read Clash Latency Tests.

Ports, time, and caches are easy to overlook

A port conflict prevents the kernel from listening; logs usually show an error such as address already in use. Quit old clients and duplicate kernel processes first, then confirm that the port has been released. An incorrect system clock can break HTTPS certificate validation and some protocol handshakes, so enable reliable time synchronization. DNS and connection caches can also delay visible changes: an old connection may continue using its previous policy after a rule switch, and an app may retain an old DNS result. Reconnect during testing and restart the target app if necessary instead of rebooting the entire device every time.

If the system proxy cannot be disabled, restore it manually in the operating system’s network settings. On Windows, also check whether an automatic configuration script and manual proxy remain enabled together; on macOS, inspect proxy entries for the current network service. After an abnormal client exit, TUN routes are usually cleaned up, but a virtual interface or route may occasionally remain temporarily. Restarting the client and closing it normally once is generally safer than deleting a driver. On mobile, disconnect from the system VPN settings and authorize the client again.

Keep reproducible troubleshooting notes

Useful troubleshooting notes should include the operating system, client name, interception method, proxy mode, time of failure, target app, matched policy, and key logs. “It does not work” cannot distinguish a subscription, rule, DNS, or node problem. “In rule mode, the browser request matched DIRECT; it recovered in global mode after matching Proxy” points directly to the rule layer. Change one variable per test and record the before-and-after results. For complex issues, copy the current configuration into a test profile instead of stacking temporary changes onto the daily profile.

After a client update introduces a problem, confirm that the intended configuration is still selected, whether the kernel changed, and whether TUN permissions remain before considering a rollback. When an old client is no longer maintained, do not stay on it indefinitely. After moving to a new client, recheck the system proxy, proxy groups, and custom overrides. For the relationship between original Clash, Meta, and mihomo, read Clash Kernel Versions: Differences and How to Choose so client-version changes are not confused with kernel differences.

Advanced roadmap: move from graphical settings to maintainable configuration

Learn to read configuration before rewriting it

The first step in Advanced Config is not starting with a blank file; it is understanding a working configuration. Identify basic listeners, DNS, proxy providers, proxy groups, rule providers, and the final rule, then trace the fields a real request passes through. Make a copy of a subscription-generated configuration, apply minimal changes in the copy, and validate it with the client’s configuration checker. YAML is indentation-sensitive: list items, object nesting, and special characters in strings can all cause parse failures. Use spaces for indentation and prevent the editor from replacing ordinary characters with typographic symbols.

Split configuration around maintenance boundaries: subscriptions handle remote nodes, local overrides handle personal rules, rule providers handle reusable categories, and global settings handle device-level ports, TUN, and interface behavior. Do not put everything into one file that is replaced on every subscription update. When a client supports merge, override, or scripts, confirm the merge order first: whether same-named fields are replaced, appended, or deeply merged directly affects the final configuration. After editing, inspect the configuration the client actually generates and passes to the kernel, not just the input fragment.

Proxy providers are suited to dynamic node management

proxy-providers:
  main-provider:
    type: http
    url: https://example.invalid/provider.yaml
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: Main
    type: select
    use:
      - main-provider
    proxies:
      - DIRECT

proxy-providers separate node sources from the main configuration, which can reference providers through use. Remote files must use a provider format supported by the kernel; path sets the local cache location, and the interval controls how often content is fetched. Health checks measure reachability to a specified test URL, but still do not represent every destination. With multiple providers, create separate groups by purpose rather than putting every node into one enormous list. If a provider update fails, the local cache may remain usable, so store it somewhere the client can write and preserve.

Manage the external control interface and LAN access separately

external-controller lets a graphical client or management panel read kernel state and perform switching operations. On a personal computer, listen on a loopback address by default. Consider a LAN listener only when other devices must manage it, and pair it with access credentials, the system firewall, and trusted network ranges. allow-lan controls whether LAN devices may connect to proxy ports; it is separate from the control interface. Opening proxy ports does not mean the control interface should be exposed, and vice versa. Every LAN-facing listener should have a clearly defined purpose and access scope.

When running on a soft router or server, decide which user starts the kernel, who owns the configuration and cache directories, and how the service restarts after failure. A system service manager is more reliable than leaving a process suspended in a terminal. Before updating the kernel, preserve the current executable and configuration, run a configuration check, restart the service, and monitor the logs. For containers, define port mappings, network mode, TUN-device permissions, and configuration volumes explicitly; do not map the host’s entire filesystem into a container.

Design DNS, sniffing, and rules as one system

Advanced Config often enables fake-ip, DNS hijacking, domain sniffing, and rule sets together. Their shared goal is to preserve domain information and classify traffic accurately, but redundant or conflicting settings increase misclassification. Sniffing can recover domains from some HTTP, TLS, or QUIC traffic and help with apps that connect directly to an IP; it does not decrypt application content, and not every protocol exposes a domain. Start with the client defaults and adjust ports or exclusions only for a clearly identified issue.

When designing the DNS path, answer three questions: who receives system requests, which upstreams the kernel queries, and how results participate in routing. With nameserver-policy, you can assign specific resolvers to selected domains, but keep the scope precise so large volumes of queries are not accidentally sent to an unsuitable upstream. fallback-filter determines which results enter fallback resolution and should be understood alongside geo data, network ranges, and domain conditions. For the complete relationship between these fields, see nameserver, fallback, and DNS Hijacking Parameters.

Establish your own change-management workflow

Maintainable configuration requires a fixed workflow: copy the current working profile and state the single problem being addressed; run a syntax check after editing; load it in an environment where DIRECT can restore connectivity; observe connection records, rule matches, and logs; then merge it into the daily profile only after it proves stable. For rule sets and proxy providers, record their source, purpose, and update method. Remove unused fields and avoid defining the same feature repeatedly in graphical settings, override files, and subscriptions.

Advance along three tracks. The first is rules: understand the matching boundaries of DOMAIN, IP-CIDR, PROCESS-NAME, RULE-SET, and MATCH. The second is networking: understand the system proxy, TUN, routing, DNS, and IPv6. The third is operations: learn configuration splitting, logging, service management, and rollback. After completing these tracks, study mihomo’s extended protocols and special rule types. Start with mihomo Kernel Feature Differences to confirm which fields the current kernel supports before adding them.