The Complete Clash Guide from Beginner to Advanced

Core concepts: understand how requests pass through Clash

How the client, core, and configuration file work together

Clash is not the name of a single interface. It is a working system made up of a core, a graphical client, and configuration files. The core listens on local ports, parses configuration, matches rules, creates proxy connections, and handles DNS. The graphical client manages installation, updates, profiles, the system proxy switch, and logs. Configuration files define listening ports, proxy nodes, policy groups, rules, and DNS behavior. mihomo is often called the Clash Meta core. It extends the Clash configuration model with broader protocol, rule, and system-routing capabilities. Once these boundaries are clear, troubleshooting becomes more direct: an interface that will not open is a client-layer issue; a profile that will not load calls for a YAML check; a site using the wrong route points to rules or policy groups.

A typical browser request first enters through the system proxy or a TUN virtual interface, then reaches the core. The core reads the domain, destination address, port, and network type, and searches for the first matching entry in the configured rules, in order. A match usually points to a policy group rather than directly to a server. The policy group then chooses a specific proxy, DIRECT, or reject according to the current selection, health checks, or fallback logic. The flow can be summarized as “traffic entry → rule match → policy group → outbound connection.” An inconsistency at any layer can produce the familiar result: the client says it is connected, but traffic behaves unexpectedly.

Listening ports and the system proxy

Common Clash entry points include HTTP, SOCKS, and mixed-port. HTTP proxies suit software that supports system or manual proxy settings; SOCKS handles more general TCP requests; mixed-port accepts both HTTP and SOCKS on one port, reducing the number of ports to manage. The system proxy switch only points the operating system’s proxy address to a local listening port. It does not change the rules in the profile and cannot affect applications that ignore system proxy settings. If a browser works but one program does not, first check whether that program reads the system proxy. If it does not, configure a proxy inside the program or consider enabling TUN.

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

The minimal snippet above means the core listens on a local mixed port, does not expose it to other devices on the LAN by default, uses rule mode, and records standard-level logs. You can change the port number, but then you must update the port in the system or application proxy settings as well. If startup logs report a listening failure, another process is usually already using the port. See How to find and fix Clash port conflicts to identify the process, then close it or choose another port.

Nodes, policy groups, and rules are different layers

A node defines one concrete outbound connection, usually including a server, port, protocol, and authentication details. A policy group organizes multiple nodes or other policies. Rules send requests to policy groups. For routine route changes, operate on the policy group instead of repeatedly editing rules. For example, create a manual group called “Proxy Selection,” a latency-tested group called “Auto Select,” and place both in a higher-level “Default Outbound” group. Rules for video, downloads, and work services should reference stable group names. When a subscription or node changes, the rules layer then needs no rewrite.

Choose a client: balance platform, core, and management style

Start with a full graphical client

Most users should start with a graphical client. Clash Plus is the recommended choice across platforms here, providing common installation paths, profile management, and connection controls for first-time setup and daily maintenance. Windows, macOS, Android, and iOS users can switch to their platform on the download page, review the system requirements, and then install. Do not choose a client based only on appearance. Check four basics: support for your operating system and CPU architecture, a core compatible with your configuration, profile updates and switching, and the ability to manage the system proxy or TUN when needed.

Windows and Linux users can also choose Clash Verge Rev or FlClash; Windows users can choose Clash Nyanpasu; Android users can choose Clash Meta for Android, FlClash, or Surfboard; macOS users may also find the archived ClashX Meta; Clash for Windows is likewise an archived client that is no longer maintained. Archived status does not make an existing profile stop working immediately, but it is not a sound long-term foundation for a new deployment. If an existing setup still depends on an old client, export the profile and overrides before migrating, then restore them one by one in the new client. Avoid changing the client, core, DNS, and TUN all at once, or the source of a problem will be difficult to isolate.

Identify the CPU architecture

