Cores, proxy modes, rules, and DNS—organized by concept. Understand what each setting does before changing your configuration.
This page is a reference for getting started with client setup and configuration. Each term has a shareable anchor. For advanced options and practical examples, see the configuration guide.
The interface handles controls; the core handles connections. A node describes a remote connection, while a port is a local or remote listening endpoint. They are not interchangeable.
Proxy Core · Formerly Clash Meta
mihomo is a proxy core evolved from Clash Meta. It reads configuration, matches rules, handles DNS, and forwards connections. GUI clients such as Clash Verge Rev provide the interface, but an option in the interface does not mean every core version supports the same configuration syntax. If you see a field error, check which core the client is actually using and consult its documentation before changing the configuration.
GUI client
A GUI client provides controls for importing subscriptions, choosing proxies, viewing logs, and setting the system proxy; the core typically handles the underlying connections. Clients may use the same core but differ in how they apply overrides, install services, and request permissions. When choosing a client, consider both OS support and configuration management. See the client comparison for details.
proxy · Remote connection parameters
A node is a set of parameters describing a connection to a remote proxy. It usually includes the protocol, server address, port, and credentials; some protocols also require transport-layer or TLS settings. A node is not the client itself—you still need to import a working configuration after installing the app. When a connection fails, distinguish between incorrect parameters, an unreachable server, and a local network issue. A node name or test result alone does not establish whether the service is working.
mixed-port
A mixed port accepts both HTTP proxy and SOCKS proxy requests on the same local listening port, so different apps can use a single endpoint. It is not the server port of a remote node. For local use, apps typically connect to the loopback address and this port. If you change the port, update the system proxy and any proxy settings entered manually in apps. For steps, see Clash port settings.
latency · request time
Clients typically access a specified test URL through a proxy and record how long the request takes, allowing response times to be compared under specific conditions. Results depend on the test site, handshake, connection reuse, and current network conditions; they do not measure download bandwidth or video playback quality. To troubleshoot actual performance, test in the target app and check logs for failed connections, packet loss, or congestion instead of choosing the lowest millisecond reading.
Rule, global, and direct modes determine where traffic goes. The system proxy and TUN determine how traffic enters the core. These are two different sets of settings.
mode: rule
Rule mode uses the rules in your configuration to choose an outbound target, so different domains or addresses can go direct, use a proxy, or be rejected. Rules are usually checked in order, and the matching target is applied; put specific conditions before broader ones. Beginners can start with rule mode for everyday use, but its behavior depends on the rules and policy groups in the configuration—it will not fill in missing routing logic automatically.
mode: global
Global mode sends all connections entering the core to the target selected by the global policy, making it useful for quickly testing whether a proxy can reach a destination. “Global” refers to outbound selection, not system-wide traffic capture: an app that ignores the system proxy may still bypass the client. Before switching, check which target the global policy actually selects. Restore the previous mode when testing is done, so a mode change is not mistaken for a rule fix.
mode: direct · DIRECT
Direct mode sends connections entering the core to their destinations without using a remote proxy server. The DIRECT target, by contrast, can be used by an individual rule. They have different scopes: one direct rule does not mean the entire configuration is routing directly. Direct mode also does not mean the app is closed; the system proxy, TUN, and core DNS may still be active.
system proxy
The system proxy registers a proxy address and port in the operating system, allowing apps that follow those settings to send requests to the local client. Browsers usually support it, but some games, command-line programs, and apps with their own network stacks may not. For a first connection, enable the system proxy and test in a browser. If another app still cannot connect, check its own proxy settings or consider using TUN.
tun · virtual network interface
TUN routes traffic into the proxy core through a virtual network interface and routing rules, including traffic from some apps that ignore the system proxy. It usually requires appropriate system permissions or client service support. Coverage also depends on routes, exclusions, and other networking software. TUN does not force connections to use a proxy; once traffic enters the core, the current mode still determines the outbound target. See TUN setup for instructions.
Rules answer “what kind of connection is this?” Policy groups answer “which outbound target should it use?” Referenced names must match their definitions in the complete configuration.
rules · condition matching
Rule-based routing sends connections to a specified policy group, DIRECT target, or REJECT target based on their domain, destination IP, or other conditions. Common domain rules include DOMAIN and DOMAIN-SUFFIX; MATCH is typically used at the end to catch remaining connections. When editing rules, check not only that the conditions are correct, but also that a broader earlier rule will not match first and that every referenced policy group exists.
proxy-groups
A policy group organizes multiple nodes or other policy targets under a stable name that rules can reference, rather than binding each rule to a specific node. Use select for manual selection, url-test to choose based on test results, and fallback to switch targets in order when one is unavailable. Each type solves a different problem. When configuring a group, check its members, test conditions, and references to other groups.
Automatic Proxy Testing
url-test periodically visits a specified URL through the proxies in the group, then selects an outbound target based on the results and related settings. The test URL determines which route is being compared; the interval and tolerance affect how often the selection changes. Frequent switching may not suit long-lived connections. This type can reduce manual selection, but it does not guarantee high throughput for large downloads or good performance on every site.
GEOIP · IP Geolocation Matching
GeoIP matches connections by the region associated with an IP address or by a database classification, and is commonly used for IP-based routing. Results come from a database and do not indicate the user's location; cloud migrations, shared infrastructure, and database updates can all affect classification. A domain may need to be resolved before an IP-based rule can match. With no-resolve, the rule does not trigger an extra DNS lookup.
rule-providers · RULE-SET
A rule provider stores matching conditions as a separate resource, defined with rule-providers and referenced using RULE-SET for easier updates and reuse. The resource format must match behavior; domain lists, IP lists, and classical rules are not interchangeable. A rule provider does not choose an outbound target—the referencing rule specifies the action. After an update, confirm that the resource loaded successfully.
Domain resolution and connection forwarding are related but distinct paths. If a website will not load, the problem may be with DNS resolution, routing, or the remote connection.
Domain Name System
DNS resolves domain names into addresses and other records so apps know which destination to connect to. The operating system, browser, and proxy core may each use a different resolver, so changing the core's DNS settings may not change the query path for every app. To troubleshoot, first identify which resolver is handling the request, then check whether the query succeeds, the returned address is expected, and the proxy server's domain can also be resolved.
enhanced-mode: fake-ip
Fake-IP returns a virtual address to the app and uses the address-to-domain mapping in the core to handle subsequent connections, preserving domain information for routing. This is not the website's real server address, so seeing a virtual address alone does not indicate a DNS error. For apps that need real addresses or are incompatible with this mapping, configure fake-ip-filter as needed and keep exceptions as specific as possible.
DNS leak · unintended query path
A DNS leak occurs when domain queries take an unintended path and are sent to a different resolver, potentially exposing the domains being queried. Check browser encrypted DNS, operating system fallback behavior, and queries that are not being intercepted separately. A test site showing a resolver's name is not enough to reveal the full query path. Encrypted DNS protects queries in transit, but whether it follows your intended setup still depends on the selected resolver and traffic routing.
sniffer
Domain sniffing attempts to extract domain names from visible protocol metadata in a connection, such as some HTTP requests or TLS handshake information, to help with rule matching. It does not decrypt TLS traffic and cannot recover domains from every connection; encrypted metadata and unsupported protocols may yield no result. If enabling it causes compatibility issues, narrow its scope to the relevant destinations instead of assuming every IP connection can be identified accurately.
Internet Protocol version 6
IPv6 uses 128-bit addresses, and a domain's AAAA record typically provides one. Whether connections work depends on the local network, DNS results, TUN route coverage, and proxy egress support—not just the IPv6 toggle in the client. If only some sites have issues, compare their IPv4 and IPv6 resolution and connection paths before deciding which layer to change. Avoid using a single toggle to mask an underlying routing problem.
Subscriptions provide remote resources, configuration defines how they work, and overrides preserve local changes. Before updating, check whether you imported a full configuration or just a proxy list.
subscription URL
A subscription URL retrieves a remote configuration or proxy list, allowing the client to update resources periodically instead of requiring each node to be added manually. Services may return a complete YAML file, a proxy list, or another format, so confirm that the client supports it before importing. URLs often contain access credentials; do not include them in public screenshots, logs, or messages. For import instructions, see how to import a Clash subscription.
config.yaml · structured configuration file
YAML uses indentation to represent objects and lists, and is a common text format for Clash configuration. Align fields at the same level and use spaces for indentation. Successful parsing only confirms that the syntax is readable; it does not verify policy group references, field names, or core compatibility. Place copied snippets at the correct level and avoid duplicate top-level keys. See Clash configuration files for the full structure.
proxy-providers
A proxy provider uses proxy-providers to manage a separate proxy list resource, which policy groups can reference through settings such as use. This keeps proxy resource updates separate from local rule management, but the resource must meet the requirements of the core in use; an arbitrary full configuration cannot be used as a proxy provider. Unlike a rule provider, it supplies connection candidates, not matching conditions.
override · merge · patch
Local overrides preserve custom changes alongside subscription content, such as adding rules or changing a listening port, so remote updates do not overwrite manual edits. Clients can differ in how they merge or replace content, insert rules, and run scripts; similar names do not guarantee identical behavior. After making changes, inspect the effective configuration and check that they persist after a restart or subscription update—not just in the editor's source text.
external-controller · management API
The external controller API lets a dashboard or client read core status, switch policies, and manage connections. Its listening address is set with external-controller. This is a management endpoint, not the mixed port used for browser traffic; they cannot replace each other. For local management, prefer the loopback address, enable authentication, and check your firewall. Before exposing the API on a local network, make sure you know which devices can access it.