Clash YAML Configuration Guide

1. YAML Structure and How Configuration Takes Effect

A Clash configuration file is not a script that runs line by line; it is a set of hierarchical data. Top-level fields define listeners, proxy sources, groups, and rules. The core reads the entire file and creates the corresponding objects. This distinction matters: placing a rule at the end of the file does not mean it is created last. Matching order is determined by the order of entries in the rules list. The file can have any name and may use the .yml extension, but the configuration currently selected in the client is the one that matters.

Recognize mappings, lists, and strings

A colon separates a field name from its value, and is usually followed by a space. A hyphen marks a list item. Indentation defines nesting; use two spaces consistently and avoid tabs. Here, proxies lists candidates inside a proxy group—it is not the top-level list of proxy nodes. The same key can appear at different levels with different meanings. If parsing fails, check the indentation around the reported line before focusing on its text.

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

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

rules:
  - MATCH,Outbound Selection

This minimal direct-connection configuration illustrates the structure. It opens a mixed proxy port, but all traffic ultimately goes direct; it does not provide remote proxy access. Use it to check whether the core can read the file before importing complex rules, which makes syntax issues easier to isolate. DIRECT is a built-in outbound and needs no separate definition. A proxy group's name must exactly match the name used in rules: differences in spaces, punctuation, or capitalization can break the reference.

Distinguish the original subscription from the runtime configuration

In clients such as Clash Plus and Clash Verge Rev, a remote subscription is often only a configuration source. The client may also apply port settings, TUN toggles, global extensions, and overrides for the selected subscription, then generate the file used by the core. Editing a temporary generated file is rarely a lasting fix: switching subscriptions, saving settings, or restarting may regenerate it. First identify whether you are editing a subscription copy, a persistent override, or just viewing the runtime result.

A plain YAML file can pass a syntax check and still fail mihomo's field requirements. For example, a generic YAML parser accepts proxy-groups as a string, but the core expects a list. Conversely, valid syntax and structure do not guarantee that a node can connect; DNS, authentication, and the remote service still need to be checked. Troubleshoot “can be parsed,” “can start,” and “can connect” as separate stages to avoid repeatedly changing unrelated fields.

Check these three details before saving

First, save as UTF-8 to avoid editors corrupting group names with non-ASCII characters. Second, quote strings containing a colon followed by a space, a hash, or special punctuation. A comment starts at a hash outside the quotes and is not part of the value. Third, do not repeat a key at the same mapping level. Parsers handle duplicate keys differently: some report an error, while others keep only the last value. Neither behavior is a reliable way to merge settings.

Keep a working copy before making changes, then edit a separate test configuration. If you have a standalone mihomo executable, test the configuration with mihomo -t -f config.yaml. Use the same core version as the client and check the working directory for relative-path dependencies. After a successful test, reload the configuration and confirm in the logs that it was accepted. If a subscription returns unexpected content, see the Subscription Parsing Failure Checklist.

2. Common Fields: Listening Ports and Run Modes

Common fields control how the core accepts local connections and whether incoming traffic is routed by rules. They do not replace Windows system proxy settings. A listening port only means applications can connect to it; whether any application sends traffic there depends on the client's system proxy toggle, the app's own proxy settings, or TUN. If nothing changes in your browser, check the traffic entry point before changing the node protocol.

port, socks-port, and mixed-port

There is no need to enable all three proxy ports for the sake of completeness. For typical desktop use, one mixed port is enough. You can change the port number as long as it is in the valid range, unused, and matches the value configured in the application. The 7897 used here is an example, not a universal client default. If you change it, update browser extensions, command-line tools, and download managers that still use the old port.

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

These settings are a good starting point when only local applications need access. allow-lan: false prevents devices on your local network from connecting; an explicit loopback listening address reinforces that this is for local use. To let a phone use your PC's proxy, adjust the relevant restrictions, use the PC's LAN address, and configure Windows Firewall for a trusted network. Do not disable the entire firewall to troubleshoot, or expose a local proxy port to the public internet.

Rule mode and proxy groups are separate settings

mode: rule matches connections against rules in order; global uses the global outbound selection; direct sends connections directly. Switching to global mode does not change the rule text; it changes how traffic is routed. In rule mode, a rule may point to a selection group that in turn points to direct, so being in rule mode does not prove a request used a remote proxy. Check the matched rule and final outbound chain to verify.

