Clash Configuration File Reference

YAML Structure and File Scope

Clash configuration files usually use YAML. A common filename is config.yaml, but the name alone does not determine how the file is used. The active file depends on the configuration selected in the client or the file argument passed when starting the core. Examples on this page use fields commonly supported by mihomo. Other Clash-family cores may support only some of them, and a client may generate a separate runtime configuration before launch. When troubleshooting, first identify the core, the configuration source, and the final file path being loaded; then check whether a particular field is supported.

Mappings, Lists, and Indentation

YAML mappings express settings as key-value pairs, such as mode: rule. Lists use hyphens to introduce each item, as in the entries under rules. Top-level fields start at the beginning of a line; nested fields are indented with spaces, typically two. Indentation defines structure—it is not just visual formatting. Aligning nameserver with dns makes it a separate top-level key instead of a DNS subkey. The file may still parse, but the core will not necessarily use it as intended.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

proxy-groups:
  - name: Outbound
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Outbound

This minimal configuration is for inspecting the structure and contains no remote proxy nodes. After import, rules send requests to “Outbound,” whose only member is currently DIRECT. Use it to check whether the file loads, ports listen, and rule references resolve—not to test remote proxy access. Snippets in other sections must be merged into the relevant fields. Do not simply concatenate examples that each define a top-level dns section.

Strings and Data Types

Booleans are written as true or false, ports as integers, and addresses and names usually as strings. Quote passwords, values that start with special characters, and text containing a colon followed by a space. Comments start with #; quoting a password that contains a hash prevents the rest from being treated as a comment. Single-quoted strings do not interpret backslash escapes, while double-quoted strings interpret some escape sequences. When copying a password from another format, do not add or remove backslashes casually.

Each item in a list is usually a mapping. A node’s keys, such as name, type, and server, must belong to the same list item. Missing a hyphen can merge a new node into the previous item. Repeating name in one mapping or repeating a top-level field may be rejected by the parser or cause a later value to overwrite an earlier one. Do not rely on duplicate keys for overrides; use an explicit merge mechanism provided by the client.

Full Configurations vs. Proxy Collections

A full configuration can include ports, DNS, proxies, proxy groups, and rules. A proxy collection file usually contains only a proxies list, while a rule collection has its own payload structure. All three can use YAML, but they are not interchangeable. A subscription URL returning valid YAML does not mean it can be imported directly as a main configuration. If it returns a single-node URI, Base64 text, or a login page, check the subscription format before changing indentation.

Save a copy of the original file before editing. Use an editor set to UTF-8 that can display whitespace. Keep a minimal loadable structure, then add content one section at a time in this order: DNS, proxies, proxy groups, and rules. Change only one area at a time so you can pinpoint and revert errors. An online YAML formatter is not required. Configuration files often contain subscription URLs and credentials, so local editing and syntax checks are a better fit.

Ports, Modes, and Access

General fields determine how the core receives requests, which routing mode it uses, and who can connect. Start by distinguishing three entry points: apps can send proxy requests directly to an HTTP or SOCKS port; system proxy settings can direct compatible apps to those ports; and TUN routes matching traffic through a virtual network interface. Opening a listening port does not automatically configure the system proxy, and enabling the system proxy does not mean every app will use it. When troubleshooting the entry point, check which proxy method the app actually uses.

port, socks-port, and mixed-port

For everyday desktop use, you can start with just mixed-port to simplify port selection in apps. Do not assign multiple listeners to the same address and port, and check whether another client or an old core process is already using the port. Changing a port will not necessarily update proxy addresses entered manually in apps. A client-managed system proxy may follow the change, but verify that the host and port in system settings match the current instance.

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

allow-lan and bind-address

Set allow-lan: false for local-only access. To share the proxy with devices on your LAN, set it to true and configure an appropriate bind-address. Binding to 127.0.0.1 accepts connections only from the local IPv4 loopback interface; binding to "*" broadens the listening scope. Reachability depends on the listening address, OS firewall, router isolation, and client authentication. Changing one boolean alone does not guarantee that a phone or TV can connect.

