Advanced Clash Configuration Guide

CHAPTER 01

Proxy Group Types and Practical Use

Proxy groups sit between rules and proxy nodes. The last argument in a rule is usually a proxy group name, not a specific node; the group then decides whether the request uses a node, an automatic test group, or a direct connection. When a rule matches but traffic exits through the wrong route, check the rule name in the log first, then open the corresponding group and verify its current selection. Editing a rule does not change a manually selected group, and switching nodes does not rewrite rules, so verify these actions separately.

The boundaries between select, url-test, fallback, and load-balance

select is a manual selection group, suited to fixed-egress use cases such as proxy selection, streaming, and downloads. It can contain individual nodes or other proxy groups. Placing an automatic test group inside a manual group lets you use automatic selection normally and switch to a specific region when needed, while keeping the hierarchy easy to understand and roll back. Do not spread dozens of nodes across every service policy; when node names change, multiple references can fail at once.

url-test periodically visits a test URL and selects the best-performing candidate node. The result reflects connectivity to that URL, not every website or large-file transfer. interval controls the test frequency; setting it too low increases background requests. tolerance suppresses frequent switches caused by small fluctuations. If the current node still works and remains within the tolerance of the best result, keeping it is usually more stable.

fallback prioritizes availability order. When an earlier candidate recovers, the group tends to return to it, making it suitable for clearly defined primary and backup exits. load-balance distributes connections across multiple nodes and suits concurrent traffic that can tolerate changing exits. Sites that depend on login state, regional consistency, or strict fraud controls are poor candidates for load balancing because separate connections may use different exits.

proxy-groups:
  - name: Proxy Selection
    type: select
    proxies:
      - Automatic Selection
      - Failover
      - DIRECT

  - name: Automatic Selection
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: Failover
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    lazy: true

Control candidate nodes with filters

When a subscription contains many nodes, use filters within automatic or regional groups instead of copying node names by hand. Kernels that support these fields can use include-all to include nodes, then filter to match names and exclude-filter to remove multipliers, test nodes, or unwanted entries. Filters operate on node names, so a provider rename can leave the candidate list empty. After each subscription update, open the group and confirm that at least one usable member remains.

Groups may reference other groups, but never create a cycle. A structure where Proxy Selection contains Automatic Selection is valid; if Automatic Selection also includes Proxy Selection as a candidate, the kernel cannot determine an exit. Group names must exactly match the final rule argument—spaces, capitalization, and full-width characters all matter. When configuration loading fails, first search for duplicate group names, then verify that every group referenced by a rule actually exists.

CHAPTER 02

Managing Rule Providers

As the rule count grows, putting everything in the main configuration creates three problems: subscription updates can overwrite local edits, rule sources cannot be updated independently, and troubleshooting becomes unclear about which set matched. rule-providers separates rules into independent collections, leaving the main configuration to define the source, storage path, update interval, and reference order. You can maintain advertising, LAN, direct-connection, and proxy-service rules separately, while the final matching order remains controlled by rules in the main configuration.

behavior determines the rule file format

Use domain for a plain domain collection; its payload usually contains domains, suffixes, or wildcard expressions. Use ipcidr for IP ranges. classical can contain complete typed rules such as DOMAIN-SUFFIX, PROCESS-NAME, and IP-CIDR. With the wrong type, a file may download successfully but still fail to parse. Inspect the source contents first instead of guessing from the filename.

type: http enables remote updates, url is the source address, path is the local cache location, and interval is the refresh period. Each provider needs a unique path, or a later download will overwrite an earlier file. When a remote update fails, the kernel usually keeps using the existing cache. On first launch, however, an unreachable source with no cache means the rule provider cannot load, so a few inline LAN rules can provide a basic startup fallback.

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

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.com/rules/service-proxy.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-proxy,Proxy Selection
  - GEOIP,CN,DIRECT
  - MATCH,Proxy Selection

The example URL only illustrates the field structure; replace it with a rule source you actually maintain in production. When the rule file uses YAML, a domain provider can be written as follows:

