Advanced Clash Configuration

Proxy Group Types and Practical Use

Proxy groups decide which outbound route to use for a matching connection. Rules identify traffic, proxy groups choose a destination, and proxies establish the actual connection. These roles are distinct: if a rule matches correctly but access fails, check the group selection or proxy; if the proxy connects but traffic takes the wrong route, revisit rule order and group references. Start by noting the matched rule, policy chain, and final outbound in the Connections view. That gives you a basis for identifying which layer to change.

Manual Selection, Automatic Testing, and Failover

select lets you choose a member explicitly and is useful when a service needs a fixed outbound route. Members can be proxies or other proxy groups. Keep manual selection as the outermost entry point, with an automatic group as one of its options. If automated test results do not match real-world performance, you can temporarily pin the route without editing every rule. The client or core may save the selection, so check which member is actually selected after reloading the configuration.

url-test periodically requests a test URL and selects a member based on the results; tolerance helps prevent frequent switches caused by small differences. The test measures access to that URL, not performance on every site, download, or live call. fallback prioritizes available members in order, making it useful for primary and backup routes. It may switch back when the first available member recovers, so do not treat it as a sticky group that always keeps the current proxy.

load-balance distributes different connections across members, using strategies such as consistent-hashing and round-robin. It does not split one connection across multiple proxies to combine bandwidth. Some services are sensitive to changes in outbound IP, including login sessions, payment verification, and persistent connections; these usually work better with a fixed selection. Even with consistent hashing, adding or removing members can change assignments, so outbound stability is never guaranteed.

Build a policy chain you can follow

This minimal example uses only the built-in direct route to make the references easier to follow. In practice, add existing proxies or automatic groups to the member list for “Manual Egress.” Business groups reference the egress group, and rules reference business groups; names must match exactly. Quote names that contain spaces or special characters. Avoid circular references between business and egress groups: they can cause configuration validation to fail or make the selection chain shown in the interface meaningless.

proxy-groups:
  - name: Manual Egress
    type: select
    proxies:
      - DIRECT
  - name: Everyday Traffic
    type: select
    proxies:
      - Manual Egress
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Everyday Traffic
  - MATCH,Manual Egress

When proxies come from proxy-providers, use use within the group to reference a provider name. Do not put a subscription URL in proxies. Automatic groups usually also need url and interval. For example, you can use https://www.gstatic.com/generate_204 as a test URL and set the interval to 300 seconds. This URL is only a connectivity probe; replace it if it is not reachable in your network. Do not delete an entire subscription based on a single test result.

Verify and Troubleshoot After Switching

After changing a group selection, create a new request and inspect its connection details. Existing connections usually do not migrate when you switch groups, and browser connection reuse can keep using the old route. To test, close the relevant connections or restart the test app. Closing connections interrupts active tasks, so make sure downloads, meetings, and remote sessions can be stopped first. An unchanged existing connection does not mean the configuration failed to reload.

If an automatic group has no selectable members, check in order whether the provider loaded, the filter expression is too restrictive, member names match, and health checks are running. If members are available but the group keeps switching, check probe timeouts, test URL reachability, and tolerance. Avoid redundant probes: several automatic groups repeatedly testing the same proxies increase connection and battery use, especially on mobile devices.

Managing Rules with Providers

Rule providers separate traffic-matching data from the main configuration. Keep policy order and target groups in the main file, and maintain domain or IP range lists in provider files. Updating a traffic category then does not require changing every proxy and DNS setting. Providers also add dependencies: the source, download path, local cache, and file format must all match. A successful download does not mean the rules are being used; reference the provider with RULE-SET under rules.

Choose a behavior and file format

behavior: domain is for domain lists, ipcidr for IP ranges, and classical for full entries that include rule types. The file extension alone does not determine the behavior. Even in YAML, a domain list might contain +.example.com, while a classical entry might be DOMAIN-SUFFIX,example.com. Mixing the two can cause parsing errors or unexpected matches. Check the source's format documentation before importing a rule set.

format determines how the file is read. Depending on the source, use yaml, text, or a supported binary rule format. YAML rule sets usually list entries under payload; text files store one entry per line. Binary formats are limited to specific behaviors. Simply changing the extension of an arbitrary classical file will not make it usable. If conversion is needed, use a conversion tool supported by the core and keep the original data so you can compare the meaning before and after conversion.