Labels such as x64, AMD64, ARM64, and Apple Silicon in installer names refer to different CPU architectures. Most traditional Windows PCs use x64; Windows on ARM devices require an ARM64 build if available. Newer Macs generally use Apple Silicon and need an ARM build, while older Intel Macs use x64. Android devices usually prefer an arm64 package; consider a universal package only when the architecture is unclear or installation fails. On Linux, distinguish AMD64 from ARM and also distinguish deb, rpm, and compressed core files. Desktop distributions suit their matching package format, while servers and routers often run the mihomo core directly.

The boundary between a graphical client and a standalone core

A standalone mihomo core suits environments that require precise control over startup arguments, configuration directories, service permissions, and log output. It does not automatically provide a desktop interface or modify the system proxy. Server deployments typically specify the configuration directory from the command line and then use a system service manager to keep the process running. Desktop users who simply want to import a subscription and connect do not need to start with a core archive. A graphical client already packages core lifecycle management, profile switching, and system settings, making issues easier to locate.

A device should not have multiple clients controlling the same port or establishing TUN simultaneously. During migration, exit the old client and confirm that its background core has stopped before starting the new one. If the new client reports a port conflict, do not keep switching to random ports; identify the leftover process first. If the system proxy still points to the old port, disable the old proxy state and let the new client write its settings again. Keeping “one active core, one current profile, and one clear entry point” greatly reduces cross-effects.

Platform installation: verify permissions, entry points, and first launch

Installing on Windows and macOS

Before installing on Windows, exit other clients of the same type so an old core does not keep the listening port occupied. After installation and the first launch, do not enable every switch immediately. Open Settings and confirm the core status, configuration directory, and mixed-port before importing a profile. When you enable the system proxy, the client points it to the local loopback address and listening port. If the browser still uses an old setting, disable the system proxy and enable it again. If only Store or UWP apps cannot connect, check whether they are allowed to access the local loopback rather than changing the global rules.

On macOS, choose an Apple Silicon or Intel build according to the processor. If the first launch is blocked by system security, review the application source and the displayed message in System Settings. Enabling the system proxy usually requires permission to modify network settings; TUN or a network extension may require additional authorization. After granting permission, return to the client and confirm the switch state instead of treating the disappearance of the system prompt as proof. If an old client installed a helper service, shut it down normally before migrating so two helpers do not try to modify network settings at once.

Installing on Android and iOS

Android clients usually route traffic through the system VPN interface. When connecting for the first time, Android displays a VPN authorization prompt; after approval, a connection indicator appears in the status bar. If the connection stops soon after switching apps, check battery optimization, background activity, and power-saving restrictions. Some vendor-customized systems reclaim background services after the screen locks, so add the client to the list allowed to run in the background. Per-app routing, LAN bypass, and IPv6 behavior depend on both the client and the profile. For initial testing, keep the setup simple, confirm that ordinary websites work, and only then add per-app rules.

On iOS, install Clash Plus through the App Store and authorize the VPN configuration during the first connection. iOS can keep only one active VPN configuration at a time, so disconnect any other network tool before testing. After switching between Wi-Fi and cellular data, check whether the client remains connected and verify the rules through actual access results. Mobile systems hide some low-level logs, so record whether the issue occurs on Wi-Fi, cellular data, or both, and whether it affects only one app.

Linux desktop and core deployment

After installing a deb or rpm package on a Linux desktop, confirm that the desktop environment actually reads system proxy settings. The configuration entry points for HTTP, HTTPS, and SOCKS vary between desktop environments, and a client’s “system proxy” button may not cover every session. Test in a browser first, then use a command that clearly supports proxy environment variables. For a standalone core, create a fixed configuration directory and run it in the foreground on the first launch so YAML errors appear directly in the terminal. Once the profile loads correctly, hand it over to the service manager.

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

-d specifies the working directory, from which the core reads configuration and related data files. Use the executable name and installation path provided by the downloaded package. For long-term operation, create a dedicated user with limited permissions and define the owners of the configuration and log directories. Do not grant broad access to the entire directory just to bypass a permission issue. If the service fails to start, run the same command in the foreground first; it is easier to see a YAML line number, port conflict, or missing resource than by checking service status alone.

Four checks after the first launch