Devices on your LAN should use the address of the computer running the core, not their own 127.0.0.1. The computer’s address may change when its DHCP lease renews; a router address reservation can help keep it stable. Allow access only from trusted networks, and never expose a proxy port to the public internet. See Sharing a mixed-port proxy on your LAN with allow-lan for setup and firewall checks. A shared proxy listener is not an admin interface; restrict them separately.

mode and log-level

mode: rule selects a target according to the order of rules; global uses the global proxy group; direct sends traffic directly. Switching modes can help narrow down a problem, but access working in global mode does not prove that rule mode has a syntax error. A rule may simply choose a different outbound. In rule mode, LAN requests, specific domains, and fallback traffic can each use different targets—which is why rule order matters.

log-level is commonly set to info; you can switch briefly to debug while troubleshooting. Detailed logs may expose visited domains, connection targets, or subscription information, so avoid keeping or sharing them publicly. ipv6: false controls related IPv6 behavior in the core, but does not disable all IPv6 networking in the operating system. The DNS section has its own ipv6 setting. Consider both settings in the context of the traffic path; neither proves that IPv6 is blocked across the entire device.

TUN settings such as enable, auto-route, auto-detect-interface, and dns-hijack involve permissions, network interfaces, and system routes. Similar configuration syntax does not mean setup is the same on every platform. First follow the Quick Start steps to confirm that a standard proxy listener works, then enable TUN. Otherwise, port, permission, and DNS issues can appear at once, making the cause harder to isolate.

DNS and Fake-IP

dns is a separate mapping section. enable turns the built-in DNS server on or off, listen sets its listening address, and enhanced-mode selects the enhanced DNS mode. Even with DNS enabled, whether system queries reach the core depends on system DNS settings, TUN interception, or other forwarding rules. If no queries reach the configured listener, the core cannot map those queries to domains or replace encrypted DNS used directly by an app.

Basic Resolution Flow and Encrypted Upstreams

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

The example assumes 192.168.1.1 is a router that can resolve local names; replace it if your network uses a different address. nameserver lists regular upstream resolvers. Supported address formats depend on the core; this example uses DNS over HTTPS. If an upstream address uses a hostname, that hostname must be resolved first. default-nameserver is often used for this bootstrap lookup. Do not make bootstrap resolution depend on the same proxy path that has not been established yet, or startup can get stuck in a dependency loop.

nameserver-policy assigns resolvers by domain and is useful for sending LAN names to a local DNS server. It controls which resolver handles a query; it does not choose the connection’s outbound target like rules does. fallback and fallback-filter can influence result selection, but their behavior is more involved than “try the next server if the first fails.” Unless you have a clear need for split DNS, start with one easy-to-understand resolution path. It is simpler to verify than a pile of public upstreams.

Fake-IP vs. redir-host

In fake-ip mode, the core can return a synthetic address from a reserved pool, then use its mapping to recover the domain and choose an outbound. The address is not the website’s real IP; seeing a result starting with 198.18 in the command line does not necessarily indicate a DNS error. redir-host primarily uses the real resolved address. Both modes require a working traffic entry point and domain information. Choose based on app compatibility, the DNS path, and how transparent proxying is configured.

fake-ip-filter excludes domains that should not receive synthetic addresses, such as some local names or services with special validation requirements. It does not make all traffic from an app go direct or change routing rules automatically. To troubleshoot compatibility, exclude one specific domain and compare behavior rather than adding every common suffix. A broad exclusion list can send different traffic through different DNS paths, making future maintenance harder.

Resolving Proxy Hosts and Rule Targets

A proxy server’s hostname must be resolved before connecting to that proxy. mihomo’s proxy-server-nameserver can specify an upstream for these lookups; respect-rules may also be involved when DNS connections follow routing rules. Make sure the proxy server’s hostname does not depend on the proxy itself to resolve. First confirm that the node address resolves through a regular direct upstream, then introduce DNS routing gradually. This is more reliable than copying a complex split-DNS snippet.

IP rules may need to resolve a domain before checking whether its address falls within a given range. no-resolve on a rule prevents that rule from triggering an extra lookup for IP matching, but does not block DNS queries already made by an app. To troubleshoot DNS leaks, inspect system resolution, app-level DoH, core upstreams, and proxy-side resolution separately. Checking one DNS address shown by a browser does not prove that every query from the device follows the same path.