Validate the rule flow with a local rule set first

Start with a file-based provider to separate download issues from matching issues. The path ./rules/local-sites.yaml in this example is relative to the configuration working directory; it may not be the same as the location where you imported the file in the interface. Desktop clients may generate the runtime configuration in a separate core directory. Confirm the actual working directory and create the rule file there. If the directory does not exist or permissions prevent access, fix the file read error before checking the rule contents.

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

rules:
  - RULE-SET,local-sites,DIRECT
  - MATCH,Manual Egress

Add the following content to the relevant local-sites.yaml. +.example.com is a common mihomo suffix-match format for domain lists and covers the domain and its subdomains. This is not the same structure as a comma-separated full rule under rules. Reload the configuration, visit the domain, and check the matched rule. “Manual Egress” is defined in the previous section; if testing this section on its own, first create a proxy group with the same name.

payload:
  - '+.example.com'
  - '+.example.org'

After local matching works, switch to type: http, add a real url and interval, and use a unique cache path. The update interval is in seconds; set it according to how often the source changes rather than polling frequently just to get the latest data. If the rule source must be downloaded through a proxy, configure the download policy if the core supports it. Make sure that policy does not depend on the same rules that have yet to load, or initialization may stall in a dependency loop.

Rule order matters more than the number of categories

Connections are typically matched against rules from top to bottom, and the first match determines the policy. Put a few clearly defined exceptions first, business categories in the middle, and the catch-all MATCH last. A broad IP range or domain list placed too early can capture traffic intended for more specific rules. Overlapping rule sets are not necessarily a problem, but you must decide which one takes priority. Otherwise, changing their order can send the same domain through a different route, making the proxy look unreliable.

IP-based rules may trigger DNS resolution to obtain the destination address. Where applicable, no-resolve avoids resolving a domain just to match the rule, but the rule may then fail to match if the connection has a domain and no destination IP yet. This is not a universal performance switch. First determine whether the category is identified by domain or IP range, then choose the appropriate behavior. Avoid combining domain, IP, and process rules into one hard-to-trace set.

Update failures and cache behavior

If a remote update fails, check that the URL is still valid, the response is actually a rule file, existing rules are not blocking the download, and the local cache is writable. Seeing a login page when you open the URL in a browser does not mean the core can retrieve rule data. Old cache data may keep an existing category working, or conceal a broken source. Check provider timestamps and logs rather than relying on whether the URL opens in a browser.

Optimizing DNS Configuration

DNS configuration must answer three questions: where apps send queries, which resolver looks up destination domains, and how connections to that resolver are routed. Enabling DNS in the client does not mean every app uses that DNS entry point. Browser-encrypted DNS, the system cache, LAN resolvers, and the scope of TUN interception can all affect the actual path. Start by observing where queries come from; adding more resolvers does not automatically make DNS more reliable.

Separate DNS for destinations from DNS for proxy servers

nameserver handles general destination lookups. default-nameserver is mainly used to bootstrap resolver hostname lookups; it is not a universal fallback for every failed query. If a proxy server uses a hostname, it must be resolved before the proxy connection is established. Configure that separately with proxy-server-nameserver. Otherwise, resolving the proxy server may depend on a proxy connection that cannot be established until its hostname is resolved, creating a loop.

nameserver-policy selects resolvers for specific domains and is useful for internal names or services with explicit DNS requirements. Send LAN hostnames to a resolver that understands that network rather than automatically using a public resolver. The following is an example structure; the addresses illustrate one possible combination, and should be chosen based on reachability in your network. Bind the listener to the local machine. If you are only testing DNS, there is no need to expose the listening port to other devices.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    '+.home.arpa':
      - system

home.arpa is a special-use domain for home networks. The example sends it through the system resolver, which must actually support the name. Do not assume every LAN uses the same domain naming scheme. Corporate networks may require a specific internal DNS server; note the original system settings before making changes. If a device is connected to both a VPN and a local network, also make sure proxy rules or another tunnel are not diverting traffic to the internal resolver.

Understand the transport path for encrypted DNS

