Clash Configuration Guide

Modes and configuration baseline

Start advanced configuration with a connection path you have already tested. Keep the working subscription, one manually selected proxy, and your current system proxy settings. Note the client name, core type, mixed port, and active profile. Avoid changing the subscription, enabling TUN, and modifying DNS all at once. When several things change together, a page loading only confirms the final result; it does not reveal which layer caused the change.

Separate configuration sources from runtime behavior

Clients typically combine a subscription file, local settings, and overrides before passing the result to the core. A port shown in a subscription editor does not necessarily match the port the core actually listens on. Check the client's effective configuration, core configuration preview, or startup logs. If a saved change has no effect, confirm that you edited the active profile and that it was reloaded before adding the same field again.

Named references in the configuration are runtime dependencies too. Every policy named at the end of a rule must exist as a proxy or proxy group, and every provider referenced by a group must be defined. Valid YAML syntax only confirms that the file parses; it does not confirm that these objects exist. Use spaces, not tabs, for indentation. Quote names containing commas, colons, or special characters, and check every reference after renaming an item.

When to use rule, global, and direct modes

mode: rule selects an outbound based on the rules, checked from top to bottom. Global mode generally sends connections that need proxy routing to the global policy. Direct mode bypasses the proxy. Changing modes will not fix a broken proxy, DNS lookup, or route, nor does it automatically capture traffic from every app. Whether traffic from apps outside the system proxy reaches the core still depends on app settings, TUN, or gateway forwarding.

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

This baseline sets the mixed proxy port to 7890, disables LAN access, and keeps informational logging. The mixed port accepts both HTTP and SOCKS proxy requests, but each app still needs to use the correct proxy protocol. If the port is already in use, stop the other listening process or update both the client and app settings. Changing only the number in the app sends traffic to a listener that does not exist.

Make testing repeatable

Change one setting at a time, then open a new connection from the same app. Existing long-lived connections may keep using the old policy, so close the connection or restart the test app. First check the connections panel to see whether the request reached the core, then inspect the matched rule and actual outbound. No connection entry? Check traffic capture. An entry with the wrong policy? Check the rules and proxy groups.

If global mode works but rule mode fails, the two modes may be choosing different outbounds, or rule mode may be sending the destination down an unsuitable direct route. Compare the actual outbound before drawing conclusions. Direct access to one site does not prove the whole subscription is broken; the destination, DNS result, and server behavior can all differ. Compare results for the same destination to avoid treating a local symptom as a general failure.

To distinguish client UI behavior from core behavior, start with the configuration structure and traffic capture concepts in Glossary. When switching clients, choose Clash Plus from the Download Center first, then compare other clients by platform and core features. The controls may appear in different places, but the verification sequence stays the same: load configuration, confirm the request reaches the core, check the matched rule, and inspect the outbound connection.

Proxy group types and practical setups

Proxy groups separate rules from individual proxies. Rules can keep referring to a stable name such as “Business Egress” while the proxies in the group change with subscription updates. Start by deciding what you need: manual selection, a preferred route with a backup, automatic selection of a responsive candidate, or distributing separate connections across multiple outbounds. Avoid stacking every group type in one configuration; the more layers you add, the longer the reference chain to trace.

Manual selection and automatic selection

select is best when you want to choose an outbound manually; the result is easy to understand. url-test automatically picks a candidate based on probe results. fallback uses the first available item in list order, making it suitable for primary and backup routes. load-balance distributes connections according to its strategy; it does not combine bandwidth for a single download. For logins, payments, and session-based services that depend on a stable egress IP, avoid frequent automatic switching.

This snippet assumes the current configuration defines two proxies named “Route A” and “Route B.” Replace these with the exact names used in your subscription. The top-level manual group can select an automatic group or a proxy directly. Have rules refer only to the top-level group so you can change the candidate list without editing each rule.

proxy-groups:
  - name: Auto Egress
    type: url-test
    proxies:
      - Route A
      - Route B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Business Egress
    type: select
    proxies:
      - Auto Egress
      - Route A
      - Route B

rules:
  - DOMAIN-SUFFIX,example.com,Business Egress
  - MATCH,Business Egress