After installation, check in a fixed order: first, the client reports that the core has started; second, the current profile is selected with no parse errors; third, only the expected system proxy or VPN/TUN entry point is active; fourth, the policy groups contain a usable outbound. Then visit an ordinary site and inspect the connection log to confirm that the request entered the core, matched a rule, and created an outbound connection. Do not judge success only by the status text on the client home screen. The system proxy may not have been written, an app may bypass the proxy, or DNS may still be handled by another network component.

Subscriptions and profiles: create an updateable, reversible setup

A profile is the complete configuration entry point

A profile can come from a local YAML file or a remote subscription URL. It is more than a node list: it may also contain policy groups, rules, DNS settings, and overrides. After importing a remote URL, the client usually saves a local copy and records its update source. Later updates may overwrite manual changes in that profile, so long-term customizations should not be scattered through an auto-updating file. A safer approach is to keep the original subscription as the base and use the client’s overrides, scripts, or a separately maintained local profile to add rules.

When managing multiple profiles, give each one a purpose-based name such as “Daily Rules,” “Mobile Network Test,” or “Minimal Local Setup” instead of keeping only an import timestamp. Switching profiles makes the core reload the configuration, and policy-group selections may revert to the state stored by that profile. After switching, check the current filename, mode, and main policy groups so the interface does not appear to have switched while the previous profile is still active. For profile update relationships and switching behavior, read Importing Clash profiles and managing multiple configurations.

YAML structure and indentation

Clash configuration uses YAML. Indentation represents hierarchy and normally uses spaces; tabs should not be mixed in. List items begin with a hyphen, and the colon after a key must preserve the correct structure with its value. When a name contains a colon, hash, comma, or other special character, quoting it is safer. If a profile fails to load, start with the line number in the log, then inspect that line and the hierarchy above it, because the actual error often comes from an incompletely indented preceding list item.

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

proxy-groups:
  - name: "Proxy Selection"
    type: select
    proxies:
      - "Auto Select"
      - DIRECT

  - name: "Auto Select"
    type: url-test
    proxies:
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy Selection

This snippet demonstrates hierarchy, but the “Auto Select” group contains only DIRECT and is included solely to illustrate syntax. In a real setup, nodes are usually written by a subscription or proxy provider. MATCH is the final fallback rule and should be placed at the end of the rules list; the rules before it handle LAN traffic and other explicit targets first. Policy-group names must exactly match the names referenced by rules, including spaces and capitalization. If you rename a group without updating its references, the profile may fail to load or requests may be sent to a nonexistent policy.

Remote updates and local overrides

When a subscription update fails, distinguish among an unreachable URL, a server error, invalid YAML content, and a client write failure. Check the network status and parse result in the update log. Do not click Update repeatedly; duplicate requests will not fix an address, permission, or format problem. If the old copy still works, keep it active while investigating the update source separately. If an update succeeds but nodes change while rules do not, the provider format may simply differ. If policy-group names also change, local rule references may need to be updated.

Overrides are suitable for local ports, LAN access, DNS preferences, and a small number of fixed rules, but record whether the override is applied before or after import. Later fields with the same name usually overwrite earlier ones; list fields may replace, prepend, or append depending on the client. Export a working profile before editing, make one category of change at a time, and reload immediately. If you change ports, DNS, rules, and TUN together, it becomes difficult to identify the cause of a failure.

Proxy modes: understand the scope of Rule, Global, and Direct

Use Rule mode as the daily default

Rule mode reads rules one by one and sends each request to the matched policy group. It suits long-term use because LAN traffic, common direct destinations, proxy targets, and rejected targets can be handled separately. Matching proceeds from top to bottom and stops at the first match, so ordering matters more than the number of rules. Put specific rules before broad ones: place a full domain before a domain suffix, private network addresses before general IP rules, and use MATCH for traffic that matches nothing else.

In Rule mode, “Proxy Selection” is not a mode switch but the current outbound choice of a policy group. You can select a specific node, an automatically tested group, or DIRECT within that group. If a site takes the wrong route, inspect the matched rule and policy name in the connection log instead of switching to Global first. Global mode is useful for quickly checking whether a node works, but it bypasses the existing routing logic and cannot prove that the rules are correct.