A mode button in the client may override the file's value at runtime or write a new value when the configuration is regenerated. If the mode changes back on every restart, check the client's persistent settings instead of repeatedly editing the subscription. For troubleshooting, you can temporarily set log-level to debug, then restore it to info. Debug logs may contain domain names and connection details; remove subscription URLs, credentials, and personal browsing records before sharing them.

Top-level IPv6 and the control interface

The top-level ipv6 field controls IPv6 support in the core; it is not the same as the field of the same name under DNS later in this guide. Disabling it does not turn off IPv6 on a Windows network adapter, nor does it prove that all applications are being intercepted. If your network needs IPv6, check the traffic entry point, routing, DNS, and node capabilities together rather than using a single toggle to mask an inconsistent path.

external-controller is a management interface, not an HTTP proxy port for your browser. The client usually manages its address and access credentials, so avoid changing them casually in a subscription. If the connection panel stops displaying data while the proxy still works, distinguish an unavailable management interface from a failed proxy listener. To check for a port conflict, run Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue in PowerShell and identify the process using the port. Do not terminate an unfamiliar system process.

3. Proxy Nodes and Subscription Providers

A node definition describes how to connect to a remote proxy service. The top-level proxies field is usually a list of nodes, each with a name, protocol type, server address, port, and protocol-specific credentials. A name is a local identifier used by proxy groups; it does not automatically become a server address. Renaming a node can make it easier to identify in the UI, but update any groups that reference it explicitly. If a subscription regenerates node names on update, managing them through a provider or stable group structure is a better fit.

Shared fields and protocol-specific fields

server can be a domain name or IP address. port is the port the remote service actually listens on; do not use an arbitrary number from a share link. Authentication varies by protocol: Shadowsocks typically uses an encryption method and password, Trojan uses a password and involves TLS, and VLESS has its own identity and transport parameters. Changing only type does not convert a node to another protocol; the server must provide a matching service.

proxies:
  - name: "Local SOCKS Entry"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: "Outbound Selection"
    type: select
    proxies:
      - "Local SOCKS Entry"
      - DIRECT

This snippet uses valid SOCKS5 fields, but it only forwards traffic if a SOCKS service is actually running locally on port 1080. It does not provide a remote node, and should not point back to mihomo's own mixed port or it may create a loop. The local address is used to illustrate the data structure without inventing credentials. Get actual node settings from your provider and verify each field; do not replace your own credentials with values from a web example.

udp: true allows the node to handle the relevant UDP traffic; it does not add UDP support to a service that lacks it. The protocol implementation, server configuration, network path, and traffic entry point can all affect the outcome. If web pages work but voice chat or games do not, first confirm the application's transport and whether the node can carry it. A working web page alone does not prove the entire connection path is healthy.

proxy-providers supply collections of proxies

Use proxy-providers when you need to update a set of nodes independently. A provider usually contains a proxy collection with a proxies list; do not assume an arbitrary full-configuration URL uses the same format. An HTTP provider fetches remote content, while a file provider reads a local file. A provider is not a proxy group: a group must reference it with use. The example below uses a local file to show how they fit together. Keep the path within the configuration directories the core is allowed to read.

proxy-providers:
  local-pool:
    type: file
    path: ./providers/local-pool.yaml

proxy-groups:
  - name: "Subscription Outbound"
    type: select
    use:
      - local-pool
    proxies:
      - DIRECT

The corresponding local-pool.yaml should contain a list of nodes, not another layer of proxy-providers. Relative paths are usually resolved from the runtime or core working directory, not necessarily from the folder open in your editor. If the file cannot be found, check the configuration directory shown by the client and the core logs. Do not move files into system directories or broaden disk-wide access permissions just to work around a path restriction.

Troubleshoot connection failures in stages

First check whether the server's domain resolves, then confirm the destination port is reachable, and finally verify authentication, the TLS server name, and transport parameters. The name used to verify a TLS certificate may differ from the connection address; use the value required by the server. If you see a certificate error, check the system clock, certificate chain, and name first. Do not routinely bypass certificate verification. A timeout and an authentication rejection are different problems; the error type in the logs is more useful than repeatedly changing ports.

