CLASH / CONFIGURATION GLOSSARY
Cores, rules, DNS, and ports. Find a term by configuration area, then compare it with the value actually in use.
This page covers 24 commonly used terms, each with a direct link you can copy to share its explanation. For your first setup, start with the getting started guide. If you already have an error, use the troubleshooting guide to diagnose it by symptom.
First distinguish the core handling connections from the user interface and connection settings.
mihomo is a proxy core in the Clash ecosystem. It parses configuration, matches rules, handles DNS, and forwards connections. The core is not a graphical interface; to determine whether a configuration works, check which core is actually running and which fields it supports. Clients with the same name may use cores with different capabilities across platforms or installations.
mode: rule
A graphical client provides subscription management, policy selection, logs, and a system proxy toggle. UI settings may generate or override the core configuration. When troubleshooting, inspect the configuration in effect, not just the imported original file. When choosing a client, check its platform and architecture first, then confirm where to find the features you need. See the client comparison.
A proxy node is a set of parameters for connecting to a remote server, typically including its address, port, protocol, and authentication details. Seeing a node in the list only means the configuration was recognized; whether it connects depends on the parameters, network, and server status. A node name is just a label—it does not confirm the exit location or protocol.
proxies:
Clients often measure response time by connecting through a node to a specified test endpoint; this is not the same as an ICMP ping. Results depend on the endpoint, handshake, and network path, so they do not directly indicate download speed or whether every site is reachable. If a test times out, first check that the endpoint is reachable, then use the troubleshooting guide to check your local network and node connection.
type: url-test
The protocol determines the parameter structure; transport and authentication fields must also match.
Shadowsocks is an encrypted proxy protocol. Its configuration must match the server address, port, encryption method, and password. If a connection fails after importing a subscription, check the encryption method and any required plugins first; fields for other protocols are not interchangeable. UDP forwarding also depends on the node configuration and server support; the SS name alone does not guarantee it.
type: ss
VMess is a proxy protocol that requires matching client and server settings. UUID is a commonly used identity field. With WebSocket or TLS, also check the transport path, hostname, and certificate settings—a correct UUID alone does not guarantee a connection. If the logs show an authentication or handshake error, verify the system clock before checking the transport parameters further.
type: vmess
VLESS is a lightweight proxy protocol and does not provide transport encryption equivalent to TLS on its own. Whether to use TLS or REALITY, and whether to set flow, depends on the server configuration. You cannot convert a node by simply changing its protocol name. Before importing, check that your core supports the required combination to avoid mistaking incompatible fields for a server problem.
type: vless
Trojan typically carries proxy traffic over TLS and uses password authentication. In addition to the address and password, check the server name and certificate verification results. Disabling certificate verification should not be the default fix. If the server uses another transport, such as WebSocket, the client must include the matching parameters; a server port alone is not enough.
type: trojan
Rules decide how a connection is handled; proxy groups determine which connection path to use.
In rule mode, connections are matched against the `rules` list from top to bottom. The first match is handled by its specified policy. Put specific conditions before broad ones, then check the matched rule in the connection log to confirm your changes took effect. A final MATCH rule commonly handles connections that did not match earlier rules. In global mode, routing does not follow the behavior of rule mode.
DOMAIN-SUFFIX,example.com,DIRECT
A proxy group combines nodes or other policies under a name that rules can reference. `select` lets you choose manually; `url-test` selects based on test results. Changing a group selection does not change rule order, and it does not mean every app will use that group. If changing nodes does not change your exit IP, first check which group the connection matched, then confirm you changed an active option in that group.
proxy-groups:
DIRECT sends a connection straight to its destination without a proxy node; REJECT blocks matching connections. Both are built-in policies. PROXY is often used as the name of a custom proxy group, so make sure that name actually exists in the configuration before using it. Direct connections may still follow local routing settings, and check the matched rule to see whether a connection was blocked by mistake.
DOMAIN-SUFFIX,example.com,REJECT
GeoIP matches destination addresses against geographic data in an IP database; the result does not establish the origin of the content or the location of its operator. CDNs and changing IP addresses can affect results. `no-resolve` in a rule prevents that rule from triggering a DNS lookup. For reliable matching against a known set of domains, use domain rules rather than relying only on IP location.
GEOIP,CN,DIRECT,no-resolve
Check how a domain is resolved first, then how traffic reaches the core.
DNS resolution maps a domain name to an address needed for a connection. The DNS lookup path and the connection path are separate. Even with core DNS enabled, confirm that app requests actually use it; browser Secure DNS or system settings may route queries elsewhere. If a domain fails to open but its IP address works, check the DNS response, cache, and resolver in use.
dns:
Fake-IP returns a synthetic address for a DNS request and keeps a domain-to-address mapping in the core, allowing later connections to be handled by domain. For app compatibility issues, check `fake-ip-filter`. After switching modes, clear stale DNS cache and reconnect. A synthetic address in the DNS response is not necessarily an error; what matters is whether subsequent traffic reaches the core holding the mapping.
enhanced-mode: fake-ip
TUN receives IP traffic through a virtual network interface and can cover apps that ignore system proxy settings. It depends on permissions, routing, and DNS working together; enabling it does not guarantee that all traffic is captured. First check that the virtual interface and routes were created. Other VPNs running at the same time can cause route conflicts; disable them one at a time to narrow down the issue.
auto-route: true
A DNS leak occurs when domain queries take an unexpected path and reach a resolver you did not intend to use. Check system, browser, and client settings, and distinguish the source of the query from the recursive resolver. A location label alone is not enough to draw a conclusion. Encrypted DNS only means that the relevant query link is encrypted; it does not prove the query went through the intended proxy.
Distinguish the configuration source, file structure, and independently updated resources.
A subscription URL is a remote address used to fetch a node list or full configuration; it is not the client app itself. If an update fails, check the response content and supported format first. URLs may contain credentials, so redact them from logs and screenshots. If the response is a web page, login prompt, or error, changing the file extension will not turn it into a usable YAML configuration.
View subscription setup stepsYAML uses indentation to represent data structure; Clash configurations are commonly saved as `config.yaml`. Use spaces, not tabs, and keep indentation consistent at each level. Passing a syntax check only confirms valid structure—the core determines whether the fields are supported. Also check the indentation of the parent level near an error; fixing only the reported line may leave the structural problem in place.
config.yaml
A Proxy Provider is a set of nodes that can be loaded and updated independently, then referenced by a proxy group. After loading the resource, connect it to a group using settings such as `use`. Defining a provider without referencing it does not create a complete routing setup. If a node list is empty, check resource retrieval, content parsing, and proxy group references separately.
proxy-providers:
A Rule Provider stores a set of matching conditions separately, then uses RULE-SET to direct matches to a policy. The resource format must match the `behavior` and `format` settings. Where the rule set is referenced still determines its position in top-to-bottom rule matching. Updating a rule resource does not change the proxy group; the rule that references the set still determines the policy used for matches.
rule-providers:
Check local listeners, app settings, and LAN access separately.
A system proxy writes proxy details to operating system settings for apps that honor them. It does not capture all traffic. If a browser works but another app does not, first check whether that app uses the system proxy rather than switching nodes immediately. If network access still fails after closing the client, check whether the system proxy settings still point to a port that is no longer listening.
`mixed-port` lets one local port accept both HTTP proxy and SOCKS requests. Apps must use the address and port the core is actually listening on. If the port is already in use, the listener will fail; example values in a configuration do not guarantee the client uses that port. The 7890 below is only an example—check the client settings and startup logs for the actual value.
mixed-port: 7890
Both 127.0.0.1 and IPv6's ::1 point to the local device and are commonly used by apps to connect to a local proxy. Some Windows UWP apps are restricted from using loopback by their sandbox; check loopback exemptions for each app. Enabling LAN access does not grant this permission. On another device, 127.0.0.1 points to that device, not the computer running Clash.
127.0.0.1 / ::1
`allow-lan` controls whether other devices can access the core's proxy listener; the listening address and firewall must also allow it. Enable it only when needed on a trusted network, and restrict access. Proxy ports and the controller interface serve different purposes; do not expose both to the public internet. Other devices must use the LAN address of the device running the client, and the devices must be able to reach each other.
allow-lan: true