Use Global mode to isolate rule problems

Global mode generally sends all traffic entering the core to the global policy group. It is useful for short diagnostic tests: if Rule mode fails but Global mode works through the same node, the issue is more likely in the rules, DNS result, or policy-group reference. If both modes fail, continue checking the node, destination network, listening entry point, and system permissions. Switch back to Rule mode after testing so LAN traffic, software updates, and local services are not sent through the proxy unnecessarily.

Global mode cannot make traffic that never entered the core enter it automatically. An app that ignores the system proxy may still connect directly even when the client is set to Global, and its requests usually will not appear in the connection log. Check the app’s own proxy settings or enable TUN after confirming that it is needed. This distinction is essential: the mode determines “how traffic is handled after entering the core,” while the system proxy and TUN determine “whether the request enters the core.” They are not interchangeable.

Direct mode and actually disconnecting

Direct mode normally makes requests that enter the core connect directly to their destinations. It is useful for comparison tests, but it is not the same as fully exiting the client. The system proxy may still point to Clash, DNS may still be handled by the core, and application requests may continue to appear in the connection log. To restore the operating system’s original network path, disable the system proxy or TUN first, then stop the core. If the client offers “Restore system proxy,” use that action normally so the system does not retain a dead local proxy address.

Use latency values for relative comparison only

Latency tests in a policy group usually connect to a fixed URL to determine whether a node is reachable and compare a particular test path. They do not represent the actual time required to reach every site and cannot fully capture bandwidth, packet loss, connection reuse, DNS, congestion, or the destination server’s condition. An auto-test group should use a stable URL with a small response body and a reasonable interval. Intervals that are too short create unnecessary connections; intervals that are too long detect route changes late. See Understanding Clash proxy latency results for the underlying details.

Rule-based routing: from match order to custom policies

Common rule types

DOMAIN matches a full domain name and suits one specific host; DOMAIN-SUFFIX matches a domain and its subdomains, making it useful for a group of related services; DOMAIN-KEYWORD matches a keyword in the domain and has a broad scope, so place it carefully; IP-CIDR and IP-CIDR6 match address ranges; GEOIP classifies addresses using a database; PROCESS-NAME matches a program name on platforms that support process identification; RULE-SET references an external rule collection. The final MATCH catches every request not matched earlier.

Domain rules can often make a decision before DNS produces a destination address, while IP rules depend on the resolved or actual destination address. Some connections access an IP directly and provide no domain information, so only IP or fallback rules can handle them. no-resolve can prevent certain IP rules from triggering an extra lookup for matching, but whether it applies depends on the rule type and configuration goal. When writing rules, do not optimize only for coverage. Define the responsibilities of policy groups first, then have rules reference stable responsibility names.

rules:
  - DOMAIN,updates.example.test,DIRECT
  - DOMAIN-SUFFIX,example.test,Proxy Selection
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy Selection

This example uses a reserved test domain to demonstrate the syntax. The first full-domain rule takes priority over the later suffix rule, so update.example.test goes DIRECT while other hosts under the same suffix go to “Proxy Selection.” Private address ranges remain DIRECT, and MATCH provides the final fallback. In a real profile, add the address ranges required by the local network and confirm that LAN services are not sent to a remote outbound.

Rule order determines the final result

Clash does not search all rules for the “most specific” match; it uses the first matching rule. Therefore, a broad DOMAIN-SUFFIX placed first can prevent a later full-domain exception from ever matching. If MATCH appears early, every rule after it becomes ineffective. When adjusting rules, find the target domain, destination address, and current match in the connection log, then place the exception before the broad rule causing the conflict.

Rule sets follow the order of their current position as well. When referencing multiple rule sets, define each collection’s scope and update source clearly. Do not load many collections with overlapping responsibilities, or an earlier collection may intercept a domain before later rules can be understood. Maintain rules in sections such as “local and private networks, explicit direct routes, explicit proxy routes, specific services, address rules, and final fallback,” then verify several representative destinations in the connection log after every change.

Policy-group design matters more than piling up rules