DoH and DoT protect queries between the client and resolver; they do not determine whether the resulting service connection is proxied. Encrypted DNS still requires a reachable resolver, correct system time, and a valid certificate chain. With respect-rules enabled, resolver connections follow routing rules, so proxy server hostname resolution must also be configured carefully to avoid a dependency loop. There is no need to enable this setting immediately. Verify basic DNS first, then check which rules match resolver connections.

fallback and fallback-filter can help select DNS answers based on domains or returned addresses, but they also add queries and dependencies. Different resolvers may return different addresses for the same domain due to CDN routing, cache age, or client location. A difference alone does not mean an answer is wrong. Record the failing domain, DNS responses, and actual connection address before deciding whether policy-based resolution is needed. Do not expect fallback resolvers to handle every discrepancy.

Test a single domain instead of resetting everything

On a system with dig, run the command below to query the local DNS listener directly. In Fake-IP mode, receiving a mapped address is expected. This test confirms that local DNS can answer; it does not prove that the service itself is reachable. Make an app request as well, then check whether the domain is preserved, the correct rule matches, and the outbound route works. If there is no response, check the listener, whether the configuration has taken effect, and whether another process is using the port.

dig @127.0.0.1 -p 1053 example.com A

If only the browser fails while command-line lookups work, check the browser's Secure DNS setting, extensions, and cache first. If all apps fail, check system DNS and interception settings. After switching enhanced modes, old DNS cache entries may point to addresses that do not work on the new path. Close relevant app connections and clear the cache using the system's recommended method. For HTTPS certificate errors, do not hide the problem by disabling certificate verification. See How Proxy Connections Affect Certificate Errors to distinguish time, certificate chain, and network path issues.

TUN and Fake-IP

TUN is an entry point for traffic interception; Fake-IP is a way to associate DNS queries with connections. They can work together, but they are not the same setting. System proxy settings mainly affect apps that honor them. TUN uses a virtual network interface and routing to send more IP traffic to the core. Fake-IP creates a mapping between a queried domain and a synthetic address, which the core can then use to process the connection by domain. Understanding these layers helps explain why an app may bypass the core with TUN enabled, or why a mapped address may still be unreachable.

Permissions, virtual interfaces, and default routes

Before enabling TUN, make sure the Clash client has permission to create an interface and modify routes. Desktop systems typically require administrator approval, service mode, or a privileged helper. Mobile systems use VPN permission to create an interception interface. An enabled switch only means the client attempted to start TUN; check the core logs for interface and route status. If multiple VPNs, virtual machine networks, or security tools modify routes, repeatedly restarting the client will not identify the source of a conflict.

Here is a common starting configuration. auto-route configures interception routes automatically, auto-detect-interface attempts to select the outbound interface, and dns-hijack sends specified DNS traffic to the core's DNS module. Support and behavior for stack: mixed depend on the running core. If the client generates its own TUN configuration, verify the values in the final runtime file rather than checking only the original subscription.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.home.arpa'

DNS hijacking applies to the traditional DNS traffic on the ports listed here. It does not automatically decrypt DoH built into apps or intercept every multicast name discovery protocol. LAN discovery, printing, and device control may use separate protocols, so check the system routes as well. Mobile VPN implementations are not equivalent to desktop TUN settings. Some options are managed by the client, so do not assume every field in a desktop YAML configuration is available in the mobile interface.

Fake-IP mappings and excluded domains

A mapped address is not the website's real server address and should not be saved in a browser as a permanent destination. An app should get the mapped address from a domain lookup, then let the core use the mapping to establish the actual connection. If DNS runs through the core but the connection bypasses it, the app may try to reach the mapped address as if it were a real destination and time out. In Fake-IP mode, keep the paths for relevant DNS queries and service connections consistent, especially when only some apps are intercepted.

fake-ip-filter tells the resolver to return real addresses for specific names. This is commonly used for local services that need real IPs or compatibility exceptions. The example assumes the default blacklist mode; if you choose a different filter mode, review what the list means. This filter does not mean “send these domains direct.” It only changes the DNS response; the final route is still determined by rules. After adding an exception, check the cache and existing connections, or the app may keep using an old mapping.