To validate DNS, query a regular domain first, then a local domain, and finally test a connection to the relevant service. If regular domains work but local names fail, check local resolution policies and filters. If all queries time out, check the listener address, port, firewall, and upstream reachability. DNS resolution and an app connection are separate stages. If resolution fails, do not start by changing proxy protocol parameters.

Proxy Fields

proxies is a list of outbound proxies that proxy groups can reference. Common fields include name, type, server, and port; authentication and transport fields vary by protocol. A proxy name is a reference identifier in the configuration, not just a display label. If you rename it, update any matching references in proxy groups. Keep names unique so you can tell which proxy was selected.

Common Fields and Protocol-Specific Fields

type tells the core which protocol to use to interpret the other parameters. For example, Shadowsocks requires cipher and password; Trojan uses a password and involves TLS; VMess and VLESS use their own identity and transport parameters. Changing only type does not convert one protocol into another. The protocol, authentication, transport layer, and TLS settings must match the server. Check with your provider for any missing parameters.

proxies:
  - name: SS-Example
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: Trojan-Example
    type: trojan
    server: 192.0.2.20
    port: 443
    password: "your-password"
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

These documentation-only IP addresses and example domains show the field structure; they are not usable servers. Replace the server address, credentials, and TLS hostname with your actual values. server can be an IP address or domain name; port is the server's listening port, not your local mixed-port. A domain-name server must be resolved before connecting; an IP-address server may still require a separate TLS hostname.

TLS, SNI, and Certificate Verification

Trojan commonly uses sni to set the server name for the TLS handshake; other protocols may use fields such as servername, so follow the protocol’s requirements. The TLS hostname must match the server certificate and deployment; do not enter an arbitrary website domain. Keep certificate verification enabled with skip-cert-verify: false. If certificate validation fails, first check the system clock, hostname, and certificate chain. Disabling verification is not a general fix.

A WebSocket request path, the Host request header, and a gRPC service name are separate transport settings. If the server requires WebSocket, the client also needs the matching network and ws-opts; path capitalization and slashes may affect routing. When converting an existing URI to YAML, check these details one by one. Encoded characters in a link must be decoded correctly. A password or path decoded incorrectly can make the configuration load successfully but fail during the handshake.

UDP and End-to-End Support

udp: true enables the relevant UDP capability for protocols that support the field; it does not guarantee that UDP will work across the entire path. The app entry point, proxy protocol, server setup, firewall, and carrier network can all impose limits. If web pages load but real-time communications fail, first check whether the app is using an entry point that supports UDP, then inspect the node settings. A successful HTTP test does not prove that DNS, QUIC, or game traffic will work.

Some protocols also use ALPN, client fingerprints, Reality, or other protocol-specific parameters. Field availability depends on the core implementation, and an older client may accept the YAML without supporting the protocol. For an unknown field or unsupported type, check core compatibility before changing clients. The downloads page offers Clash Plus and other clients for different platforms. Do not remove unfamiliar fields just to make the configuration load; doing so may change the authentication or transport required by the server.

Manually maintained proxies work well for a small, stable set of outbounds. If nodes change often, update them centrally in a proxy collection and reference them from proxy groups. Avoid editing names directly in a subscription-generated proxy list, as the next refresh may restore the original names. If the issue began after a format conversion, use the YAML subscriptions and proxy link formats guide to check whether authentication, transport, and TLS parameters were preserved.

Proxy Groups and Providers

proxy-groups defines outbound selection, while proxy-providers defines where a collection of proxies comes from. They have different roles: providers supply candidate proxies, and groups decide how to select from them. Rules usually reference a stable group name rather than proxy names that change frequently. This way, node updates do not require rewriting every rule as long as group names and provider references remain valid. Groups can reference other groups, but avoid self-references and circular references.

select, url-test, and fallback

select lets a user or management API choose a member, providing direct control over the outbound. url-test selects automatically based on the result of a probe to a specified URL. fallback typically selects the first available member in order. load-balance distributes traffic according to a supported balancing strategy; it does not split one connection across multiple routes to combine their bandwidth. Each type addresses a different need. Do not switch every group to automatic testing just because it sounds more convenient.

