Clash Configuration Reference

1. YAML Structure Overview

A Clash configuration file usually starts with config.yaml. It is not a collection of unrelated switches, but a hierarchical mapping: top-level fields define listening ports, operating mode, and network capabilities; proxies defines available proxies; proxy-groups organizes them into manually selectable, automatically tested, or failover strategies; and rules directs each type of request to a strategy. Understanding this reference chain matters more than memorizing individual fields. A rule pointing to a nonexistent proxy group, or a group referencing an undefined node, can prevent the configuration from loading or produce unexpected behavior.

Indentation, sequences, and mappings

YAML uses spaces to express hierarchy. Two-space indentation is recommended; do not mix in tabs. The key appears to the left of the colon and the value to the right; lines beginning with a hyphen are sequence items. Indented fields under dns belong to the DNS mapping, while each hyphenated line under rules is a rule. Strings usually do not need quotes, but quoting is safer for values containing colons, hash signs, commas, or text that could be interpreted as a Boolean. Comments begin with a hash and are for readers only; they do not affect runtime behavior.

# Top-level mapping
mixed-port: 7890
mode: rule
log-level: info

# Nested mapping
dns:
  enable: true
  listen: 0.0.0.0:1053

# Sequence of objects
proxies:
  - name: "Example Node"
    type: socks5
    server: 127.0.0.1
    port: 1080

# String sequence
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Node Selection

The example shows the syntax relationship; it does not mean that a local SOCKS node is required. Real subscriptions usually provide a complete proxies or proxy-providers section. When editing by hand, preserve node names exactly because proxy groups reference nodes by name. Spaces within a name are valid, while leading or trailing spaces can create differences that are hard to spot. For that reason, quote node and group names with double quotes and avoid leaving spaces at the end.

The minimum working chain and load order

A complete configuration for rule mode needs, at minimum, a listening entry point, available outbound proxies, policy groups, and a fallback rule. The parser first reads the YAML, then validates field types and references, and finally creates the listening port, DNS module, and proxy groups. Passing YAML parsing does not mean the runtime logic is correct: for example, mode: rule may be enabled while MATCH is missing at the end of the rules, leaving unmatched traffic without a clear fallback; likewise, defining nodes without adding them to a policy group prevents rules from switching them through a consistent policy name.

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "Local Test"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "Node Selection"
    type: select
    proxies:
      - "Local Test"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Node Selection

When checking the structure, follow the chain “rule target → proxy group → node or another proxy group.” Every name must exist, and references must not form a meaningless cycle. A YAML-aware editor can catch indentation errors and duplicate keys early; client logs are better for runtime issues such as unsupported fields, occupied ports, and provider download failures. For specific errors, see the configuration-loading categories in Troubleshooting.

2. Ports, Modes, and General Fields

General fields determine how the client receives system traffic and its basic behavior before proxy protocol details come into play. Graphical clients often manage these values in their interface, so check whether the client uses an override mechanism before editing by hand; otherwise, interface settings may overwrite the file at startup. The most common entry point is mixed-port, which accepts both HTTP and SOCKS5 requests on one port, making it suitable for browsers, command-line tools, and unified system proxy settings.

Rule, global, and direct modes

In rule mode, traffic is matched from top to bottom against rules, making it suitable for long-term use. global mode sends traffic to the global proxy group and is useful for temporarily testing an exit. direct mode connects directly and can confirm whether a problem comes from the proxy path. A mode is only a master switch; it does not delete existing rules. When you return to rule mode, the rules still apply in their original order. For a scenario comparison, continue with How to Choose Between Rule, Global, and Direct Proxy Modes.

LAN listening and the control interface

After enabling allow-lan, whether other devices can connect still depends on the listening address, firewall, and network. Setting the field to true alone does not guarantee a successful connection. If the client is for local use only, leave it disabled. To provide a proxy to devices on the same trusted LAN, set the listening address explicitly and check the system firewall. The external-controller interface lets a graphical client or external dashboard manage the core. It serves a different purpose from the proxy port, so do not enter the control port as the system proxy.

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"

Common log-level values include silent, error, warning, info, and debug. Keep info for normal use; switch temporarily to debug when investigating connection setup, DNS queries, or rule matches, then switch back to prevent logs from growing rapidly. Whether to enable ipv6 depends on the local network, DNS responses, and proxy-node support. If the network has no stable IPv6 path but DNS returns IPv6 addresses, an application may try unreachable addresses first, causing slow initial connections.