Understand probe settings

interval sets the probe interval in seconds. tolerance is the switching threshold, which helps prevent small differences between candidates from triggering frequent changes. Choose a probe URL that is reliably reachable through the candidate routes. A probe measures requests from a particular route to a specific test service; it does not tell you how fast every site will load, how well video will stream, whether packets are being lost, or whether a particular service is available.

Health checks generate background requests, especially when several groups share candidates and use short intervals. Start with a moderate interval and adjust it to how often routes change. With lazy behavior for latency tests enabled, an unused group may not produce fresh results right away. Interpret old values in the panel alongside the time of the last probe; they are not a continuously updated live monitor.

Nesting, subscription references, and service tiers

When proxies come from proxy-providers, groups can use use to reference a provider instead of listing every proxy name. The candidate set can then change as the subscription adds or removes proxies. Name filters can narrow the candidates, but region labels usually reflect the provider's naming conventions, not verified egress locations. A bad filter can leave a group empty, so check the expanded candidate list.

A reliable structure is usually one top-level manual group plus a few groups organized by purpose. Business rules point to purpose-specific groups, which in turn reference automatic groups or fixed proxies. Avoid circular references, such as Group A pointing to Group B while Group B points back to Group A; they can prevent the configuration from loading. An automatic group must not include a selection chain that leads back to itself either. Even if the UI displays the names, the final outbound may not resolve.

If an automatic group switches too often, first check whether its candidates are stable and whether the test service is rate-limiting requests. Then increase the tolerance or switch to a primary-and-backup group. If only one service is affected, retest with the same fixed proxy so the outbound does not change during testing. Existing connections may keep their original outbound after a group selection changes; check a new connection rather than relying on the group button's displayed name.

Proxy quality also depends on data caps, region, and protocol, not just one probe result. Use the guide to proxy selection and latency to build a candidate set. The goal of advanced configuration is not to send every kind of traffic through the same automatic route, but to make each rule's choice clear and provide a manual fallback when something fails.

Manage rule sets with providers

The rule list determines match order; rule sets manage collections of matching conditions. Moving frequently changing domains or addresses into rule-providers keeps the main configuration concise, but rule sets do not have a separate priority system. The core still checks rules from top to bottom, and the first match determines the outbound. A broad set placed too early can shadow more specific rules later in the list.

Choose the behavior first, then the file format

behavior: domain is for domain lists, ipcidr for address ranges, and classical can contain multiple complete rule conditions. Behavior and file format are separate settings: format describes how the file is encoded, while behavior describes how its contents are interpreted. A YAML file extension does not mean you can put complete DOMAIN-SUFFIX entries into a set that accepts only domain entries.

This example uses a local classical rule set so you can verify the structure first. Save the second snippet as rules/work.yaml in the core's working directory, and merge the first snippet into the current configuration. The example assumes a proxy group named “Business Egress” already exists. File-based provider changes generally require a reload. If the client copies files to another working directory, check which path it actually reads.

rule-providers:
  work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,work,Business Egress
  - GEOIP,CN,DIRECT
  - MATCH,Business Egress

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

Order exceptions, regular matches, and the fallback

A useful starting order is a small number of exceptions that must override other conditions, followed by business domain sets, any required address rules, and finally MATCH. GEOIP,CN,DIRECT is a common structural example, not a recommendation to send every destination directly based on location. Geolocation data, cross-region services, and shared infrastructure can all affect the result; adjust it to your actual needs.

Domain rules usually do not need to resolve an address just to match. Address rules may trigger a lookup. Adding no-resolve to supported address rules prevents a lookup solely for matching, but it can also stop the rule from matching requests that have a domain but no destination address. This is not a general-purpose performance switch; it is a deliberate trade-off between matching accuracy and DNS behavior.

Treat remote updates as a configuration dependency

For an HTTP provider, specify an accessible rule URL, a cache path, and an update interval. The interval is in seconds; do not use the minutes or hours shown in a client subscription UI. Give each provider a unique cache path to avoid two providers sharing the same file. If there is no cache on first startup, the route needed to download the rules must already work. Otherwise, the configuration can end up waiting for a dependency that depends on the configuration itself.

