A Profile Is More Than a Proxy List

In a Clash client, a Profile usually means a configuration that the core can load. It may come from a subscription URL or be imported manually from a local config.yaml. A usable configuration stores more than server addresses: it also describes listening ports, DNS behavior, proxy nodes, proxy groups, routing rules, and TUN settings. Switching Profiles essentially makes the client reload this entire runtime state.

Content returned by a subscription service is not always complete Clash YAML. Some links return a Base64-encoded collection of nodes and require a subscription converter to generate Clash format; others return YAML containing proxies, proxy-groups, and rules directly. A successful import only means the client accepted the text. Actual connectivity still depends on field compatibility, working nodes, and valid rule references.

What Happens When a Profile Loads

  1. The client reads the YAML and checks indentation, field types, and required parameters.
  2. The Clash or mihomo core creates local listening ports, such as the HTTP and SOCKS mixed port 7890.
  3. The core creates proxies and proxy groups, then resolves the members referenced by each group.
  4. Rules enter the matcher from top to bottom, while rule providers download remote content as needed.
  5. When TUN is enabled, the Android client requests VPN permission from the system and creates a virtual network interface.

Failure at any stage can result in “the configuration imported successfully but will not start.” For example, invalid YAML indentation stops parsing; a proxy group that references a nonexistent node name fails during validation; and an unreachable remote rule set may affect only the routing decisions that depend on it.

A Layer-by-Layer Look at the Core config.yaml Fields

YAML uses indentation to express hierarchy, typically with two spaces rather than tabs. The compact example below is intended to illustrate the structure. Server addresses, credentials, and protocol parameters are shown only to indicate field placement and should not be used as a directly connectable configuration.

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies:
  - name: HK-A
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: Proxy Selection
    type: select
    proxies:
      - HK-A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy Selection
  - GEOIP,CN,DIRECT
  - MATCH,Proxy Selection

Basic Listening and Runtime Modes

mixed-port: 7890 accepts HTTP and SOCKS5 proxy connections on the same port. Desktop applications often point the system proxy to 127.0.0.1:7890. Android clients more commonly route traffic through VpnService or TUN, but the mixed port remains useful for LAN debugging or manual configuration of an individual app.

  • mode: rule: Matches rules from top to bottom and is the most common mode for everyday use.
  • mode: global: Sends most traffic to the global proxy group instead of evaluating ordinary routing rules in sequence.
  • mode: direct: Connects traffic directly, which is useful for checking whether a problem comes from the proxy path.
  • allow-lan: false: Keeps the local proxy ports closed to LAN devices. If sharing is needed, also check the listening address and the system firewall.
  • log-level: info: Keeps standard runtime logs. For short-term troubleshooting, switch to debug and restore the previous level afterward.

proxies: Individual Egress Nodes

Each item under proxies represents a node. Different protocols require different fields. For example, Shadowsocks uses cipher and password, while Trojan typically uses password, the TLS server name, and related parameters. mihomo supports additional protocols and extension fields, but that does not mean every older Clash core can recognize them.

name is the internal reference key. Names used by proxy groups must match node names exactly, including spaces, capitalization, and symbols. Duplicate node names may cause some clients to reject the configuration, while other implementations may overwrite the earlier entry, so names should remain unique when a subscription is generated.

proxy-groups: Selection and Health Checks

A proxy group combines multiple nodes or other proxy groups into an egress that rules can reference. Common types include manually selected select, test-based url-test, failover fallback, and load-distributing load-balance.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - HK-A
      - SG-A
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

This configuration runs a test every 600 seconds. tolerance: 80 means the current node does not need to be changed when the latency difference stays within 80 ms. Reducing the interval to 30 seconds increases network requests and background wakeups, which is usually unnecessary on mobile devices.

rules: First Match from Top to Bottom