Fake-IP mappings usually use a dedicated address range. Do not change it arbitrarily to a private range already used by your home network. If it conflicts with an existing route, another VPN, or a test network, adjust both the mapping range and interception path—not just one address. Consider IPv6 as part of the whole setup: apps may prefer AAAA answers, so checking IPv4 alone can miss IPv6 traffic that is not being intercepted. Enable IPv6 based on your network and client support.

Platform differences and recovery steps

When troubleshooting, turn off other VPNs first and leave only one interception method enabled. Then check whether the core successfully created an interface. Next, check DNS responses, and finally create a new connection to see which rule matches. If only certain apps fail, check app bypass lists, protocol types, and built-in DNS. If the entire network is offline, investigate routing and DNS loops first. For a full proxy timeout checklist, see Step-by-Step Troubleshooting from Subscription to DNS. Do not delete all your configuration at once.

Domain Sniffing

Domain sniffing supplements the destination domain by reading initial connection data. It can help match domain rules when a connection provides only an IP address—for example, when an app performs its own DNS lookup and connects directly to the resulting IP, leaving the core without a DNS mapping. Where the protocol allows, sniffing can read the HTTP Host header, the server name in a TLS handshake, or supported QUIC handshake data. It supplements observable protocol metadata; it does not read all app content or fix every connection issue.

When to sniff domains

If connection details already show the correct domain and the expected rule matches, there is usually no reason to broaden sniffing. It may help when connections for a particular service regularly show only IP addresses, causing domain rules to fail, and the protocol exposes a domain name. Pick one service and compare connection details before and after enabling sniffing. Confirm that the domain was actually recovered before expanding coverage. A sniffing event in the logs alone does not mean the outbound route changed as intended.

This example covers common HTTP and TLS ports and keeps a skip list for local names. force-dns-mapping and parse-pure-ip broaden sniffing attempts and are useful when you have confirmed missing mappings or connections to bare IP addresses. For initial troubleshooting, leave these options out and see whether the default scope is sufficient. Changing interception, DNS, and sniffing settings all at once makes it hard to identify the cause of any result.

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
  skip-domain:
    - '+.home.arpa'
    - '*.lan'

Domain detection versus destination override

Once a domain is sniffed, the core can use it to help match rules. Whether that domain replaces the connection's original destination depends on the relevant setting. override-destination changes how the destination is handled and may prevent later resolution and connections from using the IP originally selected by the app. This may not be appropriate for CDNs, internal mappings, or services that deliberately connect to a specific address. The example disables HTTP destination override so you can first observe the effect on rule classification without changing the destination of every connection.

If an app connects to one IP but the handshake names another service, first determine whether this is expected, such as shared hosting or a specialized network setup. Do not assume a sniffed value is a suitable replacement destination just because it looks like a domain. If the service must keep its original address, restrict the ports, add a skipped domain, or disable destination override for that case. After making changes, compare both the matched rule and final connection address; do not rely only on whether the page opens.

What encrypted protocols expose

A TLS server name is not always observable. Connections using encrypted client handshake data, handshakes with no server name, and nonstandard protocols may not provide a usable domain for sniffing. QUIC support also depends on the core, handshake format, and interception path. Adding QUIC to the sniffing configuration only tells the core to try to identify that traffic. It does not convert UDP to TCP or guarantee that the proxy supports the UDP forwarding the service needs.

Sniffing usually waits for data from the start of a connection. A broad port range can send many unrelated connections through the sniffing process, making troubleshooting harder. For games, real-time voice, and custom services, confirm the protocol before including it. If connections take longer to establish, compare results with sniffing disabled and with a narrower port range. Attribute the problem to sniffing only when the result is repeatable and clearly linked to the change—not after one successful request.

Skip rules and step-by-step validation

skip-domain excludes names that are unsuitable for sniffing, such as internal domains, services that must retain their original destination, or apps with confirmed compatibility issues. It has a different purpose from the Fake-IP filter list: the former limits sniffing; the latter changes DNS responses. A domain in one list is not automatically included in the other. If you need to adjust both, document each reason separately so removing one exception later does not leave the other behind.