Troubleshoot remote update failures separately from rule matching failures. First check whether the provider loaded and its entries are present, then see whether a request matches the set. A cached file may let the core continue running, but that does not mean an update succeeded. Conversely, a successful download does not prove the contents match the specified behavior. Handle parse errors, empty sets, and download failures separately; do not attribute them all to an unavailable proxy.

When maintaining rule sets, record their source and purpose, and keep a fallback file with the last known good content. After adding a set, test one domain that should match and another that should not, then check whether other traffic changed. If matches are unexpected, temporarily move the related rule earlier to test for shadowing. Once you find the cause, restore the intended order instead of relying on an ever-growing list of exceptions.

Optimize DNS resolution paths

DNS configuration is about designing the resolution path before choosing servers. Consider separately which DNS server an app queries, which server the core queries, and how the core resolves proxy server hostnames. Browsers may use their own encrypted DNS, operating systems may cache old answers, and routers may forward queries. Changing only nameserver does not guarantee that every app's queries pass through the core or that proxy hostnames use the same resolution path.

Separate bootstrap resolution from regular DNS

default-nameserver provides bootstrap resolution for DNS upstream hostnames; choose an address directly reachable on the current network. nameserver handles regular queries, while proxy-server-nameserver resolves proxy hostnames. Mixing up these roles can create a dependency loop: the proxy must be connected before its own hostname can be resolved. This can leave the core unable to establish any outbound connection after startup.

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
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "*.local"

This example assumes the listed DNS services are reachable from your current network. It does not automatically change the system DNS to port 1053 or enable TUN interception. Most systems do not allow a custom port in their standard DNS settings, so test the listener separately from traffic capture. Use a query tool that supports a custom port to test the core, then check whether system requests are actually redirected to it.

Choose DNS upstreams by domain

nameserver-policy can route specific domains to specified upstreams, which is useful for internal domains, dedicated DNS environments, or services with distinct requirements. It selects a resolver; it does not determine the outbound for the final connection. “Use this DNS server for this domain” does not mean “always proxy this domain.” Connections still go through rule matching, and DNS requests may also be affected by their own routing settings.

When using respect-rules for DNS requests, check proxy hostname resolution and the bootstrap path carefully. Once DNS queries are subject to rules, an incorrect fallback policy can make them depend on a proxy that is not yet connected. First identify which queries must work directly, then add routing constraints. Seeing an encrypted DNS address alone does not prove that queries are taking the expected route.

Cache, IPv6, and comparing results

After changing DNS, consider app, system, and core caches separately. Reopening a page may reuse an existing connection, so it is not proof of a fresh lookup. Close the relevant connections, clear the appropriate cache, and check query and connection logs. Do not clear everything immediately. Keep a before-and-after result and compare returned addresses, response types, and actual outbounds to pinpoint the layer causing the problem.

Top-level ipv6 and DNS-level ipv6 have different scopes: the former affects IPv6 use by the core, while the latter controls IPv6 results in DNS responses. If the network has no working IPv6 route but apps receive IPv6 addresses they prefer, connections may stall before falling back. Disabling IPv6 outright is not a universal fix either; first check the device routes and service requirements.

If resolution works but connections fail, do not keep swapping DNS servers blindly. Check whether the selected outbound can reach the destination, whether a rule matched incorrectly, and whether certificates and system time are valid. If resolution fails while proxies remain reachable, focus on the query path and upstream availability. Treat “resolved to an address” and “the app completed its request” as separate checks to avoid repeated guesswork at the DNS layer.

Combining TUN and Fake IP

TUN is a way to route traffic into the core; Fake IP is a DNS mode that preserves domain associations. They are often used together, but they are not the same feature. TUN creates a virtual network interface and captures packets through routing. Fake IP returns a reserved address to the app, then lets the core map that address back to the original domain. Fake IP alone does not capture app traffic, and TUN alone does not guarantee the core knows which domain belongs to each connection.

Start with a limited traffic capture scope

Desktop clients often need service mode, administrator privileges, or approval for a system network extension to enable TUN. The details vary by platform. Keep your existing DNS and rule baseline, confirm that the client creates the interface successfully, and only then enable automatic routing. Other VPNs, virtual machine networks, and security software may also install routes or filters. If several are active, record changes to the default route so you do not mistake a conflict for a configuration syntax error.

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