In a graphical client, “system proxy” usually points the operating system proxy address to Clash’s listening port. “TUN mode” takes over a broader range of traffic through a virtual network device; the two are not the same field. If you only need browsers and applications that honor system proxy settings, system proxy is usually sufficient. Evaluate TUN when games, command-line programs, or applications that ignore system proxy settings must be routed. TUN also involves permissions, routes, and DNS interception, so a single toggle cannot prove that it works.

3. DNS Configuration and the Resolution Path

DNS settings determine which resolver handles a domain first, what form of address is returned, and whether the rule engine receives domain information at the right stage. Issues such as intermittent page failures or apparently correct rules using the wrong strategy are often caused not by the proxy node, but by DNS requests bypassing the client, polluted resolution caches, or incompatibility between fake-ip and certain LAN devices. Troubleshoot the four stages separately: the application sends a query, Clash receives it, the upstream resolver returns a result, and the connection is established.

Core fields and upstream servers

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

default-nameserver is mainly used to resolve the hostnames of upstream servers such as DoH and DoT endpoints. It is therefore usually set to directly reachable IP addresses, avoiding a loop in which resolving the DNS server’s hostname requires contacting that same DNS server first. nameserver provides the primary resolution sources and may contain regular UDP addresses or supported encrypted DNS addresses. Whether fallback participates, and how its results are filtered, depends on the core and the filtering fields that follow. Do not simply pile up upstream servers: the more sources there are, the harder it becomes to tell where an answer came from, and inconsistent results may increase.

fake-ip and redir-host

In fake-ip mode, the application does not immediately receive the real address. Instead, an address is allocated from a reserved range. When the application connects to it, the core restores the original hostname, then performs rule matching and real resolution. This generally preserves more hostname information and makes rule matches more consistent. The trade-off is that software relying on real LAN addresses, local discovery, or special DNS behavior may need to be added to a filter list. redir-host follows a more traditional resolution flow and is straightforward to reason about, but some connection stages may retain only IP information.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "localhost.ptlogin2.qq.com"

The goal of filtering is not to maximize the list. Add an entry only after confirming that a type of domain must receive its real address, and record why it was added. For an unreliable LAN printer, casting device, or router-management domain, first confirm the queried hostname in the logs, then add the precise suffix and test it. Copying a long filter list all at once can hide the real compatibility issue and send requests down a different resolution path when a domain rule would have been enough.

Selecting resolvers by domain

Cores that support nameserver-policy can choose an upstream based on domain sets. This is useful for sending LAN domains to the router, specific regional domains to an appropriate resolver, or keeping DNS policy aligned with rule sets. The matching syntax depends on the core and its version. When migrating a configuration, test with a small number of domains first rather than assuming every legacy syntax form still works unchanged.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

To determine whether DNS is working, do not look only at whether the final webpage opens. Check the client log for the queried domain, the DNS policy that matched, whether the connection used a hostname or an IP, and whether the system is still sending direct queries through another network adapter. With TUN enabled, also verify DNS interception and system permissions. After changes, clear the operating-system and browser caches, then test with a new domain or a private window so old answers do not distort the result.

4. Proxy Node Fields

proxies is a static list of nodes. Each item needs at least a name, protocol type, server address, port, and the authentication parameters required by that protocol. Subscription generators usually create this section for you; manual maintenance is more useful for local testing, fixed exits, or learning the fields. Different protocols use different field sets, so changing type alone cannot turn one node into another protocol. Verify the provider’s credentials, transport settings, and TLS parameters as one complete set.

Common fields and name references

A node name is not just a display label; it is also an internal configuration key. Duplicate names may cause the client to reject the configuration or make group references difficult to interpret. Names can include a region, purpose, and protocol hint, but avoid putting frequently changing data in them, or every subscription update may break fixed group references. A more robust approach is to let a provider add nodes to groups dynamically through filters.

SOCKS5 and HTTP examples

proxies:
  - name: "Local SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    username: "user"
    password: "your-password"
    udp: true

  - name: "Office HTTP Proxy"
    type: http
    server: proxy.example.com
    port: 8080
    username: "user"
    password: "your-password"
    tls: false

Authentication fields should reflect the server’s actual requirements. A service without credentials does not need empty username and password fields. tls specifies whether the connection to the HTTP proxy server uses TLS; it does not indicate whether the destination website accessed through the proxy uses HTTPS. If the server address is a hostname, startup also depends on DNS. When every group fails for nodes using the same hostnames, check the resolution path for the node servers instead of editing nodes one by one.

TLS, SNI, and transport parameters