Validate in three steps. First, keep the original configuration and record whether the domain is present and which outbound route is used. Next, enable only sniffing and check whether the domain appears and the matched rule changes. Finally, try destination override only if needed, then compare the connection address and service behavior. Create a new connection at each step and keep a configuration you can restore. Raise the log level only enough to observe what you need, then restore your usual level to avoid retaining unnecessary domain and access records.

Local Overrides and Merging Subscriptions

Subscription configurations and local preferences follow different update cycles. Subscription providers update proxies, policies, and rules; local users maintain listener ports, DNS, service exceptions, and interception scope. Directly editing a downloaded subscription can mean losing your changes at the next update. Keeping local settings in an override layer makes them reusable. Note that mihomo does not define one universal override feature in the interface: Clash clients may use merged files, scripts, GUI options, or configuration templates. Confirm the actual processing order in your client.

Source configuration, override layer, and runtime configuration

Keep track of three separate files: the original subscription, user-maintained overrides, and the final configuration passed to the core by the client. Use the last one when troubleshooting. A client option may overwrite YAML during generation, and a template may assign the same field more than once. If DNS is enabled in the original file but missing from the runtime configuration, editing the source file again will not help. Find the generation order and what is overwriting the setting.

Mappings and lists often merge differently. DNS settings may merge by field, while rules, proxy-groups, and proxy lists may be replaced in full. Do not assume a client behaves like a general-purpose YAML merge tool. Test by overriding a single observable field, such as the log level, and check the runtime file before adding rule lists. If the entire rules list is replaced, make sure the subscription rules are preserved; do not assume that adding one rule simply appends it.

Use providers to combine proxy sources

Merging multiple subscriptions does not necessarily mean combining two complete profiles. A more maintainable approach is to configure supported proxy sources as separate proxy-providers and keep one set of policies and rules in the main configuration. The example shows two HTTP providers. The URLs are for illustration only; replace them locally with real, compatible proxy sources. Not every complete subscription can be used directly as a proxy provider. Before importing, check the response format, especially whether it contains usable proxies data.

proxy-providers:
  source-a:
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/source-a.yaml
    interval: 3600
  source-b:
    type: http
    url: https://example.org/provider-b.yaml
    path: ./providers/source-b.yaml
    interval: 3600

proxy-groups:
  - name: Combined Egress
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

Give each provider its own path so different sources do not write to the same cache file. Set update intervals according to the sources, and update manually when needed instead of forcing both sources to refresh frequently. Duplicate proxy names can make selections and logs ambiguous. Use the client's supported name normalization or provider override features to add a source identifier. Never include real subscription credentials in names, and do not try to fix duplicates by stripping every character from a name.

Place local rules deliberately

Before adding a local exception, decide where it should go. A rule appended after the subscription's MATCH is usually never reached. A better approach is to put a small number of local rules first, followed by the subscription's existing rules or rule providers. If the client offers pre-rule and post-rule sections, check the final order, especially if a template automatically adds a catch-all rule. Adding many exceptions at once makes it harder to identify which one changed the route when a service behaves unexpectedly.

Check proxy group references when merging as well. Rules in the original subscription may reference “Auto Select,” while a new template defines only “Combined Egress.” Even if all proxies import successfully, an undefined policy name can cause a configuration error. Rule provider names, proxy provider names, and proxy group names are different kinds of references; replacing text across the whole file is not enough. List each type of definition and verify every reference. When renaming, check rules, group members, and the names shown in the controller.

Validate syntax and run regression checks

If you can use the core from the command line, test the configuration to check its structure and references. The command below requires mihomo to be available and the file to exist in the current directory. Desktop clients may also provide a configuration check. Passing syntax validation does not mean proxy credentials work, rule sources can be downloaded, or every service works. Run functional checks too: test a local service, a commonly used website, and one service that requires a proxy, then inspect their connection details.

mihomo -t -f ./config.yaml

After every subscription update, check that the runtime configuration still includes your local DNS settings, exceptions, and interception options. A short change log with the field, reason, and rollback steps is more useful than a pile of unlabeled backups. If the client crashes on startup after an update, restore the last working configuration first, then use How to Diagnose Startup Crashes from Logs to check syntax, paths, and permissions. Do not clear every profile at once.

External Controller