This example intercepts standard UDP and TCP DNS traffic; it does not transparently capture every encrypted DNS request. A browser's own DNS-over-HTTPS request still looks like a regular HTTPS connection, so redirecting DNS ports cannot recover its query. For testing, first have the app use the system resolver and confirm domain resolution works, then decide whether to keep the app's own encrypted DNS enabled.

Choose a stack and interface strategy

system, gvisor, and mixed use different network stack implementations. Support depends on the platform and core build. Do not assume one stack is always best. If a particular protocol fails, change one option at a time while leaving other settings alone, and check logs for an explicit unsupported-option message. A saved setting does not prove the core is using it.

Automatic outbound interface detection works well on typical single-uplink devices, but multi-NIC systems, hotspot sharing, containers, and routers may need an explicit interface and routing plan. Interface names can change after system updates, reconnects, or device changes. If traffic keeps returning to the virtual interface, connection counts grow unexpectedly, or the whole network goes down, disable TUN first to restore connectivity. Then check for a routing loop instead of repeatedly retrying the destination.

Maintain Fake IP mappings and exceptions

After an app receives a Fake IP, its connection must pass through the same core that holds the mapping. If Device A answers the DNS query but Device B handles the connection, B may not know which domain the reserved address represents. This matters especially when sharing a proxy on a LAN: make sure DNS and connections are handled by the same device. Do not expose Fake IP results to devices or network paths that do not use that proxy.

fake-ip-filter keeps specified domains from receiving Fake IP addresses, but filtered domains still need a working upstream for real DNS resolution. For apps that need real addresses, start with the specific domains causing problems rather than filtering broad public suffixes. A large filter list reduces the core's ability to recover domains from mappings and pushes more decisions back to address rules or sniffing.

If an app has cached an old Fake IP and the core restarts with its mapping lost, new connections may not recover the domain. After understanding how the mapping is stored, use profile.store-fake-ip to preserve it and check that the client keeps the corresponding data directory. During troubleshooting, clearing the app cache and resolving the name again is usually more targeted than expanding the filter list. Also avoid reusing these reserved addresses on networks that do not use this core.

Test a regular website, an app that ignores the system proxy, and access to a LAN service. For each, check whether the traffic reaches the core, whether a domain is shown, and whether the expected rule matches. If the system proxy works but TUN does not, narrow the issue to routing, permissions, DNS interception, or the network stack. For a detailed comparison, see TUN mode vs. system proxy: how they work. You do not need to enable every traffic capture feature at once.

Domain sniffing and matching limits

When a connection exposes only a destination IP and no reliable domain information, domain rules may not work as expected. Domain sniffing tries to extract a hostname from parts of a protocol handshake or request to provide another clue for rule matching. It does not decrypt HTTPS traffic and cannot identify every connection. Get DNS capture and Fake IP mapping working first. Sniffing is usually easier to maintain as a fallback for edge cases than as your only source of domain information.

Limit sniffing by protocol and port

HTTP can expose a domain in the request's host information; TLS may reveal a server name in visible handshake data, and QUIC detection depends on core support and the specific traffic. Sniffing may not find a domain when an app uses a custom protocol, connects directly to an IP, reuses an existing connection, or hides relevant handshake information. No result does not mean the core is broken; first check whether the traffic contains information that can be identified.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

This snippet limits sniffing to common service ports and preserves the original destination address. parse-pure-ip allows attempts to identify connections that have only an IP address. force-dns-mapping affects sniffing behavior for DNS mapping scenarios. The options have similar names but do not replace a working DNS setup. If the core reports an unsupported field, check the actual core version rather than relying on the client name.

Distinguish adding a domain from overriding the destination

override-destination determines whether sniffed results can change the connection destination. Changing the destination may help in cases where a connection needs to be established again by domain, but it can also break the address selected by the app. For services using dedicated IPs, internal hosts, CDN routing, or certificate-bound addresses, leave it disabled initially. Observe domain detection and rule results first, then decide whether to enable overrides.