TLS-enabled protocols usually also validate the server name. The configuration’s servername, or an equivalent field, supplies the name used during the handshake and should match the server certificate and deployment settings. Skipping certificate verification changes the security boundary and should not be a general long-term fix for connection failures. The right troubleshooting order is to confirm system time, DNS resolution, server name, certificate chain, and transport parameters before deciding that the issue is a special certificate in a test environment.

WebSocket, gRPC, and similar transports often include a path, Host, or service name. These values are part of server-side routing; one missing character can leave the port reachable while the handshake fails. If only some nodes stop working after importing a subscription, compare their transport fields with the original node information. If all nodes fail at once, prioritize checking the local network, system time, DNS, subscription expiry, and core logs.

Client choice also affects which fields are available. Graphical clients such as Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu may use different cores or override interfaces. Discontinued clients such as Clash for Windows and ClashX Meta may also have limited support for newer fields. When a configuration comes from a mihomo environment, do not assume that an older client recognizes every field. To switch clients, visit the download page for platform options.

5. Proxy Groups and Selection Logic

A proxy group is the layer between rules and individual nodes. Rules should point to stable-purpose groups such as “Node Selection,” “Streaming,” or “Direct Downloads,” rather than directly to a node. Then node updates, subscription name changes, or temporary exit switches do not require rewriting the entire rule set. A group can contain nodes, other groups, and built-in targets such as DIRECT and REJECT. Avoid circular references and ensure the deepest layer ultimately reaches a real node or built-in target.

select: manual selection

proxy-groups:
  - name: "Node Selection"
    type: select
    proxies:
      - "Auto Select"
      - "Failover"
      - "Local SOCKS"
      - DIRECT

select does not test or switch proactively; it preserves the user’s current choice. It works well as a unified rule entry point and for scenarios where a region must be selected manually. Placing an automatic test group inside a manual selection group preserves both options. Note that a graphical client may store the selected state separately from YAML. After re-importing, clearing configuration, or renaming a group, the selection may return to the first item. Make the first item a sensible default rather than a target used only for temporary troubleshooting.

url-test: select by test results

  - name: "Auto Select"
    type: url-test
    proxies:
      - "Local SOCKS"
      - "Backup Node"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

url-test periodically sends a test request to the specified address and selects an available node based on the result. The result reflects the node’s connection to that test target, not the real-world speed of every website. A very short interval creates unnecessary requests, while a very long one reacts slowly to route changes. tolerance reduces frequent switching caused by small numerical fluctuations. With lazy enabled, unused groups can reduce active testing. Choose a stable test URL with a small response body and some relevance to the main use case.

fallback and load-balance

  - name: "Failover"
    type: fallback
    proxies:
      - "Primary Node"
      - "Backup Node"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "Connection Distribution"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "Node A"
      - "Node B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

fallback uses the first available node according to list priority, making it suitable for a clear primary-and-backup arrangement; it does not simply choose the node with the lowest measured value. load-balance distributes different connections across multiple nodes, which suits tasks that tolerate multiple exits, but account logins, session-bound services, and sites sensitive to source addresses may not handle frequent exit changes well. consistent-hashing tends to keep the same destination mapped to a more stable node; it should not be interpreted as combining bandwidth across a single connection.

Layering proxy groups

A maintainable design usually has three layers: static nodes or providers supply exits at the bottom; the middle layer organizes them by region, purpose, or testing method; the top layer gives rules stable references. For example, “Hong Kong Nodes” filters names from a subscription, “Auto Select” references several regional groups, and “Node Selection” contains both Auto Select and manual regional groups. Business rules point only to top-level groups such as “Node Selection” and “Streaming.” When the subscription changes, only the filters and middle layer need maintenance.

proxy-groups:
  - name: "Hong Kong Nodes"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|港|HK"

  - name: "Node Selection"
    type: select
    proxies:
      - "Hong Kong Nodes"
      - "Auto Select"
      - DIRECT

Validate regular-expression filters gradually, starting broad and becoming more specific. Node names are controlled by the subscription provider, so relying heavily on emoji, fixed spacing, or elaborate prefixes and suffixes reduces stability. If a group is empty, first check whether the provider updated successfully, then verify the filter expression. Do not simply remove the filter and use every node indefinitely, as testing entries, expiry notices, or special-purpose nodes may enter the production strategy.

6. Rule Syntax, Order, and Fallbacks

rules is evaluated from top to bottom, usually stopping at the first match. Rules therefore need both the correct type and parameters and the correct position. Put exact domains before broad suffixes, and special direct or reject entries before wider matching sets; finish with MATCH as the fallback. Every rule target must be an existing proxy group, node, or built-in target.