Common policy-group types include select, url-test, fallback, and load-balance. select is chosen manually; url-test periodically compares candidate outbounds; fallback selects the first available option; load-balance distributes connections across multiple outbounds. Automatic testing is not a universal answer: login sessions that need a fixed exit are better suited to a manual group, and downloads that require continuity should not switch frequently. Start with “Manual Select” and “Auto Select,” then create higher-level groups for work, media, downloads, and other purposes.

Policy groups can reference other policy groups to form layers, but excessive depth makes troubleshooting harder. Let business rules reference a small number of stable top-level groups, while subscriptions and automatic groups handle lower-level node changes. Before deleting a policy group, search its name across the profile and confirm that no rules, proxy providers, or other groups still reference it. For complete custom-rule editing guidance, consult the site’s user documentation; when migrating to mihomo, read mihomo core features and configuration differences.

DNS and TUN: handle system routing and domain resolution

Why TUN is needed beyond the system proxy

The system proxy affects only applications that actively read proxy settings. Games, some command-line tools, standalone updaters, and programs using specialized network stacks may connect directly. TUN creates a virtual network interface and sends IP traffic that matches its routing conditions into the core, providing broader coverage. It also adds variables: administrator permissions, routing tables, DNS hijacking, virtual adapters, other VPNs, and security software can all affect the result. Before enabling TUN for the first time, make ordinary system-proxy traffic stable in Rule mode, then test TUN as a separate stage.

If all web access stops after enabling TUN, first check the core log to confirm that the virtual interface was created, then inspect the default route and DNS. If only LAN devices become unreachable, check whether private addresses bypass TUN, whether local subnets remain routed locally, and whether the rules set LAN addresses to DIRECT. If the network does not recover after disabling TUN, exit the client and check for a remaining virtual interface or stale proxy settings. Do not repeatedly switch between multiple VPN tools during a failure; they may keep rewriting the same routes.

DNS modes and request paths

DNS determines how domain names become addresses and affects whether domain rules can be associated with connections correctly. If system DNS operates outside Clash, domain queries may bypass the intended upstream. If an app uses encrypted DNS on its own, the core may see only the destination address. Clash DNS settings can define the listener, enabled state, IPv6 behavior, enhanced mode, default resolver, and upstream servers. Choose upstreams based on reachability and purpose rather than simply stacking many addresses. The more complex the setup, the more important it is to document which stage each resolver handles.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - "https://dns.alidns.com/dns-query"

fake-ip mode returns a mapped address from a reserved range for each domain, allowing the core to preserve the domain relationship for later connections and rule matching. Some LAN services, device discovery, login verification flows, and domains that require specific DNS results may not work well with fake-ip and need to be added to the filter list. Do not expand that list without limit. Before each addition, confirm that the failure is actually caused by fake-ip mapping and record the domain. Switching to redir-host changes resolution and connection behavior; clear system and application DNS caches before comparing the results.

Key TUN configuration fields

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

stack selects the network-stack implementation used by TUN; mixed is often used to support different traffic types. dns-hijack sends conventional DNS requests on port 53 to the core; auto-route writes the required routes automatically; auto-detect-interface attempts to identify the current egress interface. Strict routing can reduce some bypasses, but it may conflict with virtual machines, containers, LAN sharing, and other VPNs. Test these fields one at a time instead of copying a profile filled with platform-specific parameters.

On Windows, TUN usually requires elevated permissions or a helper service; macOS needs a network extension or corresponding authorization; Linux needs access to the TUN device and permission to modify routes; mobile platforms generally implement it through the system VPN interface. The same YAML does not necessarily have identical permission requirements across platforms. When troubleshooting, check “valid configuration syntax” separately from “permission granted by the operating system.”

Verify that resolution follows the expected path

DNS troubleshooting requires observing both the system side and the core side. First confirm whether system DNS requests enter Clash, then check which upstream the core selected and what kind of result it returned, and finally see which rule matched the destination connection. A single test-site result may be affected by browser secure DNS, caching, IPv6, and the network exit, so do not rely on one conclusion. Try another browser, disable the browser’s independent DNS, and compare the connection logs. For a fuller checklist, see Clash DNS leak testing and protection settings.

