Configuration fields / concept boundaries / troubleshooting tips

Clash Glossary

Explore 24 common terms in six categories, from client settings to core fields. Start by identifying how traffic enters the client, then see how rules select an outbound, and finally check DNS and subscription settings.

The execution layer and the user interface

Core and client

The client provides the controls; the core handles connections. When troubleshooting, note the names of both rather than relying on the window title alone.

Clash client#
GUI / clientThe client provides an interface for importing subscriptions, choosing proxy groups, viewing logs, and toggling the proxy. The core usually handles the actual connections. Different clients can use the same core, while interface labels and configuration merge behavior may vary. If a field has no effect, check both whether the core supports it and whether the client includes it in the final runtime configuration.
mihomo core#
mihomo / Clash Metamihomo is a proxy core developed from Clash Meta. It handles protocol connections, rule matching, DNS, and TUN features. Seeing Clash in a client's interface does not mean it runs the same core as another client. Check the documentation for the core actually running and its startup logs for supported protocols, rule syntax, and experimental options.
Proxy node#
proxies / outboundA proxy node usually means an optional remote proxy outbound, with a protocol, server address, port, and authentication details. Installing a client gives you a connection tool; usable nodes must come from a configuration or subscription. A node's display name does not establish its location, bandwidth, or availability. For connection issues, check the actual settings and error logs.
Latency test#
url-test / timeoutLatency is the response time measured against a specified test target and method. It is not download speed, and may not represent network round-trip time alone. Clients may use different test URLs, so results are not always directly comparable. A timeout can mean the test target is unreachable, the node cannot connect, or DNS resolution failed. Check access to a real website and the logs to narrow it down.

Local proxy endpoints and remote transport

Proxy protocols

The proxy endpoint used by a local application and the protocol the client uses to connect to a remote server operate at different layers.

HTTP proxy#
HTTP / CONNECTAn HTTP proxy lets an application send requests to a proxy endpoint. HTTPS connections usually use the CONNECT method to establish a tunnel. Setting a local HTTP proxy address in an app does not mean the remote node also uses HTTP. HTTP proxying does not automatically encrypt all traffic: HTTPS to the destination, transport to the local endpoint, and encryption to the remote node are separate considerations.
SOCKS5#
SOCKS / UDP ASSOCIATESOCKS5 lets an application send a destination address and connection request to a proxy endpoint. It is commonly used in browser, developer tool, and command-line proxy settings. The protocol supports TCP and defines UDP forwarding, but UDP availability also depends on the application, client, and remote route. Check the specific app's settings to see whether domain names are resolved locally or by the proxy.
Shadowsocks#
type: ssShadowsocks is a remote proxy protocol. Its configuration must match the server's encryption method and authentication settings. A server address and port alone are usually not enough to establish a working connection; any plugin requirements must also match the server. If the connection fails after import, first confirm that the core supports the method, then check the settings rather than assuming rule mode is at fault.
TLS#
TLS / SNI / servernameTLS protects connections in transit and verifies server identity. It is commonly used as an outer transport for various proxy protocols. SNI provides the server name during the handshake; certificate validation also checks that the name matches and the certificate is trusted. If the handshake fails, check the system clock, server name, and certificate chain. Disabling certificate verification is not a routine fix.

After a connection enters the core

Rules and routing

Rules determine which outbound handles a connection; proxy groups determine which node is currently selected. Check both.

Rule-based routing#
mode: rule / rulesIn rule mode, connections are checked against rules from top to bottom. Usually, the first matching rule determines the outbound. For example, DOMAIN-SUFFIX,example.com,PROXY sends the domain and its subdomains through PROXY. A final MATCH,PROXY rule handles connections that did not match earlier rules. If a broad rule appears too early, more specific rules below it may never take effect.
Proxy group#
proxy-groups / select / url-testA proxy group organizes multiple outbounds under a name that rules can reference. Configure groups under proxy-groups. A select group lets you choose manually; a url-test group selects automatically based on tests against a specified URL. An automatic test does not guarantee the fastest route for every website. When a rule points to a group, check which option is currently selected rather than stopping at the group name.
GeoIP#
GEOIP,CN,DIRECTGeoIP matches destination addresses against an IP geolocation database, often to send addresses in a specific region through a chosen outbound. Unlike GeoSite, it classifies IP addresses rather than domains, and cannot by itself identify a website's operator or content. Matching a domain connection against an IP rule may require DNS resolution first, so the database state, resolved address, and rule order can all affect the result.
Rule set#
rule-providers / RULE-SETA rule set keeps a collection of domains, IP ranges, or complete matching conditions in a separate source. Load it with rule-providers and reference it with a RULE-SET rule. The declared behavior type and file format must match the actual content; a successful download does not mean the main configuration uses the rules. To troubleshoot, check the load logs, reference name, outbound name, and rule order in sequence.