proxy-groups:
  - name: Outbound
    type: select
    proxies:
      - Auto Select
      - Failover
      - DIRECT

  - name: Auto Select
    type: url-test
    use:
      - My Proxies
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50

  - name: Failover
    type: fallback
    use:
      - My Proxies
    url: https://cp.cloudflare.com/generate_204
    interval: 300

proxy-providers:
  My Proxies:
    type: file
    path: ./providers/nodes.yaml
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300

This example expects providers/nodes.yaml to exist in the working directory and contain a proxy collection with a proxies list. use references the provider named “My Proxies,” not the filename or a specific proxy. The proxies list can directly reference existing proxies, other groups, or built-in outbounds. You can combine both approaches, but confirm that the candidate collection contains proxies; otherwise, an automatic group may have no available members.

What Probe Settings Actually Do

url sets the health-check target, interval usually sets the probe frequency in seconds, and tolerance helps prevent frequent switching over small differences in supported automatic selection modes. Probe results reflect requests to that specific test target, not every website, long-lived connection, or large download. A blocked test site, TLS handshake issue, or DNS failure can make a probe fail even when the proxy server’s port is reachable.

Provider health checks and group-level tests may both be configured. Before setting them up, decide which checks belong to the provider and which to the group, so the same proxies are not tested unnecessarily often. Shorter intervals are not always better, especially on mobile devices, where they add wakeups and network requests. Existing connections usually do not move to a new proxy immediately when a group changes. Test the new selection with a fresh connection instead of watching an existing download.

Provider Updates, Filters, and Stable Names

An HTTP proxy-providers entry uses url, path, and interval to specify the remote source, local cache, and update schedule. The downloaded content must use a collection format accepted by the core; it cannot be an arbitrary webpage or a full client configuration. Keep credentials in the local configuration if the remote URL contains them—do not include them in a public issue report. For update failures, see Troubleshooting subscription update failures to determine whether the request failed or the content could not be parsed.

A group’s filter can select candidates by name; treat its matching pattern as a regular expression. If naming conventions change, the filter may return no results. After updating a subscription, check not only the full proxy list but also the actual members of each group. Region names, special characters, and capitalization all affect matching. Start with a simple pattern that selects the intended proxies, then narrow it down. That is easier to maintain than a complex expression written all at once.

profile.store-selected can save proxy group selections, while profile.store-fake-ip can save related mappings. Whether persistence is useful depends on how you use the client and how it manages configuration. After changing group members, check the current selection again to catch mismatches between saved choices, filter results, and the active configuration.

Rules and Rule Providers

rules is an ordered list. The core checks rules from top to bottom and uses the outbound target for the first matching rule. Rules are not automatically sorted by apparent specificity, and a later domain rule will not jump ahead. A common approach is to put specific local or business exceptions first, followed by broader domain and IP rules and rule providers, then a final MATCH catch-all. Order is part of the configuration logic, so check the rules around any change you make.

Domain, IP, and Catch-All Rules

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Outbound
  - DOMAIN-KEYWORD,example,Outbound
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - RULE-SET,Local Domains,DIRECT
  - MATCH,Outbound

DOMAIN matches an exact hostname, making it suitable for a single host. DOMAIN-SUFFIX matches a domain and its subdomains. DOMAIN-KEYWORD matches based on a keyword and can cover a broader range. A keyword that is too short may match unrelated sites. IP-CIDR and IP-CIDR6 match IPv4 and IPv6 ranges, respectively. The private network ranges in this example are not exhaustive; they illustrate the syntax. Add ranges for your actual network rather than treating this snippet as a complete list of private addresses.

A rule’s outbound target can be a proxy name, a group name, or a built-in target such as DIRECT or REJECT. Names must match their definitions exactly, including spaces and punctuation. MATCH has no additional conditions, so put it last as the catch-all. If it appears at the top, most later rules will never run. If a business rule does not match, first check whether a broader rule above it has already caught the request instead of adding another similar rule.

rule-providers Declarations and File Formats