Clash does not evaluate every rule for each connection. It searches in order and stops at the first match. More specific domain rules should come before broader rules, with MATCH typically handling remaining traffic at the end. If MATCH,DIRECT is placed on the first line, later proxy rules can never take effect.

  • DOMAIN,api.example.com,Proxy Selection: Matches the exact domain only.
  • DOMAIN-SUFFIX,example.com,Proxy Selection: Matches the base domain and its subdomains.
  • IP-CIDR,192.168.0.0/16,DIRECT: Matches the specified IPv4 network range.
  • GEOIP,CN,DIRECT: Matches according to an IP geolocation database.
  • MATCH,Proxy Selection: Handles connections that matched none of the preceding rules.

How DNS, Fake-IP, and TUN Settings Work Together

DNS fields determine how domains are resolved, but they do not independently determine the traffic egress. After a domain is processed by the DNS module, the connection still enters the rule system. With fake-ip enabled, local DNS returns a mapped address; the core uses that mapping to recover the domain and apply the appropriate rules. This helps prevent domain rules from failing when an app performs its own resolution.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query

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

198.18.0.0/16 is a commonly used Fake-IP mapping range. If an app connects to this network, that does not mean it is accessing an identically named address on the public internet. The mihomo core maintains the relationship between domains and mapped addresses, then passes the connection to the rules and selected node.

When to Use Fake-IP Filtering

LAN device discovery, some gaming platforms, and apps that depend on real local network addresses may not work well with Fake-IP. In that case, add exact domains or wildcard rules to fake-ip-filter. Avoid broadly excluding every commonly used domain, or domain-rule coverage may suffer and the app may once again bypass the proxy DNS.

TUN Settings Do Not Grant Android VPN Permission

tun.enable in the configuration is only a core parameter. Whether Android allows a VPN interface to be created is controlled by system authorization through VpnService. The first launch usually requires confirmation in the system connection prompt; if another VPN app is already running, the new interface may not be created.

Android clients do not all organize their menus the same way. A common path is Settings → Configuration → TUN Mode, or TUN can be enabled directly from the service card on the home screen. After changing stack, route exclusions, or DNS hijacking, stop and restart the service so old connections and routing tables are rebuilt.

What Subscription Updates Replace

A remote Profile usually stores a subscription URL. When the client updates it, the content is downloaded again from that address and the remote snapshot for the corresponding configuration is replaced. Nodes, proxy group members, and rule order may all change with the new content. Direct edits to the downloaded YAML are usually overwritten at the next update.

Remote Content, Local Overrides, and Runtime Configuration

Understanding these three layers helps explain why a change may appear to be ignored. The first layer is the raw configuration returned by the subscription server. The second is the local Profile saved by the client. The third is the final configuration passed to the core after overrides, scripts, or compatibility conversion. The interface may show the second layer, while runtime logs reflect parameters from the third.

  1. First record the current Profile name and update time, such as 2026-07-30 09:40.
  2. Update the subscription manually, confirm that the response status is normal, and check whether the node count has changed.
  3. Open the configuration preview and verify that proxy-groups and rules still reference valid names.
  4. Check the DNS, routing, and override options under Settings → Configuration.
  5. Reload the configuration or restart the service, then use connection logs to confirm the rule and proxy group actually selected.

Set the automatic update interval according to how often the subscription changes. If node information is adjusted only once a day, there is no need to fetch it every 15 minutes. A common starting point is 1440 minutes; use a manual update when an immediate change is needed. Intervals that are too short only increase background requests and retry failures.

Changes Best Kept Locally

Permanent LAN-direct rules, personal domain rules, and device-specific DNS settings are better kept in an override layer than edited directly in the remote file. If the client supports Merge, Mixin, or overrides, use it to combine added fields with the subscription result. Before merging, confirm how arrays are handled: some implementations append rules, while others replace the entire array.

Rule order is especially sensitive. If a personal direct rule is appended after the final MATCH, it can never match. Insert it before broad rules and the final rule instead, then check the logs for matching entries such as DOMAIN-SUFFIX or IP-CIDR.

Managing Multiple Profiles and Switching Between Them