payload:
  - localhost
  - "*.lan"
  - "+.example.internal"

Ordering matters more than rule count

Clash checks rules from top to bottom and stops at the first match. Put specific service rules before broad regional rules, place LAN and reserved addresses before the default proxy, and keep MATCH last. If GEOIP,CN,DIRECT comes first, a later proxy rule that relies on IP matching may never run. Likewise, a broad domain suffix placed before a special subdomain rule will prevent the latter from executing.

The answer to a rule conflict is not more exceptions; first record the entry the request actually matched. Client logs and external control panels usually show the rule type, content, and target policy. Once a wrong match is confirmed, move the more specific rule earlier. Add IP rules only when the domain is unavailable, the connection exposes only an IP, or the application bypasses system resolution. Carelessly stacking domain and IP rules makes results difficult to predict.

no-resolve is for cases where IP-rule matching should not trigger an extra DNS lookup. For example, GEOIP,CN,DIRECT,no-resolve checks only when the destination IP is already available. This reduces additional queries, but if the connection provides only a domain, the rule will not resolve it before matching. Confirm whether the request is a domain or IP at the rule stage; do not treat no-resolve as a universal performance option.

Handle update failures and unmatched rules separately

A provider download failure is a source-layer problem: test the address over a direct connection, then check the URL, response format, and cache-directory permissions. A successful download with no match is a reference-layer problem: verify that rules contains the relevant RULE-SET, the proxy group name is correct, and no earlier rule matches first. A parse failure is a format-layer problem: focus on behavior, format, YAML indentation, and payload nesting.

After updating rules, reload the configuration once and test with a fixed domain. Do not validate with several sites at once; background browser requests, QUIC, and cached connections can muddy the logs. Choose one target, clear the connection history, make one request, and confirm that the domain, matched rule, and final policy agree. Use the Glossary to verify rule concepts. If every node times out, switch to the node timeout troubleshooting order instead of repeatedly editing rule providers.

CHAPTER 03

Optimizing DNS Configuration

DNS issues are often mistaken for node failures. When a browser reports a connection error, the domain may not have resolved, a bad result may be cached, the query may have bypassed Clash, or the rule stage may lack the original domain. First distinguish who handles the DNS query from how the result is used for the connection. System DNS, the client’s built-in DNS, encrypted browser DNS, and application-level resolution can coexist; configuration only makes sense once the query path is known.

Understand nameserver, default-nameserver, and fallback first

nameserver defines the primary upstream resolvers and can use ordinary UDP/TCP DNS, DoH, or DoT. default-nameserver is mainly used to resolve the hostnames of encrypted DNS upstreams. It should usually contain directly reachable IP addresses, avoiding the loop where resolving a DoH hostname depends on connecting to DoH first. It is not the default route for every business query and should not be filled with a long list of addresses.

fallback and filtering settings select between different resolution results. This mechanism is complex; without a clear need for pollution handling or split resolution, start with stable nameservers, confirm basic resolution, and add fallback later. More upstreams do not necessarily mean faster DNS. Parallel queries can make logs harder to read and produce cache differences between results. Prefer two or three upstreams with clearly defined roles.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
    - time.*.com
    - time.*.gov

proxy-server-nameserver resolves the hostnames of proxy servers themselves. If a node address is a hostname, its IP must be resolved before the proxy connection can be established. If this lookup incorrectly depends on a proxy that is not yet connected, startup deadlock results: the proxy must connect first, but the connection must first be resolved through the proxy. Resolve node hostnames through a directly reachable upstream to separate node DNS from business DNS.

Choosing between Fake-IP and redir-host

fake-ip does not immediately resolve a domain to its real destination IP. Instead, it returns a mapped address from a reserved pool. When the application connects to that address, the kernel restores the domain from the mapping table and applies domain rules. This usually preserves more complete domain information and prevents real DNS results from being exposed to the application too early. The tradeoff is compatibility: some LAN discovery, casting, time synchronization, games, and applications that validate real IPs may fail and need exclusions through fake-ip-filter.