rule-providers lets you reuse a set of matching conditions. type identifies a local file or HTTP source, behavior describes the content semantics, and format specifies the serialization format. A domain collection contains domain match entries; an ipcidr collection contains address ranges; a classical collection can contain supported classic rule conditions. Do not put proxy collections in a rule collection directory. Both may be YAML, but their root keys and entries are different.

rule-providers:
  Local Domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domain.yaml

# Contents of ./rules/local-domain.yaml:
# payload:
#   - "+.lan"
#   - "intranet.example.com"

The payload above is the contents of a separate file; a comment does not create that file. The main configuration assigns a target to this collection with RULE-SET,Local Domains,DIRECT. With the classical format, collection entries usually describe conditions; do not mechanically append an outbound name as you would in a main configuration rule. Remote collections also need to be downloaded and cached. If the first startup cannot fetch one and there is no local cache, resolve the resource access issue first.

Resolution Timing, Processes, and Platform Differences

Some IP conditions trigger DNS resolution to match domain requests. A matching rule with no-resolve does not actively resolve the domain for that rule. This can suit traffic where the destination IP is already known, but it can also stop rules that depend on resolution results from matching. Domain rules need the core to know the domain. If traffic exposes only a destination IP and there is no DNS mapping or sniffed domain, do not assume domain conditions will still work.

Process rules such as PROCESS-NAME depend on information from the operating system, core permissions, and the traffic entry point. A process condition available for a desktop app may not apply to another device behind a router. GEOIP and GEOSITE also depend on data resources and core support; changes to the underlying databases can change matching results. When moving a configuration between platforms, check these external dependencies instead of comparing rule text alone.

Organize rule files by purpose and add brief comments. To test an exception, place a rule for one known domain near the top, create a new connection, and confirm that it matches before deciding on its permanent position. Do not keep adding rules at the very top as a permanent fix; future maintainers may not know why the order matters, and broad rules may mask existing routing logic.

Subscriptions, Overrides, and Merging

The “subscription configuration” in a client is not necessarily the file the core ultimately reads. A common workflow downloads a remote document, saves a subscription copy, applies local overrides or scripts, adds ports and TUN settings controlled by the UI, and then generates a runtime configuration. The stages and their order vary by client. If you changed a file but the settings did not change, first look for the runtime configuration or configuration preview. Check the final fields instead of repeatedly editing the download cache.

Source Files, Persistent Settings, and Runtime Output

The source file preserves content provided by the subscription; local overrides express device-specific needs; the runtime configuration combines both with client settings. Each layer may define the same mixed-port, dns, or tun fields. UI switches may also take precedence. Do not guess the priority from filenames. Check the client documentation or run a single-field test: change just a port or log level, regenerate the config, and inspect the result.

Configuration management differs across clients such as Clash Plus, Clash Verge Rev, and FlClash. Check the actual client for how to import, extend, and merge configurations. When switching clients, do not treat an extension script specific to one client as a standard mihomo field. The core reads the final configuration; the client determines how it is generated. See the client selection guide for platform support and options, and follow the Quick Start for your first setup.

Merging Mappings and Replacing Lists

Mappings can be overridden key by key, while lists may be replaced in full, prepended, or appended; the merge tool defines the exact behavior. For example, a recursive merge of dns might replace only nameserver and preserve other subkeys. A shallow replacement could leave the DNS section with only the new content. Replacing the rules list could remove every routing rule from the subscription. The word “merge” alone does not guarantee that existing values will be preserved.

# For clients that support YAML overrides;
# Check the client’s merge rules to see whether merging is recursive.
log-level: info

profile:
  store-selected: true
  store-fake-ip: true

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query

After applying this override, check whether the existing dns.listen, enhanced-mode, filter list, and resolution policies are still present. If the result is not what you expected, change the merge strategy rather than adding more duplicate fields. Also check where rules are inserted: appending a rule after an existing MATCH usually will not route traffic as intended, while a broad rule prepended too early may catch traffic that existing exceptions should handle.

Subscription Refreshes and Protecting Local Changes