Subscription URLs often contain access credentials, so hide the full link in screenshots, logs, and public support requests. Before switching clients, keep a record of your subscription source, then choose the right platform on the client download page. Clash Plus is our top recommendation, with options such as Clash Verge Rev also available. Graphical clients do not handle extended fields identically; check which fields their cores support during migration. For context, see mihomo vs. the original Clash core.

4. Proxy Groups: Selection, Health Checks, and Fallback

Proxy groups sit between rules and individual nodes. A rule can point to a group, which then selects a node; groups can also point to other groups to create a layered outbound structure. This means you can update the node set without changing every domain rule. Keep group names short and stable, and make their purpose clear—for example, “Work” or “Media.” A name does not create special behavior; the algorithm is determined by type and its related fields.

Use select when you want direct control

select creates a manual selection group, letting users choose a candidate in the client UI. It can contain nodes, other groups, and built-in outbounds such as DIRECT. The initial selection may depend on whether the client saves previous choices, so do not assume the first item in the list is active. After changing the configuration, verify the selection on the proxy page—especially if the group was previously set to direct, an old node, or a candidate that has since been removed.

proxy-groups:
  - name: "Automatic Fallback"
    type: fallback
    proxies:
      - "Local SOCKS Entry"
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "Outbound Selection"
    type: select
    proxies:
      - "Local SOCKS Entry"
      - "Automatic Fallback"
      - DIRECT

This snippet references the local node defined in the previous section; it cannot replace a complete configuration on its own. fallback selects an available outbound in candidate order. The example puts direct connection last to demonstrate fallback behavior. If your use case requires traffic to stop when the remote proxy fails, do not include DIRECT in the fallback group. Availability and privacy goals are separate: a successful fallback means an available candidate was selected, not that traffic stayed on its original network path.

url-test and fallback use different criteria

url-test selects a candidate based on test results, usually to find a responsive outbound; fallback focuses on candidate order and availability. interval is the health-check interval in seconds, not a timeout for each application connection. tolerance can reduce frequent switching caused by small differences, but it does not guarantee application latency. Changing the candidate in a group usually affects new connections; existing connections may not switch immediately.

Use an HTTPS health-check URL that returns the expected response reliably. The URL in the example is just a test target, not an external resource required by this site. Reaching one test target does not mean every website is reachable; conversely, a blocked test URL can make a healthy node appear broken. Do not judge a plan's bandwidth from one test, or mistake test latency for download speed. For troubleshooting, open the same URL manually and check the logs to see which node handled the request.

Keep nested groups acyclic

Groups can reference other groups, but they must not form a cycle. For example, having “Outbound Selection” reference “Automatic Selection” while “Automatic Selection” references “Outbound Selection” does not make decisions smarter; it creates an invalid dependency. Add providers with use and explicit nodes with proxies; combine them as needed. If the candidate list suddenly becomes empty, check whether filters are too restrictive, the provider updated successfully, and group names were not replaced by an override.

Load balancing does not split one download connection across multiple routes to combine their speeds. Depending on the balancing algorithm, separate connections from the same activity may use different outbounds, which can trigger login checks or session issues. Work accounts, payments, and services that require a consistent source address are usually better served by a single, explicitly selected outbound. For a typical desktop setup, one manual group and a small number of clearly nested groups are easier to maintain—and make connection paths easier to trace—than a large stack of similarly named groups.

5. Rule Syntax and Top-to-Bottom Matching

In rule mode, mihomo typically checks the rules list from top to bottom and uses the outbound specified by the first matching rule. Rule order matters just as much as rule content. A broad direct-connection rule near the top can prevent more specific domain rules below it from ever matching. Before adding a custom rule, decide whether you need to match a domain, destination IP, process, or another attribute, then choose the appropriate rule type. Do not just copy a similar-looking line.

Domain rules do not take full URLs

Use DOMAIN for an exact domain, DOMAIN-SUFFIX for a domain and its subdomains, and DOMAIN-KEYWORD for keyword matching, which is generally broader. These fields do not include https://, paths, or query parameters. A standard domain rule cannot distinguish a path in a URL. Login pages, images, and APIs on the same site may also use different domains, so check actual connections rather than relying only on the main domain in the address bar.

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Outbound Selection
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,Outbound Selection