redir-host returns the real resolution result and follows a more traditional proxy path, but the rule stage may rely more heavily on DNS results and sniffing. Do not choose a mode based only on whether a webpage opens. Also test LAN devices, system time, common messaging apps, and region-sensitive services. If only one domain category fails, add that domain to the filter list before switching the entire setup back to redir-host.

Judge IPv6 together with the local network

ipv6: false suppresses AAAA results and suits networks with incomplete IPv6 support, IPv6-incompatible nodes, or frequent failures where IPv6 is tried first. If both the local network and exit support stable IPv6, enable it and test A records, AAAA records, and the actual exit separately. Disabling IPv6 at the system level while letting Clash return AAAA records can still make applications try unreachable addresses first; conversely, a network with IPv6 cannot use it when DNS blocks AAAA responses.

A single test website cannot prove that DNS is leak-free. First check whether system DNS points to the client’s listening address, then see whether the browser has independent Secure DNS enabled, and finally verify in the query log that requests enter the kernel. Browser DoH may bypass system DNS while proxy traffic still flows through the proxy; that means the query path differs, not that all traffic is direct. For unified control, disable independent browser resolution or route its upstream correctly through the rules.

Locate DNS failures by symptom

If a domain fails but its IP works, check the upstream resolver and listening port first. If the first load is slow but refresh works, inspect upstream connectivity, caches, and IPv6 timeouts. If some LAN devices cannot be found, check the Fake-IP filter. If logs show only IPs and domain rules do not match, check whether the application bypasses DNS, whether sniffing is enabled, and whether transparent proxying captures the connection. After changes, clear system and browser DNS caches and restart the target application to avoid interference from old connections.

CHAPTER 04

TUN and Fake-IP

The system proxy affects only applications that actively read proxy settings. Command-line tools, some games, virtual machines, and software with its own network stack may ignore it entirely. TUN creates a virtual network interface and routes more TCP and UDP traffic through the kernel, making it suitable for transparent capture. TUN solves the traffic-ingress problem; Fake-IP solves domain mapping. They are often used together, but they are not the same switch.

Rule out routing conflicts before configuring TUN

Starting TUN requires creating a virtual interface, installing routes, and taking over DNS, which usually requires system authorization. If the client says TUN is enabled but the target application still connects directly, first check that the virtual interface exists, then verify the default and excluded routes. VPNs, virtual machines, containers, game accelerators, and other proxy tools may all modify routing. During troubleshooting, exit similar tools and leave only one traffic-capture program active.

auto-route lets the kernel configure routes automatically and suits ordinary desktop use. auto-detect-interface identifies the actual outbound network interface, preventing proxy traffic from re-entering TUN and creating a loop. After switching from wired to wireless or from a home network to a hotspot, stale interface data may fail. If everything times out after changing networks, restart TUN or the client to trigger interface detection instead of immediately changing nodes.

tun:
  enable: true
  stack: mixed
  device: Mihomo
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true
  mtu: 1500

stack determines how TUN data enters the user-space network stack. mixed is generally suitable for desktop environments that need both TCP and UDP. If a specific system has compatibility problems, compare other supported stacks while changing only this setting. strict-route enforces the traffic path more tightly and can reduce bypasses, but may affect LANs, virtual adapters, and multi-homed systems. Test the gateway, LAN devices, and common services immediately after enabling it.

Match DNS hijacking to the listener configuration

dns-hijack sends ordinary port 53 queries passing through TUN to the built-in DNS service. It cannot directly decrypt application-generated DoH, nor can it capture queries that never pass through TUN. If hijacking is configured while dns.enable is disabled, or if the listening address conflicts, every domain may appear broken. Do not change rules first; confirm that the DNS module is running and that its port is not occupied by another service.

Fake-IP pools normally use a dedicated reserved range. Once an application sees such an address, its connection must continue through the same kernel so the domain can be restored from the mapping table. If Clash returns a Fake-IP but the subsequent connection bypasses TUN or the system proxy, the application tries to reach an unroutable reserved address directly, producing the “resolves but will not connect” symptom. Check that the traffic ingress is consistent instead of changing DNS upstreams.

