Quick Reference / 25 Terms
Key distinctions among terms for cores, connections, rules, and configuration files.
Browse terms by category. English names help you match terms to client interfaces, logs, and YAML fields. Each card has its own anchor, so you can bookmark or share it. Field support depends on the core in use and its version. For setup steps, see Getting Started; for parameter details, see the YAML Handbook.
Kernel / Client
First, distinguish the core that handles network traffic, the client that provides the interface, and the way applications connect to the proxy.
Clash originally referred to a proxy core that processes network traffic according to rules. Today, the name is also commonly used for its configuration format and client ecosystem. The original project and its later forks have different maintainers, and similar names do not guarantee identical features. When following a guide, check which client, core, and configuration era it covers; names alone do not establish compatibility.
Compare client differencesmihomo is an open-source proxy core that continues the Clash Meta project. It handles low-level tasks such as proxy connections, rule matching, and DNS. It is not a GUI, and some GUI clients let you switch cores. To check whether a field is supported, look at the core and version currently running—not just the name of the client installer.
Explore the core configuration structureA GUI client provides interfaces for importing configurations, selecting policies, viewing connections, and reading logs. It turns user actions into core configuration or control requests. A client may also manage the system proxy, background services, and configuration overrides, so an interface setting does not necessarily correspond directly to a YAML field. Even clients using the same core may save configurations in different locations or handle updates differently.
Read the client selection guideAn external controller lets a GUI or control panel read core status, switch policies, and view connections. It is an administrative interface, not a traffic port for browsers or other applications to connect to the proxy. Limit its listening scope and configure authentication to avoid exposing administrative controls to untrusted networks. If the interface cannot connect to the core, check that the controller address and authentication settings match.
Compare common configuration fieldsThe system proxy is an operating-system setting that tells applications which proxy server to use; it does not force all traffic through the proxy. Only applications that respect this setting connect to the specified proxy port. Apps that manage their own network connections may need separate configuration or TUN mode. After enabling it, check that the address and port match the current core. When you close the client, make sure no stale proxy settings remain in the system.
See connection and verification stepsProtocol / Transport
A node is a set of connection parameters; the proxy protocol, transport, and encrypted handshake each govern a different part of the connection.
A proxy node is a set of parameters describing a remote connection target and its authentication method. It typically includes a protocol, server address, port, and credentials. The node name is only for display or policy references; a region in the name does not prove the actual location of the outbound IP. If a connection fails, check all parameters and the remote server status instead of just renaming the node or repeatedly importing the same configuration.
Explore proxy node fieldsA proxy protocol defines how the client and server authenticate, encapsulate, and forward data—for example, Shadowsocks, VMess, VLESS, or Trojan. Protocol and transport are separate concepts, and one protocol can support different transport combinations. The node's type and authentication fields must meet the requirements of that protocol; changing the type name alone does not convert it to another protocol.
A transport describes how a proxy protocol carries data over a connection, such as TCP, WebSocket, or gRPC. Settings such as the path, request headers, and service name must match the server, and not every proxy protocol supports every transport. When migrating a configuration, keeping the server and credentials but omitting the transport settings can still cause handshake failures or request timeouts.
Explore transport settingsTLS encrypts communications and verifies the identity of the other endpoint. Certificate validation and the server name affect the handshake. The connection address and the server name used in the handshake may differ; follow the server's requirements rather than changing them arbitrarily. Disabling certificate verification weakens identity checks and is not a general fix for connection errors. Also check the system clock and the domain names covered by the certificate.
Explore TLS configurationClient latency tests usually measure how long it takes to request a test URL through an outbound proxy. This is not the same as an ICMP ping or download speed. Results depend on the test URL, network path, handshake, and timeout threshold, so numbers from different clients may not be directly comparable. A timeout only means the test did not finish in time; investigate further using logs and actual connection results.
Browse connection troubleshootingPolicy / Rules
Rules determine which policy handles a connection; proxy groups determine the outbound proxy. The mode determines whether traffic is handled by rules.
A proxy group organizes nodes or other groups and selects an outbound proxy according to its type. A manual select group and an automatic url-test group use different selection methods, so the node shown in the interface may not remain selected. Rules can target a group, keeping traffic classification separate from outbound selection; make sure the referenced name matches its definition.
Rule-based routing selects how to handle a connection based on conditions such as its domain, destination IP, or process. Rules are usually checked from top to bottom, and the first match takes effect. Put specific rules in the right place, and keep fallback rules such as MATCH near the end. To troubleshoot routing, check the rule that actually matched and the resulting policy rather than inferring from the website name.
The mode determines whether the core uses rules, a global policy, or direct connections as its basic handling method. Rule mode selects a policy based on rules; global mode applies the global policy, while direct mode connects directly by default. Global mode does not mean all application traffic is being routed through the core; that still depends on the system proxy, app settings, or TUN routes.
See how to choose a modeGeoIP data maps IP addresses to categories such as countries or regions for matching IP-based rules. Database updates, IP allocations, and content delivery networks can all affect results, so GeoIP cannot reliably identify where a website is based. Domain rules and GeoIP rules may classify the same traffic differently. Check rule order, the resolved IP, and the database source to understand why a rule matched.
Compare IP-based rulesA rule set groups matching conditions for centralized management. Define its source with rule-providers, then reference it in a RULE-SET rule. Rule sets are different from node subscriptions, so their URLs are not interchangeable; their content, format, and matching behavior must match the configuration that declares them. Referencing a rule set does not bypass sequential matching: earlier matching rules still take priority.
DNS / Network Stack
Check the DNS resolution path and traffic path separately. Enabling a setting does not mean every application uses the same path.
DNS resolution converts domain names into records such as IP addresses, affecting connection targets and some rule matches. The core, applications, and operating system may each perform DNS lookups, so first identify which path handles a given request. Changing DNS servers does not necessarily change the outbound route. Clearing one cache also does not guarantee that the application, system, and core caches have all been updated.
Explore DNS fieldsFake-IP mode returns a virtual IP mapped to a domain name. The core uses that mapping to recover the domain and handle the connection. The virtual address is not the remote server's real IP, so the system's DNS result alone cannot show where the connection ultimately goes. Some applications that rely on real DNS results may need exception rules. After switching resolution modes, also account for app caches and existing connections that may still use the old address.
Read about DNS resolution modesA DNS leak usually means domain lookups bypass the expected resolution path and are exposed to an unintended DNS resolver or local network. Consider application, system, IPv6, and core settings when investigating; the outbound IP alone is not enough to determine whether a leak occurred. The location of a resolver shown by a test page is only a clue. Also check browser encrypted DNS, system fallback behavior, and how the proxy server resolves domain names.
Check which settings affect DNS resolutionTUN mode uses a virtual network interface and routing rules to pass IP traffic to the core, including traffic from some applications that ignore the system proxy. What gets routed depends on routes, permissions, exclusions, and interactions with other networking software. If enabling TUN breaks your connection, check the virtual interface, default route, and DNS routing. Avoid changing several settings at once so you can narrow down the cause.
Explore TUN settingsSniffing looks for domain clues in the initial connection data, such as the server name in a TLS handshake, to help match rules. It does not decrypt encrypted payloads, and what it can extract depends on the protocol and handshake encryption. Enabling sniffing does not guarantee that every connection will yield a domain. Check connection details to confirm what was detected, and consider exceptions for specific traffic.
Explore network-related fieldsSubscription / Configuration
Distinguish the remote source, text format, client profile, and final runtime configuration to identify where a change takes effect.
A subscription is typically a URL-based mechanism for retrieving and periodically updating nodes or configuration. Different sources may return a complete YAML file, a set of nodes, or encoded node links. Subscription URLs may contain credentials, so don't share them publicly or paste them into public logs. Before importing, check that the client supports the format. Successfully retrieving content does not guarantee that every node will connect.
See how to import a subscriptionYAML is a text format for representing data such as mappings, lists, and scalars. Clash uses it to organize configuration fields. Use spaces for indentation and keep indentation consistent at each level; quote text containing special characters where required by the syntax. Valid syntax only means the text can be parsed—it does not guarantee that field names, data types, or references between nodes and proxy groups meet the core's requirements.
Explore the YAML structureA configuration profile is a local or remote configuration entry managed by a client, allowing you to switch between configurations. The editor content, the client's merged result, and the configuration loaded by the core may differ; saving a file does not necessarily trigger a reload. To check whether a change took effect, review the active profile, runtime logs, and the client's final configuration view.
See how to activate a configurationA proxy provider uses proxy-providers to load a separate set of nodes for proxy groups to reference, keeping node updates separate from local rules. This is a configuration mechanism, not the same as an organization that provides network services. Provider files use a different structure from complete configurations; don't assume a subscription containing top-level DNS and rule fields can be used as a node list as-is.
A configuration override adds, replaces, or merges local settings on top of a base configuration, usually before the client loads it. This can preserve separate DNS or rule changes. Clients may handle lists, fields with the same name, and execution order differently, so don't assume every setting will be preserved. Check the final configuration after making changes, and keep overrides separate before updating a subscription.
Read about overrides and merging