The example uses a reserved documentation domain, not a real service. “Outbound Selection” must exist as a proxy group. The final MATCH rule catches connections that did not match earlier rules and usually belongs at the end. The private-address rule before it illustrates direct access to a local network, but review it against your actual setup: some corporate subnets require a specific tunnel, so “private address” does not always mean “safe to connect directly.”

Know what no-resolve does—and does not do

IP-based rules may need a destination address before they can match. If a request contains a domain, resolving it may also affect the subsequent matching path. Adding no-resolve prevents this rule from actively triggering a DNS lookup for matching; connections that already have a destination IP can still match. It does not mean the connection will never use DNS, nor does it automatically map a domain to an address. For reliable domain-based routing, put domain rules first and add IP rules only where needed.

Process rules can route traffic by Windows application, but they depend on the core identifying the process behind a connection. The entry method, permissions, and system environment can all affect detection. Browsers use multiple child processes, and application updates can change executable paths, so check the actual process details in connection information before writing a rule. Process matching is not a promise of firewall-level isolation; use operating system controls as well when strict network restrictions are needed.

Check both format and behavior for rule providers

rule-providers organize reusable rule collections; their contents differ from those of proxy providers. behavior describes how entries in the collection should be interpreted. Common values include domain, ipcidr, and classical. format describes the file format. These answer different questions—what kind of rules the file contains and how it is encoded—and are not interchangeable. The example uses a local classical rule set to show the complete relationship.

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,Outbound Selection

# Contents of ./rules/local-domains.yaml:
# payload:
#   - DOMAIN-SUFFIX,example.com
#   - DOMAIN,intranet.example.org

Entries in a rule collection do not include an outbound; the RULE-SET reference specifies the target. If a rule set fails to load, check its path, response content, and format before removing the entire rule list. A remote URL may return a login page or error message; a successful HTTP request does not make it a valid rule file. The update interval controls how often the file is fetched, not whether its contents can be parsed.

To verify a rule, check the target domain, matched rule, and final outbound on the client's connections page before changing its position. Existing connections may continue using their original route; close the app's connection or restart the app before testing, but do not assume one refresh rebuilds every connection. For details, see the connection verification steps. If your subscription updates regularly, put custom rules in a persistent override. For merging details, see Overrides & Merging.

6. DNS: Resolution Paths and fake-ip

DNS configuration determines how domains are resolved to addresses and which path DNS queries take. It is related to proxy selection, but it is not the same set of controls. A browser reaching a site through a proxy does not mean every system DNS query goes through the core. Conversely, enabling the core's DNS service does not mean Windows or applications are sending queries to it. To investigate a Clash DNS leak, first identify the query source, resolver, and network route; one field alone cannot tell the whole story.

A listening address does not mean system DNS is being intercepted

dns.enable enables the core's DNS service, and listen sets its local listening address. The example uses a loopback address and a non-standard port to avoid conflicts with system services. Adding this configuration alone may not change Windows default DNS, which can still use the network adapter's DNS unless TUN interception or explicit forwarding is configured. Do not enter an address with a port in a network adapter field that accepts only an IP address; each entry point has its own format requirements.

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

This illustrates DNS configuration structure; the upstreams shown are not suitable for every network. default-nameserver is mainly used to bootstrap resolution of DNS upstream hostnames, avoiding a dependency loop where the resolver's own domain must be resolved first. nameserver lists upstreams for ordinary queries. Encrypted DNS changes how queries are transmitted, but does not automatically change their outbound route or solve a local network's inability to reach an upstream.

fake-ip requires connections to return to the core

fake-ip assigns synthetic addresses to domains, and the core keeps a mapping between each address and its domain for handling subsequent connections. The example range is intended for these mappings, not as a real public website address. If an application receives a synthetic address and connects directly without going through the core, the connection may fail. DNS and traffic entry points must work together. Seeing a synthetic address does not mean resolution failed; what matters is whether the subsequent connection reaches the same core instance.

fake-ip-filter can exclude some domains from synthetic addressing. This is often useful for local device discovery or services that are genuinely incompatible, but it should not become a catch-all for every anomaly. First check whether the application requires a real IP, uses its own DNS, and which resolver should answer local network domains. redir-host uses a different approach with its own matching and resolution constraints. After switching modes, account for old DNS cache entries before judging the new settings.