MTU and UDP are common boundary cases

When webpages load but large files, images, or some TLS connections stall, consider MTU. Virtual-interface encapsulation adds overhead, while the underlying network may have a smaller effective MTU. Check whether the issue occurs only on a particular network, then lower the TUN MTU gradually. Do not reduce it drastically in one step. Values that are too low increase fragmentation and processing overhead; values that are too high may encounter a path black hole.

Games, voice calls, and QUIC depend on UDP. TUN capturing UDP does not mean that the node protocol and exit support it. Check in order: whether UDP connections appear in the log, whether the rule selects the intended policy, whether the chosen node supports UDP, and whether the system firewall allows the virtual interface. If browser pages behave strangely, temporarily disable QUIC to compare the TCP path. Use this only for diagnosis, not as an automatic long-term fix.

Platform-specific priorities

On Windows, focus on driver authorization, system services, and other VPN virtual adapters. On macOS, check network-extension authorization and the order of system network services. On Linux, check TUN-device permissions, policy routing, forwarding, and firewall rules. Clash clients on Android and iOS usually capture traffic through the system VPN interface, which generally permits only one primary VPN session; enabling another VPN may replace the current connection. To choose a compatible client, visit the download center for platform listings; Clash Plus is the recommended option across platforms.

CHAPTER 05

Domain Sniffing

When an application connects directly to an IP, uses a cached result, or sends DNS queries outside Clash, the rule stage may see only the destination IP. Domain sniffing extracts a hostname from the initial connection data, such as SNI in a TLS handshake or Host in an HTTP request, and passes it to the rule system. It supplements routing information; it does not decrypt all content or guarantee domain recovery for every protocol.

When should sniffing be enabled?

Sniffing helps when logs show only IPs over time and DOMAIN, DOMAIN-SUFFIX, or domain rule providers never match. With Fake-IP, the kernel usually already knows the domain, so sniffing is less necessary, though it may still help connections that bypass built-in DNS. Do not enable every port just to get broader coverage. Identify the protocol and port used by the failing connection, then choose a capture scope.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud
    - "+.push.apple.com"

parse-pure-ip allows connections targeting a bare IP to attempt domain extraction; force-dns-mapping uses existing DNS mappings; override-destination decides whether the sniffed domain replaces the original destination. Overriding can enable domain rules, but may affect applications that use fixed IPs, certificate validation, or private protocols. Enable overrides for specific protocols first instead of applying them globally.

HTTP sniffing relies on plaintext request headers, while TLS sniffing reads the SNI visible during the handshake. QUIC depends on the protocol implementation and encrypted handshake. Mechanisms such as ECH may hide the traditional SNI, leaving sniffing with no domain to extract. This is not necessarily a configuration error; the connection may simply contain no plaintext identifier. In that case, route DNS queries through the kernel or supplement routing with explicit IP, process, and rule-provider policies.

Use skip-domain for compatibility issues

LAN discovery, push services, system connectivity checks, and some games may not work well when the destination is rewritten. If an app works with sniffing disabled but fails when it is enabled, confirm the sniffed domain in the log and add that specific domain to skip-domain. Keep exclusions narrow; a broad top-level suffix can deprive many normal connections of domain-based routing.

Some clients place sniffing options in graphical override settings that remain unchanged during subscription updates; others read them directly from the configuration file. Before troubleshooting, confirm the final active configuration rather than relying on the subscription source. If the client offers a “running configuration” or “current configuration” view, use that as the source of truth. A local override may already have changed sniffer, making manual edits to the subscription file ineffective.

Verify that sniffing actually affects routing

Choose a destination that appears only as an IP in the logs, clear existing connections, and make a new request. Record the original destination, sniffed domain, matched rule, and final policy in order. Seeing a domain does not prove that routing used it; confirm that the match changed from an IP rule to the expected domain rule. If the domain is correct but the default rule still matches, check rule order and suffix syntax. If the sniffed domain is wrong, disable destination overriding first, then exclude that domain or application.