Scope differences among domain rules

DOMAIN matches only the specified exact hostname, making it suitable for an API hostname or a single host that needs an exception. DOMAIN-SUFFIX covers the root domain and its subdomains and is a common choice for website routing. DOMAIN-KEYWORD is broader; short keywords may catch unrelated domains, so place them carefully. If api.example.com should connect directly while the rest of example.com uses a proxy, the exact rule must come before the suffix rule.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Node Selection
  - DOMAIN-KEYWORD,stream,Streaming
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

IP rules and no-resolve

IP rules match the destination address. Some cores may resolve a hostname while processing an IP rule to determine its final address. Adding no-resolve prevents that rule from actively resolving hostnames and is useful for clearly IP-based rules such as local networks. It is not a universal performance option and must not be appended to rule types that do not support it. Understand the current core’s rule-resolution behavior before using it.

GEOIP relies on a local geolocation database and matches the destination IP rather than properties of the domain itself. Database availability, update status, and which address DNS returns all affect the result. For finer domain classification, combine rule sets or geosite-style capabilities rather than relying solely on GEOIP. For a complete mainland-China and outside-China routing example and verification process, see A Practical Guide to Clash Routing for Mainland China and Global Traffic.

PROCESS and port rules

Some desktop cores support matching by process name, process path, or destination port. Process rules depend on operating-system permissions and the core’s ability to obtain process information, so cross-platform configurations may not behave the same way. Port rules describe a port, not an application identity; multiple protocols can use the same port. First decide whether the requirement is “route one application through a specific strategy” or “route every connection to a port through a specific strategy,” and do not confuse the two.

rules:
  - PROCESS-NAME,curl,DIRECT
  - DST-PORT,22,Node Selection
  - DOMAIN-SUFFIX,example.net,Node Selection
  - MATCH,Node Selection

Maintain rules in sections where possible: “exceptions, LAN, business categories, regional categories, final fallback,” with a short comment above each section. Reload and verify after changing a small number of rules; this is more reliable than adding thousands of lines and troubleshooting afterward. Reject rules also need a clear purpose: REJECT terminates the matched connection immediately, so an overly broad suffix can break related logins, static assets, and APIs together.

7. Proxy Providers and Rule Providers

Proxy providers proxy-providers load nodes from external files or subscription URLs, while rule providers rule-providers load reusable rules. Both keep frequently changing content out of the main configuration, but their formats and references differ: proxy groups import providers with use, while rules reference rule providers with RULE-SET. Treating a node subscription as a rule provider, or a rule file as a proxy provider, will cause parsing to fail.

Proxy provider configuration

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

proxy-groups:
  - name: "Subscription Nodes"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|新加坡|日本|HK|SG|JP"

type: http means the provider is updated from a remote URL, path is the local cache location after download, and interval is the update interval. A successful update does not mean every node is usable, so health checks can be configured separately. Keep the health-check URL and interval reasonable; with many subscription nodes, overly frequent checks can open a large number of connections at once. If a subscription requires special request headers, some cores allow the relevant fields to be configured, but follow the subscription service’s requirements and never share sensitive credentials in a public configuration.

A group’s use field can reference one or more proxy providers and combine them with filter, exclude-filter, and similar features. Filters are usually regular expressions. Start by testing a small set of keywords against the node names shown by the client, then expand them; combinations can cover regional names, abbreviations, and capitalization. If filtering returns no nodes, the group has no exit to offer, and the log will usually identify the provider or group involved.

Rule provider configuration

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

  local-network:
    type: file
    behavior: ipcidr
    format: text
    path: ./ruleset/local-network.txt

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,Node Selection

behavior describes the type of rules in the provider, commonly domain rules, IP ranges, or classical rules. It must match the remote file’s content. format states whether the file uses YAML, plain text, or another format supported by the core. Changing the extension does not change the content format; when loading fails, open the file and inspect its actual structure. Remote rule providers are also cached at path; use separate paths to prevent two providers from writing to the same file.

A YAML rule file for domain behavior can use a payload-list structure:

payload:
  - "example.com"
  - "+.example.org"
  - "full:api.example.net"

Prefix semantics can differ between cores and rule projects, so follow the provider’s documentation when using third-party sets. For complete control, maintain a small number of high-value rules yourself and use large public categories as supplements. The more external sets you add, the more complex the update chain becomes. If a remote URL is unavailable, the presence of a local cache can affect startup. Important configurations should remain clear for direct, proxied, and fallback traffic even when an optional provider temporarily fails to update.

Update and persistence boundaries