One IP can host multiple domains, and one domain can resolve to several addresses. Resolving again after sniffing may return a different address from the one the app originally used. So “the right domain was identified” and “the connection reached the right service” are separate checks. If enabling overrides breaks just one app, compare results with overrides disabled, then consider a skip policy for the affected domain.

Handle exceptions and privacy carefully

For domains that should not be sniffed, use exclusions such as skip-domain if the core supports them. Add exceptions for a known compatibility issue and record the reason; avoid copying large exclusion lists from unknown sources. If the exclusions are too broad, sniffing may effectively stop working while troubleshooters assume it is still active, leading to patches being added at the rule layer instead.

Sniffing cannot reliably get around mechanisms such as encrypted client hellos, and it cannot replace app logs. A detected domain may be the hostname used at the connection layer, not the page title or the full service the user is accessing. This is especially common on shared infrastructure. Base rules on stable, verifiable hostnames; do not route an entire infrastructure through one outbound based on a single sniffed domain.

For testing, fix one destination, close existing connections, and send a new request. Compare the destination domain, rule name, and outbound with sniffing off and on. If the request already matched a specific address rule before sniffing, also check rule order and core behavior. Do not change the port range, destination override, and routing set in a single test, or you will not know which setting caused the difference.

Logs may include domains, destination addresses, and app details. If you temporarily increase the log level, capture only what you need to identify the issue and remove subscription URLs, credentials, and personal browsing records before sharing. Restore the usual log level once the issue is resolved, keeping the smallest effective configuration. Sniffing should be an explainable aid, not a way to hide unresolved problems with DNS, traffic capture, or rule references.

Local overrides and merging multiple subscriptions

Subscription updates often replace the contents of a remote profile, so edits made directly to the downloaded file may disappear on the next update. Local overrides preserve long-term device or user settings, such as listening ports, DNS policies, a few business rules, and the control interface. The entry may be called override, merge, extension, or script, but the names do not guarantee the same behavior. First find out whether the client replaces fields, deep-merges objects, or concatenates arrays.

Define ownership for three configuration layers

Remote subscriptions provide proxies and their related structure. Local device settings manage permissions, listeners, and traffic capture. User policies define routing and long-term exceptions. Avoid maintaining the same field in all three layers. For example, if the UI fixes one port, an override sets another, and the subscription specifies a third, the outcome depends on an implicit load order that may change when you move to another client.

Test merge behavior with a low-impact, easy-to-check field such as log-level. After loading, inspect the effective configuration, then test how rule arrays are handled. If the new rules replace the entire rules list, that entry is not an append mechanism. Use a client feature that explicitly supports prepending, appending, or editing rules instead of assuming every YAML merge preserves the original array.

# Merge snippet: confirm how the client handles objects and arrays before use
log-level: info

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

Merge proxy sources instead of concatenating full files

Two complete subscriptions may both include ports, DNS, proxy groups, and fallback rules. Concatenating the files can create duplicate keys or conflicting values. A more reliable approach is to use one main configuration for rules and group structure, with multiple proxy-providers supplying proxies. This requires each source to use a proxy provider format the core accepts; a complete client configuration does not become a proxy list just by changing its filename.

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: Multi-Source Egress
    type: select
    use:
      - source-a
      - source-b

Each local file should contain a proxies list with valid protocol fields. This example shows only how the providers are referenced; it does not include proxy credentials. Use recognizable proxy names so you can tell sources apart. If you need to rename them or add source prefixes, confirm that the client or conversion process explicitly supports it. Avoid manual edits to generated files that cannot be repeated after an update.

Update intervals, conversion, and fallback

A client's profile update interval and the core's provider update interval are separate tasks and may use different units. The former fetches the main configuration; the latter updates a proxy or rule source. Record what triggers each update, where its cache lives, and whether the previous file remains in use after a failure. Device sleep, mobile data restrictions, and background task policies can all delay updates, so the interval alone does not tell you when an update actually runs.

Subscription URLs often contain access credentials. Do not include the full URL in public screenshots, logs, or example repositories. Before converting a subscription, check whether the process sends the original URL to a third-party service. Prefer trusted client features or local conversion, and check whether proxy options were lost. Loading successfully is only the first step; simplifying protocol fields can still change how connections behave.