Process rules can supplement desktop routing, but process-detection support and permissions vary by operating system. Process names may also change with launchers, child processes, or sandboxes, so do not bind every service to a process. Stable routing usually relies on domain rules, with IP and process rules covering the few connections where no domain is available.

CHAPTER 06

Local Overrides and Subscription Merging

Remote subscriptions are useful for supplying nodes and baseline policies, but they are poor places for long-term manual edits. Clients usually regenerate configuration during subscription updates, which can overwrite DNS, rules, and proxy groups written directly into the subscription file. The purpose of local overrides is to separate content maintained upstream from content that must persist on this device. Before editing, confirm whether the client supports field overrides, script processing, configuration-fragment merging, or full configuration management; similar names can conceal different merge orders.

Determine the final configuration generation order first

A common flow is to read the remote subscription, parse its nodes and proxy groups, apply local scripts or fragments, and write the running configuration. Some clients prepend local rules to subscription rules, while others append them; some override same-named keys, while others concatenate arrays. Without knowing the order, a new rule may land after MATCH and never match. A same-named proxy group may also be replaced wholesale instead of receiving one additional node.

The most reliable check compares three artifacts: the raw remote subscription, the local override, and the client’s final running configuration. A fragment shown in an editor does not prove that it is active. After each change, search for the target field and confirm that it appears only once in the final configuration, at the correct level, with valid references. Pay close attention to the difference between YAML arrays and objects: rules and proxies are ordered lists, while dns and tun are usually key-value objects. A wrong merge strategy changes the meaning directly.

prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - PROCESS-NAME,backup-client,DIRECT

append-proxies:
  - name: Local Exit
    type: socks5
    server: 127.0.0.1
    port: 1081

override:
  ipv6: false
  log-level: info

The example expresses a common override goal, but fragment field names differ between clients, so follow the client’s own documentation. Standard Clash configuration has no top-level prepend-rules field; do not copy override-tool syntax directly into config.yaml. When troubleshooting a configuration error, first distinguish kernel-native fields from client merger fields.

Resolve naming conflicts before merging subscriptions

Two subscriptions may both contain groups such as Automatic Selection and Proxy Selection, or nodes with the same name. Direct concatenation can create duplicate names, broken references, or later entries overwriting earlier ones. Before merging, add a stable source prefix, such as a short purpose label for work or backup, then build your own higher-level groups. Top-level rules should reference your groups rather than upstream groups that may be renamed at any time, so updating one subscription does not disrupt all routing.

Node names serve as both reference keys and filter criteria. When identically named nodes come from different subscriptions, they are difficult to distinguish in a group even if the servers differ. Rename them before adding them to groups, keeping region, purpose, and source information short and clear. Do not include dynamic text such as subscription expiry or remaining traffic in long-term filters; when the provider updates that text, the regular expression may match unexpectedly.

proxy-groups:
  - name: Main Exit
    type: select
    proxies:
      - Automatic Main Subscription
      - Automatic Backup Subscription
      - DIRECT

  - name: Automatic Main Subscription
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: Automatic Backup Subscription
    type: fallback
    use:
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

The smaller the override, the lower the update cost

Long-term overrides should contain only what this device actually needs: LAN direct rules, DNS choices, TUN parameters, custom proxy groups, and a few service exceptions. Do not copy and edit the entire upstream configuration, or subscription updates will no longer deliver node changes cleanly. If a full local configuration is necessary, use the subscription only as a node provider and let the local file own all policies and rules.

When merging fails, check three layers. At the syntax layer, inspect YAML indentation, list markers, and duplicate keys. At the reference layer, verify that proxy groups, providers, and rule names exist. At the runtime layer, confirm that the client actually selected the generated configuration. A configuration that loads but has no nodes usually indicates a provider or filter issue; a configuration that will not load calls for checking duplicate names and unknown fields; local settings disappearing after an update points to the wrong override order or save location.

Creating a rollback point matters more than adding automation. Keep a verified working base configuration, document the purpose of each local fragment, and run a reload test after every change. When updating the client or moving to another device, load the base configuration first to confirm that the kernel and network work, then restore overrides one by one. Choose clients for different platforms in the download center; for the initial migration, follow the Getting Started guide.