Choose DNS upstreams by domain and resolve proxy servers

nameserver-policy lets you select DNS upstreams by domain, which is useful when corporate intranet domains must use an internal DNS server. Proxy server hostnames can be resolved separately with proxy-server-nameserver, reducing dependencies between proxy and general-purpose DNS lookups. If you enable respect-rules so DNS upstream connections follow routing rules, first establish how proxy node hostnames will be resolved. Otherwise, you can create a loop where proxy access is needed to resolve a name, while resolving that name is needed to connect to the proxy.

DNS field precedence can change the actual behavior. Avoid combining lots of fallback upstreams, per-domain policies, and rule dependencies when setting up DNS for the first time. Start with one clear resolution path, then add exceptions as needed. Pay particular attention to browser Secure DNS, other VPNs' DNS settings, corporate security software, and router forwarding; any of these can send test queries through an unexpected path. More fallback upstreams are not automatically better—check the reachability and intended scope of each one.

If needed, run ipconfig /flushdns after making changes to clear the Windows DNS cache, and restart applications with their own caches. Clearing the system cache does not necessarily clear browser, core, or remote resolver caches. If a local printer or corporate domain stops working, restore the correct internal DNS resolution before disabling routing altogether. Once the new setup works, save it as a persistent setting and note which domains need local resolution for future maintenance.

7. TUN, System Proxy, and Windows Routing

System proxy and TUN are two common traffic entry points. The system proxy works with applications that honor Windows proxy settings, making it a good first option for testing browser connections. TUN uses a virtual network adapter and routing to handle more traffic, including apps that ignore system proxy settings. Enabling TUN does not change node authentication or add UDP support. First verify the outbound route with a working node and basic rules, then enable TUN; this avoids troubleshooting both the entry point and the remote connection at once.

Configuration fields and client permissions both matter

Creating a virtual adapter, changing routes, and installing services on Windows may require elevated permissions. The client's service mode, running as administrator, and the core configuration each play a different role; no single YAML toggle performs every system operation. Prefer the client's own service installation and TUN controls. If the UI manages these fields, manual subscription edits may be overwritten the next time the configuration is generated. When troubleshooting, first check that the UI state matches the runtime configuration.

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

This example uses mihomo TUN fields: auto-route requests automatic route setup, auto-detect-interface identifies the outbound interface, and dns-hijack describes which requests should be handled by the core's DNS service. These fields need a working dns configuration. Intercepting traditional DNS traffic does not mean all encrypted DNS is intercepted. When an app resolves names over HTTPS, the traffic is different and needs to be considered separately.

The network stack is not a universal performance switch

stack selects a network stack supported by the core; compatibility depends on the operating system, core implementation, and application. mixed combines handling methods, but is not necessarily better on every device. If a particular app has issues, compare options one at a time while keeping a working baseline. Changing the stack, MTU, DNS, and node together makes it impossible to tell which change helped.

MTU affects packet size, and some paths can be affected by fragmentation or tunnel encapsulation, but MTU is not the cause of every slowdown. First check whether the issue affects only specific sites, transports, or large packets, then consider making a change. Applying a fixed value found online too early can make a working connection harder to diagnose. If the issue occurs only with TUN while system proxy works, focus on routes, entry points, DNS, and the network stack before replacing the subscription.

Troubleshooting multiple adapters and other VPNs

When a PC is connected to Ethernet, Wi-Fi, virtual machine networks, or a corporate VPN at the same time, the default route and DNS may come from different interfaces. Automatic outbound interface detection may not choose the expected one in complex network setups. Use Get-NetRoute -AddressFamily IPv4 to inspect routes and Get-NetIPConfiguration to check interface settings. Record the current state first, then disable conflicting software one at a time where permitted. Do not delete unfamiliar virtual adapters.

Enabling system proxy and TUN at the same time does not necessarily create double proxying, but it makes the traffic path harder to reason about. For troubleshooting, use one method at a time and disable any additional in-app proxy extensions to create a clear test setup. Company devices may be subject to administrator policies; follow your network's requirements rather than bypassing restrictions by deleting services or changing security policies. Once everything works, decide whether to enable client startup and service mode for ongoing use.