Before a merge, prepare three things: the current working configuration, the new override snippet, and a rollback plan. After applying it, check that the number of proxies is as expected, groups are nonempty, rule references exist, and DNS and ports still match your plan. If an update causes problems, disable the new override and return to the baseline first. If that works, enable changes one section at a time instead of reinstalling the client and losing useful troubleshooting evidence.

Clients differ in how they switch between and merge multiple profiles. Switching to another configuration does not necessarily mean using proxies from both. First understand the client's profile model; see Profiles and managing multiple subscriptions. For long-term maintenance, a brief note on rule intent and source relationships is easier to migrate and verify after updates than a complex, undocumented merge script.

External control and maintenance

The external controller API reads core status, switches policies, shows connections, and triggers some management operations. It is not a proxy port for apps to access the internet. A common controller port is 9090; a mixed proxy port might be 7890. Pointing a browser or system proxy at the controller port will not provide a working proxy. Before deployment, document the purpose, bind address, and permitted devices for each port separately.

Bind to localhost whenever possible

A single-device client usually does not need to expose its controller to the LAN. Binding to a loopback address limits access. If the client already manages the controller and its authentication secret, do not override them in a local configuration or the built-in dashboard may lose its connection. The example uses a teaching-only secret to show where the field goes. In a real setup, generate a unique, strong secret and store it securely.

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

Controller authentication does not replace network security boundaries. If remote administration is necessary, plan a trusted network, encrypted transport, and firewall restrictions before changing the bind address. Do not expose the controller on every interface for convenience or forward its port directly to the public internet. Anyone with access may change routing policies or read connection details, so protect it like a system administration interface.

Use the API to isolate controller issues from dashboard issues

Test the API on the device running the core before troubleshooting the browser dashboard. The credentials in the commands below match the teaching configuration above; replace them together when using your own setup. Authentication failure, connection refusal, and unexpected response content are different issues: check authentication settings, the listener or process, and the port or service respectively. Re-downloading the dashboard will not fix all three.

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/version

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/proxies

In Windows PowerShell, curl may behave differently depending on aliases or the version. Use curl.exe explicitly if needed, and adjust line breaks for your terminal. Once the API returns data, check the address, protocol, and credentials configured in the dashboard. A dashboard loaded over HTTPS may also be blocked when it tries to connect to a plain HTTP API because of browser mixed-content restrictions.

Static dashboards and connection history: limitations

external-ui specifies the directory for local dashboard files, resolved relative to the core's working directory. Having the files on disk does not mean the dashboard is connected to the right core; check the controller address and authentication after opening it. Built-in dashboards usually handle this connection. Desktop users should generally use the entry point provided by their client rather than maintaining multiple dashboards from unknown sources.

The dashboard's connection list usually shows current connections; it is not a permanent audit log. Visible data may change when the core restarts, connections close, or the configuration switches. Keep the logs needed for troubleshooting, but do not publish connection details indefinitely. When reporting an issue, describe the destination category, matched rule, and error type. Remove subscription URLs, credentials, and complete browsing history first.

Create a post-update verification checklist

After every client update, subscription replacement, or override change, verify the setup in the same order: confirm the core starts, check the actual listening ports, confirm providers load, test rule matches, then verify DNS and TUN. Check the external dashboard last. Even if the dashboard is temporarily unavailable, logs and a basic connection test can show whether proxy routing works, preventing a management UI issue from being mistaken for a complete network outage.

Rollback should restore the last verified configuration as a whole, not just undo the most recently edited file. The subscription cache, overrides, proxy selection, and client toggles all affect the final behavior. Keep a recovery note listing which overrides to disable, which profile to select, whether to turn off TUN, and when to clear caches. After restoring, start a new connection to make sure an old session is not hiding the result.

Each section can be used on its own, but changes should follow their dependencies: stabilize the entry point and proxies first, then set up groups and rules, adjust DNS, TUN, and sniffing, and configure remote management last. For basic connection issues, check system proxy settings. To switch clients, return to the Download Center. A visible result and a workable rollback plan are more valuable for maintenance than continually adding configuration fields.