An external controller API lets you read runtime status, switch policies, inspect connections, and manage some core features. A panel is a visual client for that API, not a separate proxy core. Opening the panel does not mean it is connected to the current Clash client; verify the controller address, authentication, and instance. A page may connect to an old process while the system proxy points to a new one. If a switch reports success but connections do not change, check which instance the panel controls before reinstalling anything.

Bind to localhost before considering remote access

external-controller sets the listening address for the HTTP controller API. For typical desktop use, bind it to 127.0.0.1 so only local connections are accepted. secret is the API access token; set a long, unique value locally. The example intentionally shows only the listener and local UI directory, not a copyable public token. Add your own authentication setting before using an external panel. Do not reuse your controller token as a proxy password or subscription token.

external-controller: 127.0.0.1:9090
external-ui: ./ui

external-ui points to a directory containing prepared static panel files; this setting alone does not generate a complete interface. Relative paths depend on the core's working directory, and some clients include a panel and set the path automatically. Check that the entry file exists and the core can read it before opening the panel. If the page is blank or resources fail to load, check the UI directory and static asset paths. Do not mistake a frontend loading error for a proxy failure.

API authentication and browser restrictions

Standard HTTP APIs use Bearer authentication, with the token sent in the Authorization header. Panels usually save the controller address and token in their connection settings. After entering them, check the basic status before trying to switch a policy. Browser cross-origin restrictions and API authentication are separate: a valid token can still be blocked by cross-origin policy. For a panel served from another origin, configure CORS to allow trusted origins supported by the core. Do not allow arbitrary websites to access the local controller just to troubleshoot.

An HTTPS page connecting to an HTTP controller may also be blocked as mixed content, especially when the controller is not on the local machine. Do not disable browser security as a long-term workaround. Prefer the client's built-in panel or serve the panel and controller from an appropriate same-origin path. For remote management, use a controlled tunnel or an authenticated, TLS-protected management endpoint, and restrict which people and networks can access it. A controller port is not an ordinary public web port.

Start with read-only checks

The command below reads a local token from an environment variable instead of putting its real value in the documentation. Before running it, set MIHOMO_SECRET in your terminal environment. If the variable is unset, the command stops with an error rather than sending an empty token. A successful response shows that the API at that address is reachable; verify that it belongs to the current instance. When checking connections and logs, keep only what is needed for troubleshooting. Do not publicly upload full results containing domains and network addresses.

: "${MIHOMO_SECRET:?Set the controller token locally first}"
curl --fail --silent --show-error \
  -H "Authorization: Bearer ${MIHOMO_SECRET}" \
  http://127.0.0.1:9090/configs

Once read-only checks work, use the panel to switch one manual group and create a new connection to verify the policy chain. When calling the API directly, URL-encode names; do not append a group name containing spaces or non-ASCII characters as-is and assume every tool will encode it correctly. Changes usually affect runtime state and may not be written back to the subscription. Whether they persist after a reload or restart depends on the client and its caching mechanism. Maintain settings that need to last in the appropriate configuration layer.

Troubleshoot controller and proxy ports separately

The controller port is for management; HTTP, SOCKS, and mixed proxy ports are for traffic. They are not interchangeable. If you set the controller port as the system proxy, web browsing will fail. If you set a mixed proxy port as the controller address in a panel, it cannot retrieve policy groups. Label each port by purpose and check whether another process is using it. For multiple instances, use a separate working directory and controller port for each to prevent caches, rule files, and panel actions from interfering with one another.

Troubleshoot panel connection failures by response: if it cannot connect, check the listener address, process, and firewall; if it returns an unauthorized error, check the token and request header; if the page opens but data fails, check the controller address, cross-origin restrictions, and browser console. If policy switching works but existing traffic does not change, check whether connections are being reused. Do not expose the controller on every network interface just to fix a local connection error. Local management does not require access from the whole LAN.

Build a repeatable configuration check

Keep the verification order consistent: confirm the active profile and runtime instance, then inspect the final YAML; check that providers loaded, groups have members, and rules match; verify DNS and traffic interception; and only then adjust sniffing or the panel. Change one factor at a time and record its original value and the result. To return to the setup workflow, continue with the Getting Started guide. To troubleshoot a specific symptom, visit Troubleshooting—there is no need to rebuild configuration layers that already work.