Work, home, and test networks can each be saved as separate Profiles. The value of multiple Profiles is isolating rules and parameters, not piling every node into one file. Give each Profile a recognizable name, such as Daily-Meta, Office-Direct, or Lab-TUN, and record its source and purpose.

Four Differences to Check Before Switching

  • Core compatibility: Check whether the configuration uses mihomo-specific fields. An older Clash core may fail to load when it encounters an unknown protocol or rule-set format.
  • Port conflicts: If two local services listen on 7890 or DNS port 1053 at the same time, the service started later will report a binding error.
  • Mode state: Some clients treat rule, global, and direct as global interface states, so they may not switch with the Profile.
  • Override scope: A global override may apply to every Profile, while a Profile-specific override affects only the current entry.

After switching configurations, existing TCP connections may continue using the old egress until they close. For verification, reopen the app or clear the test connections before checking the new logs. Refreshing a web page alone may not create a new connection because HTTP/2 and QUIC can reuse existing sessions.

What to Save in a Backup

Keep an independent copy of manually written local configurations and record the modification date. For remote subscriptions, prioritize saving the subscription entry point, override rules, and client settings rather than treating every downloaded temporary copy as the primary file. Subscription URLs often contain access credentials, so store backups in a controlled location and never paste them into public logs, screenshots, or issue reports.

When moving from an older client to a Clash Meta or mihomo client, import one Profile first for validation before migrating the rest. Pay particular attention to proxy-providers, rule-providers, proxy-group filter expressions, and TUN fields. Successful YAML parsing does not guarantee that a remote provider can be downloaded or that the current core supports every proxy protocol.

A Systematic Order for Diagnosing Profile Load Failures

Troubleshoot configuration problems layer by layer. First determine whether the file parses, then whether a node can establish a connection, and finally whether the rules send traffic to the expected egress. Repeatedly testing nodes while skipping parsing errors usually produces no useful conclusion.

Layer 1: YAML and Field Validation

  • Check that a space follows each colon, for example mode: rule.
  • Check the indentation of list items - relative to their parent fields.
  • Names containing colons, hash signs, or special characters can be enclosed in quotation marks.
  • Check that every name referenced by proxy groups, rules, and providers exists.
  • Check the line number in the client log and fix the first parsing error before addressing later messages.

Layer 2: Node and Network Connectivity

Testing latency for a single node only describes the connection result for the test URL; it does not mean every website is reachable. You can switch briefly to global for verification, then return to rule. If global mode works but rule mode does not, inspect the matched rule and the current proxy-group selection. If neither mode works, continue checking node parameters, system time, DNS, and network restrictions.

Layer 3: Rules and Final Egress

Find the matching entry for the target domain in the logs and confirm which rule matched, which proxy group handled it, and which node was finally selected. If the logs show only an IP address, check whether Clash controls DNS and whether the app uses its own encrypted DNS. During troubleshooting, set the log level to debug; restore it to info afterward.

Building Maintainable Profile Habits

The key to configuration management is separating sources and responsibilities. The subscription provides nodes and baseline policies, local overrides handle personal rules, and client settings control system interfaces and app behavior. Mixing all three into one remote file makes it difficult to identify the source of changes after an update.

  1. Give each Profile a clear purpose-based name and keep a note of its source.
  2. Record the currently working nodes and proxy-group selections before updating, then compare key fields afterward.
  3. Put personal rules in a reusable override layer and confirm where they are inserted.
  4. Limit frequent automatic health checks and subscription refreshes, especially on mobile devices where background wakeups should be controlled.
  5. After switching Profiles, create new test connections and verify the rules through logs rather than relying only on the status icon.
  6. Check configuration compatibility before upgrading the core, especially protocol extensions, rule providers, and TUN parameters.

Once a Profile is understood as a complete snapshot of proxies, proxy groups, rules, DNS, and system-routing parameters, subscription updates and multi-Profile switching become much easier to manage. When something fails, trace it layer by layer through configuration parsing, node connectivity, DNS processing, rule matching, and system routing instead of repeatedly deleting and reimporting the same file.