Routine maintenance: updates, backups, logs, and fault isolation

Build a reversible update workflow

The client, core, subscription, and rule sets are four different update targets. Do not update all of them at the same time. A safer sequence is to back up the currently working profile and record the main policy-group selections, update only the subscription and verify it, update the client or core if needed, and update external rule sets last. At each step, check startup, parsing, connectivity, and rule matches. If compatibility breaks, you can identify the changed layer and roll back to the last working state.

At minimum, back up local profiles, overrides, scripts, policy-group names, and key DNS/TUN settings. The subscription URL is only an update source and cannot replace a local backup; once remote content changes, downloading it again may not restore the previous state. Organize backup files by purpose and date, and do not let the client scan multiple duplicate copies at once, or the profile list becomes difficult to distinguish. During recovery, first verify that the profile loads without enabling the system proxy or TUN, then restore traffic takeover step by step.

Log levels and connection records

info suits daily use and shows startup, profile loading, and major connection events. Temporarily increase verbosity when investigating rule or network details, but keeping highly detailed logs enabled indefinitely increases disk writes and reading overhead. Troubleshoot logs around a time window: record the exact action that triggered the issue, then look for DNS, rule, policy, and connection errors in the same period. The final error line alone is often insufficient because the root cause may appear earlier during a profile reload or interface-creation stage.

Connection records answer three questions: did the request enter the core, which rule matched, and which outbound was ultimately used? If there is no record, check the system proxy, TUN, and the app’s own network settings. If the rule is wrong, check the domain, address, and ordering. If the outbound is correct but the connection fails, check the node, destination service, and network environment. For intermittent issues, record the network, profile, mode, and policy-group selection at the time of failure instead of continually changing settings before reproducing it.

Layered handling of common failures

A port conflict is one of the most common startup problems. Before changing a port, identify the process using it. If it is an old Clash core, terminate the old process normally instead of keeping two instances running on different ports indefinitely. DNS problems often appear as partial site failures, unexpected rule matches, or temporary recovery after switching networks. Distinguish among a failed domain lookup, an unexpected resolution result, and a failure to connect to the destination address; each belongs to a different troubleshooting layer.

Keep the configuration readable and portable

Keep policy-group names stable and clear, organize rules by responsibility, and document the source and purpose of external rule sets. Avoid retaining large numbers of dead nodes, duplicate rules, and unused policy groups in one profile. After each cleanup, use a configuration check or client reload to confirm valid syntax, then test several representative destinations. Before migrating clients, disable the old client’s system proxy and TUN, export the profile, and import it into the new client while checking override support. Do not copy the entire application data directory; databases, caches, and interface state may not be compatible between clients.

For daily use, keep a “minimal working profile” as a diagnostic baseline. It should contain only a listening port, one explicit outbound, a simple policy group, LAN DIRECT rules, and MATCH. When a complex profile fails, use the minimal profile first to confirm that the client and network entry point work, then add DNS, rule sets, and TUN layer by layer. This is more reliable than randomly deleting fields from a profile thousands of lines long and helps distinguish a basic environment problem from an extension configuration problem.

Advanced workflow: from reliable use to a maintainable configuration system

Stage 1: fix the basic entry points

Advanced configuration starts not by adding more rules, but by making the basic entry points predictable. Fix the mixed-port, decide whether LAN access is allowed, choose Rule mode for daily use, and ensure that the system proxy and TUN are not controlled by multiple clients at once. Create a minimal profile and record the configuration directory, client name, and core type. At the end, you should be able to answer clearly: where does a request enter, which profile is active, what is the default policy group, and how do you restore the system network after closing the client?

This stage should also establish a testing method. Choose one LAN address, one destination expected to go DIRECT, and one destination expected to use the proxy, then observe their connection records. Keep the node and network unchanged while adjusting one parameter at a time. If the basic entry point is still unstable, do not rush to add remote rule sets, complex DNS, or process rules; these features increase the number of variables.

Stage 2: restructure policy groups and rules