Before exiting the client, it's a good idea to turn off TUN and the system proxy, then confirm that normal network access has returned. If web pages fail after an unexpected exit, first check whether Windows proxy settings still point to a stopped local port, then check for leftover routes and other VPNs. Do not reset the entire network straight away. For a blank window or a service that will not start, see Windows client startup troubleshooting. To verify the connection path, return to the tutorial's verification section.

8. Overrides, Merging, and Safe Rollbacks

Subscriptions are usually maintained remotely, so direct edits to imported content can disappear when it updates. Overrides keep local preferences separate from the subscription source: the remote source can continue updating nodes while necessary local rules and settings remain in place. But “override” is not a universal editing feature defined by the mihomo core; it describes how a client processes configuration when generating a file. For the entry points, syntax, and processing order in Clash Plus, Clash Verge Rev, and other clients, follow each client's documentation.

Scalars, mappings, and lists merge differently

Scalars such as ports and mode are typically replaced by the later value. Mappings such as DNS may merge by subfield or be replaced as a whole. Lists such as rules and proxy groups may be replaced, appended to, or prepended. Unless the client documents its behavior, do not assume it will automatically “put this rule at the top of the list.” The example below shows the intended final rules snippet, not an override instruction that works in every client.

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Outbound Selection
  - MATCH,Outbound Selection

If the subscription already has rules, replacing its list with the example above will discard the other rules. If you append new rules to the end of an existing list that already contains MATCH, the new rules may never be reached. Use a client-supported prepend feature or specify the insertion point in a script, then inspect the generated result. When changing a group, also confirm whether you are modifying the existing group or accidentally adding a duplicate name.

Map the generation order before deciding where to make changes

Configuration generation may involve a remote subscription, subscription-specific extensions, global extensions, UI settings, and runtime selections. The client determines the actual order; this guide does not generalize one client's process to the entire ecosystem. If a saved override has no effect, inspect the final runtime file to see whether the field is present. If not, the override may not have been applied or may have been overwritten later. If it is present but behavior is still wrong, check references, rule order, and the traffic entry point.

A global override suits preferences shared across subscriptions, such as a specific local listening restriction. A subscription-specific override is better for rules that depend on a particular provider or group name. Putting a group name that exists in only one subscription into global rules can leave other subscriptions without a valid target when you switch. Before migrating, keep the old client's proprietary parsing scripts separate from core YAML; do not paste an entire script file into a configuration. See the Clash for Windows Migration Notes for a comparison.

Make changes in four steps: save, test, load, verify

Before saving, back up the working source and overrides, and store any subscription credentials in the backup securely. During testing, check YAML syntax, node references, and rule targets. If you can test with a standalone core, validate the final configuration—not just isolated snippets. When loading, make sure the client has not reverted to an older configuration and check the logs for parsing or provider errors. Finally, create a new connection for the behavior you changed and confirm the matched rule and final outbound are as expected.

# Test a specified file in a terminal with the corresponding core installed
mihomo -t -f config.yaml

# PowerShell: check whether the example proxy port is listening
Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

# Clear the Windows system DNS cache
ipconfig /flushdns

Each command answers a different question: a configuration test does not verify remote authentication, a listening port does not prove the destination website is reachable, and flushing DNS does not fix incorrect rules. Do not treat these commands as a universal three-step repair. If a command is not found, check the executable path or terminal environment before downloading a tool from an untrusted source. If the client has a built-in configuration checker, prefer it to avoid differences between the standalone and client core versions.

After updates, check dependencies—not just whether the client starts

A subscription update may rename or remove nodes, or change proxy groups and rules. A client update may also change how extensions are processed. After updating, check that groups referenced by local rules still exist, rule providers load correctly, and TUN and DNS still behave as expected. A successful startup only means the configuration was accepted; it does not prove that application routing still meets your goals. Test a new connection from an important app, then confirm that intranet resources and ordinary websites work as intended.

For more field definitions, see the Glossary. If you have not imported a subscription yet, return to the subscription import steps; there is no need to configure every advanced feature at once. Good configuration maintenance means every field has a clear purpose, every exception can be explained, and every update can be rolled back. Short, verifiable local overrides are usually easier to keep stable than maintaining a full copy of a subscription.