Direct edits to a downloaded subscription file may be overwritten the next time it refreshes. Keep persistent local DNS, LAN rules, and port settings in the client’s supported local configuration layer. Store manually maintained proxy and rule collections at separate paths, not in the subscription cache. If multiple HTTP providers use the same cache path, their contents can overwrite one another, making proxies disappear or causing the wrong structure to be parsed.

Converting subscription formats does not guarantee that every field will be preserved. A single-proxy URI usually cannot represent full DNS, rules, and proxy groups; converting full YAML to proxy links may discard these top-level settings. After conversion, compare the protocol, authentication, and transport first, then check whether the converter regenerated groups and rules. For private subscriptions, do not send a full link to an untrusted online conversion service. Use a trusted local tool or a format provided by the service instead.

A Reversible Update Workflow

Before updating, save the current working configuration and local extensions, and note which configuration is selected. After refreshing, run a syntax check, verify proxy group members and rule targets, then test a new connection. If the download succeeds but loading fails, check whether the response has become a webpage, error message, or different subscription format. If loading succeeds but behavior changes, compare the runtime configuration rather than only the original subscription. For timeouts, expired links, and automatic update intervals, see Troubleshooting subscription updates.

When sharing configuration differences, include only relevant fields and sanitized references. Do not upload the entire runtime configuration to explain one DNS subkey; it may also contain proxy passwords, management credentials, and remote subscription details. A reproducible minimal snippet is easier to assess than a full file with unrelated rules.

Validation, Logs, and Troubleshooting

Validate configuration from static structure through to a real connection. Do not start by changing the mode, proxy, and DNS all at once. First confirm that the core accepts the file, then confirm requests reach the right port, and finally inspect rule matches and proxy connections. Each step should rule out one layer; record the inputs, results, and changes. A full configuration can contain several working proxies without proving that the one currently selected by a group works. Likewise, a client showing “running” does not replace a real request test.

Check the File Before Loading It

If you run mihomo directly, you can use its configuration test option. Replace the directory in the command with your actual working directory; relative provider and cache paths depend on it. GUI users should prefer the client’s built-in checks, preview, or logs. Do not start a second instance that may compete for the same ports. After the configuration passes validation, check startup logs for listener failures or resource loading errors, which may not appear during static checks.

# Run from the directory containing the configuration and resources
mihomo -t -d . -f ./config.yaml

# Send a request through the local HTTP proxy listener
curl -I --proxy http://127.0.0.1:7890 https://example.com

# Use SOCKS and resolve the hostname on the proxy side
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

The two curl requests may use different DNS paths, so they are not equivalent tests. socks5h lets the proxy resolve the hostname; with regular socks5, resolution usually happens locally first. On Windows, if the terminal maps curl to another command, call the actual curl executable explicitly. An HTTP error status does not necessarily mean the proxy is unreachable. Distinguish a website rejecting the request, proxy authentication failure, and an underlying connection failure.

Narrow Down the Cause by Error Stage

The reported error line may show where the parser stopped, not where the first mistake occurred. Check that line and the one before it for a missing quote or colon. An unknown proxy name is usually a reference issue, not a reason to adjust network settings. For a timeout, identify what timed out: the subscription server, proxy server, or destination website. Check the download, proxy, and website paths separately.

Logs and Minimal Reproductions

Temporarily enable debug, reproduce a single request, and record the time, destination, matched rule, and final outbound. Then restore the normal log level. If you have TUN, the system proxy, and a manually configured app proxy as entry points, test with one clearly defined entry point at a time. Browser connection pools, background services, and DNS caches can keep old connections alive. After an important change, use a new request process or restart the test app so you do not mistake old state for the new result.

A minimal reproduction can include one verified proxy, one manually selected group, one rule for a test domain, and a final catch-all. If it works, restore DNS policies, rule providers, automatic selection, and local overrides one at a time. Do not remove every rule at once and conclude that rules are the problem; removing them can also change DNS resolution timing and the default outbound. Keep a record of each configuration difference so you can identify which change affected the result.

Common Edge Cases

After troubleshooting, remove temporary test rules, restore an appropriate log level, and confirm that LAN access was not broadened during testing. Move stable changes into the local persistent override layer, then test one more subscription refresh and reload. This verifies both the current connection and whether the configuration will still behave as expected after its next update.