Separate the node, selection, and business layers. The subscription provides nodes at the bottom; the middle layer contains manual selection, automatic selection, and fallback; the top layer contains stable purpose-based policies such as “Default Outbound,” “Work Services,” and “Download Tasks.” Business rules should reference only the top-level names. When subscription nodes change, the middle and upper layers do not need to be rewritten; when you need a temporary route change, operate on the policy group instead of editing the rules file.

Then organize rule order. Handle private networks and explicit exceptions first, followed by business rule sets and domain rules, address rules, and finally MATCH. For every rule set, record its coverage, update frequency, and target policy. If two collections overlap heavily, keep only the one with clearer responsibility. For frequently changing exceptions, maintain a small local rule section and place it before broad rule sets.

Stage 3: proxy providers and rule providers

When nodes and rules need independent updates, use proxy providers and rule providers to split large remote files out of the main profile. Keep ports, DNS, policy groups, and references in the main profile; let providers update external files at set intervals. This makes maintenance easier but adds checks for download failures, path permissions, and format compatibility. When a provider update fails, the core will usually try its cached copy, so the cache directory must be writable and should retain the latest usable content.

rule-providers:
  local-service:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-service.yaml
    url: "https://example.invalid/rules/local-service.yaml"
    interval: 86400

rules:
  - RULE-SET,local-service,DIRECT
  - MATCH,Proxy Selection

The example URL is a reserved test address used to show the structure. In real use, the rule file’s behavior type must match its contents: domain suits a domain collection, ipcidr suits address ranges, and classical supports complete rule expressions. The path should be inside a working directory writable by the core. Provider names are also stable interfaces; after renaming one, update every RULE-SET reference.

Stage 4: handle processes and LAN traffic by platform

Process rules depend on the operating system and the core’s ability to obtain process information, so support varies by platform. Before using them, confirm in the connection log that process names are visible, then write a PROCESS-NAME rule. Process paths, app-store packaging, and child processes can all affect matching; do not infer the match from the display name alone. On mobile, the client’s per-app proxy interface is usually more suitable because it handles system permissions and app identifiers directly.

LAN sharing requires considering allow-lan, the listening address, the firewall, and access control together. Enabling allow-lan alone does not guarantee that other devices can connect; the local firewall may still block the port. Conversely, listening on every interface broadens the accessible surface. If the client is for local use only, keep LAN access disabled. If sharing is genuinely needed, limit it to a trusted network and document the device’s LAN address and port. Under TUN, also keep private network ranges on DIRECT so printers, storage devices, and development services are not sent through the proxy.

Stage 5: keep change records and a verification checklist

Long-term configuration maintenance needs a simple change log. For every edit, record its purpose, fields changed, validation target, and rollback method. For example: “Add a DIRECT exception for one full domain before its suffix rule; verify the homepage and download API; delete the line and reload if it fails.” This is more valuable than keeping multiple unexplained copies. When a problem occurs, follow the change history instead of rereading the entire profile.

The final verification checklist should cover client startup, profile loading, system proxy, TUN, DNS, LAN, direct destinations, proxy destinations, policy-group switching, subscription updates, and rule-set updates. Not every small edit requires every check, but changes to the entry point, DNS, or TUN call for a complete review. After testing, inspect the log for persistent retries, resolution failures, or interface errors. Even if access appears normal, fix repeated errors before a later network change exposes them all at once.

Further reading and recommended practice order

After completing this guide, choose the next step based on your needs. To establish a basic connection quickly, return to the user documentation and review the shortest workflow; to replace a client, visit the platform download page and check the architecture and system requirements; for port errors, see listening-port troubleshooting; for unexpected DNS results, see DNS testing and correction; for multiple profiles, see profile management; for migrating an older setup, see mihomo configuration differences.

The key to moving from zero to stable use is not writing a complex profile in one go, but progressing layer by layer: make the client and core start reliably, then create an updateable profile; understand Rule, Global, and Direct before writing custom rules; make the system proxy work before enabling TUN; confirm the DNS request path before changing enhanced mode; and only then introduce providers, process rules, and automated maintenance. Preserve a rollback state after every layer so the setup remains maintainable as the client, subscription, or network environment changes.