Manage the main configuration, proxy-provider caches, and rule-provider caches separately. A client may rewrite the main configuration during a subscription update without deleting local overrides; after changing the configuration directory, it may also stop reading the old caches. When a subscription appears updated but the node list does not change, verify the active configuration, provider update time, actual cache path, and whether the group references the same provider name.

On headless Linux systems, mihomo often runs directly as a service, so the configuration directory and service-user permissions directly affect provider-cache writes. With systemd, give the service user read access to the configuration directory and the necessary write access to cache directories such as providers and rulesets. For the deployment process, see Deploying the Clash Core as a Linux Command-Line Service.

8. Overrides, Merging, Validation, and Rollback

Subscription configuration is regenerated during updates, so manual edits made directly in the subscription body are often lost at the next update. Graphical clients therefore commonly provide overrides, merging, or script processing: the subscription supplies nodes and the base configuration, while local overrides handle ports, DNS, added proxy groups, and custom rules. “Merging” is not defined identically across clients: some overwrite keys, some append arrays, and some allow rules to be inserted at a specified position. When migrating clients, validate the merge result with a small configuration first.

Mapping overrides and array handling

For scalar fields such as mode and mixed-port, the later value usually overrides the earlier one. For mappings such as dns, fields may be merged recursively or replaced as a whole. For arrays such as rules, proxies, and proxy-groups, appending, prepending, and replacing produce completely different results. Rule arrays deserve special attention: if a custom exception is appended after the subscription’s MATCH, it will never match.

# Local override example; see the client for the exact entry point
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

Before writing an override, decide whether the goal is to replace subscription fields or supplement them. Ports and log levels are usually good candidates for replacement; custom rules often need to be prepended to the rule array; local groups may need to be appended, while ensuring that every provider they reference exists in the final configuration. Do not inspect only the override file; inspect the final configuration passed to the core after merging. Many problems arise because an override looks correct while the final order differs.

Prepending rules and adding proxy groups

Suppose internal company domains must connect directly. The custom rules must appear before broad proxy rules and MATCH. If the client provides separate prepend and append areas, use the prepend area. When adding a group, also confirm that its name does not duplicate an existing subscription group; duplicate-object behavior depends on the implementation and may replace the original group entirely. The safest approach is to use clear, collision-resistant names and inspect the reference chain after merging.

# Expected final rule order
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - RULE-SET,applications,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

Validate in stages

When changing a complex configuration, do not replace DNS, proxy groups, and the entire rule set at the same time. First verify that the YAML loads; next confirm that the listening port and control interface start; then confirm that DNS queries enter the core; check that the groups contain usable nodes; test rule matches with a small number of domains; and only then import large rule providers. Each step adds one variable, which narrows the possible cause of an error.

1. Save a baseline: Keep a copy of the configuration that currently starts and connects successfully, and record the active configuration name.
2. Check the syntax: Verify indentation, colons, quotes, and array structure, paying particular attention to duplicate keys flagged by the editor.
3. Read the logs: Fix the first clear error first; later messages may simply be cascading effects of the original error.
4. Check references: Verify each rule target, proxy-group name, node name, provider name, and local path.
5. Verify behavior: Use the logs to confirm the actual matched rule and final strategy instead of judging only by page-load speed.

Common error paths

For “configuration file format error,” first check indentation, tabs, unclosed quotes, and spaces after colons. For “proxy group not found,” verify capitalization, full-width versus half-width punctuation, and trailing spaces. For “provider update failed,” check URL reachability, cache-directory permissions, and file format. For “port listening failed,” see whether another client or an old core process is using the port. For “rule never matches,” confirm the current mode, rule order, connection reuse, and whether the log reports a hostname or an IP.

If the configuration loads but no node can connect, temporarily use DIRECT to test the local network, then test one static node before restoring the groups. If only one category of website is affected, start with rule logs and DNS queries rather than reinstalling the client. If the issue begins only after enabling TUN, also check system permissions, the virtual network adapter, routing table, firewall, and DNS interception. Android background operation is also affected by VpnService authorization and battery-optimization policies; see Android VpnService and Battery-Optimization Allowlist Settings.

The final configuration should achieve three things: clear entry points, so every application knows which port to use; closed references, so every rule can follow a group to a real exit; and controlled updates, so subscription changes do not overwrite critical local logic. Once these are in place, refine regional groups, DNS policies, and large rule providers. Complexity should serve a clear requirement, not a field count. For issues that still do not fit a category, see Troubleshooting. To repeat the import and connection workflow, return to the Clash Setup Tutorial and check each step.