CHAPTER 07

External Control Panels

The external control API reads connection, log, rule, and proxy-group status and can also switch policies, close connections, or reload configuration. It is a troubleshooting tool, not a traffic-forwarding entry point. A control panel only calls the API exposed by the kernel; the page does not replace the kernel or repair configuration automatically. If the interface shows offline, verify the control address and authentication first, then confirm that the kernel process is running.

The listening address determines exposure

external-controller specifies the control API’s listening address. For local-only use, bind it to 127.0.0.1 whenever possible. Binding to 0.0.0.0 may expose the port to other devices on the same network and must be paired with access controls and a firewall. Do not broaden the listening scope just to make a browser panel connect. First confirm that the panel and kernel run on the same device; on one device, a loopback address is simplest.

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
external-ui: ./ui
external-ui-name: dashboard
external-ui-url: https://example.com/dashboard.zip

secret authenticates the control API, and the panel must provide the same value. Changing it immediately cuts off existing panels, which is expected. Authentication failures usually mean the API is reachable but policies or connections cannot be read. Never place the control secret in a public page, screenshot, or shared configuration. When sharing diagnostic data, remove the control address, authentication fields, subscription URLs, and node credentials.

external-ui points to a local static panel directory, while external-ui-url can fetch panel files. The kernel API and panel files are separate: if the API works but the page is blank, the UI path may be wrong; if the page opens but shows no data, check the control address, CORS settings, or authentication. Test the two parts separately to identify the failing layer.

Cross-device access needs additional restrictions

If you must access the panel from another device on the LAN, bind the listener to a LAN-reachable interface and configure the system firewall to allow only trusted subnets. Router port forwarding and public listening greatly increase risk and should not be used for routine remote management. A safer approach is a controlled private network or local tunnel to the loopback interface, with authentication left enabled.

Browser panels connect to the control API over HTTP or WebSocket. If the panel uses HTTPS while the API uses plain HTTP, the browser may block mixed content. Let the panel and API share the same controlled entry point instead of disabling browser security. If WebSocket connections repeatedly drop, check that a reverse proxy forwards upgrade headers correctly, that system sleep has not paused the kernel, and that the firewall is not reclaiming idle connections.

Use the panel to inspect requests layer by layer

For each connection, check at least four items: destination domain or IP, matched rule, policy chain, and final node. If the domain is missing, return to DNS and sniffing. If the rule is wrong, check rule order. If the policy chain is correct but the final node fails, inspect the group’s current selection. If everything looks right but the connection still fails, check the node handshake, UDP support, and local network. This order prevents replacing the entire configuration just because a request timed out.

The rules page can usually confirm whether a provider loaded and whether rules are present, but count is not a measure of quality. Connection logs matter more: choose one fixed target, close old connections, make one request, and follow the complete path from domain to exit. The info log level is sufficient for routine diagnosis. Switch temporarily to debug only when handshake or rule details are needed, then restore it so excessive output does not hide important events.

After a panel switches policies, existing long-lived connections may not move to the new node immediately. To verify the exit, close the relevant old connection, restart the target application if necessary, and make a new request. Browser tabs, downloads, and messaging apps maintain connection pools, so a changed group selection does not prove that the current request uses the new exit.

Keep a repeatable end-to-end troubleshooting path

After multiple configuration changes, export the current running configuration and recent logs first. Then disable TUN and keep only the system proxy to confirm that the basic node connects. Enable DNS and check resolution for a fixed domain; restore rule providers and confirm the match; finally enable Fake-IP, sniffing, and TUN in sequence. Use the same test target at every layer. If failure begins at one step, it is in that restored layer or at its boundary with the previous one.

If only a few nodes time out, follow the node timeout troubleshooting order. If overall speed drops, use layered slow-speed diagnosis to separate node, route, and local-setting issues. When the configuration file fails to load, return to syntax and references instead of applying node-switching steps from a connectivity guide to a parsing error.