Traffic capture and outbound modes

Network modes

System proxy and TUN control how traffic enters the client; rule and global modes control outbound selection. Enabling one does not replace the other.

System proxy#
system proxy / loopbackSystem proxy settings register a local proxy address with the operating system, so apps that honor the setting send requests to the client's listening port. Some games, command-line tools, and apps with their own network settings may ignore it, so enabling the switch does not mean every connection is captured. If websites stop loading after you quit the client, check whether the system still points to a proxy port that is no longer running.
TUN mode#
tun / auto-route / dns-hijackTUN uses a virtual network interface and routing rules to capture traffic, including traffic from some apps that ignore the system proxy. It usually requires appropriate permissions or a service component. The range of captured traffic also depends on route exclusions, the network environment, and the client implementation. If TUN conflicts with another VPN, check the default route and DNS first instead of repeatedly switching between multiple traffic-capture tools.
Global mode#
mode: global / GLOBALGlobal mode sends connections entering the core through the outbound currently selected under GLOBAL, instead of routing them according to the usual rules. It changes outbound selection; it does not automatically bring apps that bypass the client into the proxy. Global mode can help test whether rules are the issue, but check which option GLOBAL has selected. Switch back to rule mode to check the original match results.
Mixed port#
mixed-port: 7890A mixed port accepts both HTTP and SOCKS proxy requests on the same listening port, configured with mixed-port. 7890 is a common example, not a port every client uses by default. When configuring an app manually, check the active value. Access from other devices on the LAN also depends on the listen address, allow-lan, and firewall settings; changing the port number alone is not enough.

Domains, addresses, and resolution paths

DNS and resolution

DNS resolves addresses; routing rules choose the outbound for connections. Being able to open a website does not prove that its DNS queries took the expected route.

DNS resolution#
dns / nameserverDNS resolves domain names to IP addresses and other records. Apps usually query DNS before connecting to a destination. The operating system, browser, and core may each use separate caches or resolvers, so changing DNS in one place may not affect every app. When troubleshooting, distinguish resolution of the destination domain from resolution of the proxy server's domain and the address lookups needed for the resolver itself to connect.
Fake-IP#
enhanced-mode: fake-ipFake-IP assigns a mapped address to a domain. When an app connects to that address, the core can recover the domain name and use it for routing. A mapped address in the logs is not the website server's actual address and cannot be used to determine a node's location. Some apps rely on real DNS answers and may need exceptions. Add filters for specific domains rather than excluding all domains.
DNS leak#
resolver path / DNS interceptionA DNS leak occurs when DNS queries take a route other than the one you intended—for example, when queries expected to pass through the core are sent to another resolver. A test page may show resolvers using forwarding or anycast, so do not draw conclusions from a name or location alone. Check system DNS, encrypted DNS in the browser, TUN interception settings, and actual logs together. Enabling Fake-IP alone does not prove that every DNS query is controlled.
nameserver-policy#
dns.nameserver-policynameserver-policy selects DNS upstreams based on domain matching rules, allowing different domains to use different resolvers. It determines where DNS queries go; it does not replace rules for selecting the node used by application connections. After changing it, check the matching syntax, resolver connection route, and cached answers. An old cached answer does not necessarily mean the new configuration failed to load.

Configuration sources and the active configuration

Subscriptions and configuration

Subscription updates, local edits, and client overrides can all affect the configuration. When troubleshooting a setting, check the final configuration passed to the core.

Subscription#
subscription / profileSubscriptions distribute proxy node lists or complete configurations through a link. Their contents depend on the provider and how the client imports them. A successful update usually means the content was retrieved, but you still need to confirm that the profile is active, the proxy group exists, and a working outbound is selected. Subscription links often contain access credentials. Hide the link and authentication details when sharing logs or screenshots; do not treat it as an ordinary public URL.
YAML#
config.yaml / indentationYAML is a structured text format commonly used for Clash configuration, with indentation defining the hierarchy of mappings and lists. Use consistent spaces rather than tabs for indentation, and take care when quoting strings that contain special characters. Passing a syntax check only means the file can be parsed; it does not confirm that field names, node references, or core support are correct.
Override#
override / merge / patchAn override keeps local DNS, rules, or other preferences separate from the original subscription content, then merges them through the client to create the runtime configuration. This can preserve settings across subscription updates, but merge order and array handling vary between clients. If rules are duplicated, fields disappear, or ordering changes, inspect the final configuration rather than comparing the subscription and override files separately.
proxy-providers#
proxy-providers / useproxy-providers loads a set of nodes from a source. A proxy group can reference them with use, keeping node updates separate from management of the main configuration. This loads proxy outbounds, unlike rule-providers, which loads matching conditions. Check the source file format, reference name, and update status. A provider declared but not referenced by a usable proxy group may not appear where expected.