# glossary
Understand the concepts before changing your config. Browse 24 terms by setting category to see how traffic enters mihomo, matches rules, and is affected by subscription updates.
For step-by-step instructions, see the Getting Started guide. For OS-specific help, see the cross-platform setup guide. This page covers general concepts; supported fields depend on the core and client you're using.
# Category 01 · core-clients
The UI provides controls; the core handles connections. First identify which component is running, then decide where to change a setting.
core: mihomo
mihomo is the name of the core used by the original Clash.Meta project. It handles proxy protocol connections, DNS, and rule matching; a graphical UI is just the control layer for these capabilities. Different clients may bundle different core versions, so updating the UI doesn't necessarily update the core. If a field is unrecognized or a protocol is unsupported, check the core version actually running and its startup logs—not just the app's name.
GUI / profile / settings
A client is an app for importing subscriptions, selecting proxies, viewing connections, and configuring traffic handling. It may bundle a core or manage a separate core process. Settings such as the system proxy toggle and launch at startup are often stored locally in the client, not in the subscription file. When switching clients, importing the same subscription won't transfer these local settings; check permissions and traffic handling again.
external-controller
The external controller is a management interface the core provides to a UI or dashboard. It can read connections, view logs, and change policy group selections. It's not the same as the port apps use to send proxy requests; pointing a browser proxy at the controller port won't provide normal proxy service. Keep access local and enable authentication. If remote management is necessary, set up separate access controls—never expose it directly to the public internet.
mixed-port
A mixed port accepts both HTTP proxy and SOCKS connections on the same listener, letting apps connect using whichever protocol they support. A common config is mixed-port: 7890, but use the port set by your client rather than copying this value blindly. Having a listening port doesn't mean traffic is being captured: check that apps use it and that the bind address, LAN access permissions, and firewall allow the connection.
# Category 02 · proxy-protocols
The protocol determines how a client connects to a server. The same proxy label doesn't mean its authentication, transport, and security settings are interchangeable.
proxies
A proxy is a set of connection parameters for an outbound, usually including a server address, port, protocol, and authentication details. It may also specify TLS, transport, and UDP support. A proxy name is just a label; it can't establish the endpoint's actual location or availability. Test access to the destination after selecting a proxy. Proxies on the same server may behave differently due to different ports or transport settings.
type: ss
Shadowsocks establishes a proxy connection using an encryption method and credentials agreed on by both sides. In config, it's usually specified as type: ss. The client and server must use matching encryption methods, passwords, and plugin settings; a correct server address alone isn't enough. Core support for methods and plugins can vary. If importing fails, check these fields first rather than trying to fix it by switching rule modes.
type: vmess
VMess is a proxy protocol authenticated with parameters such as a user ID, and it can use transports such as WebSocket, with TLS enabled as required by the server. The authentication, transport path, hostname, and TLS settings must all match as a set; the protocol name is only one part of the config. If the connection fails, check that the device clock is accurate too. Changing DNS alone usually won't fix mismatched authentication or transport settings.
type: vless
VLESS is a lightweight protocol for proxy authentication and data encapsulation, often used with security layers such as TLS or REALITY. The protocol name alone doesn't mean the connection is encrypted. The user ID, transport, server name, and security settings in the config must match the server. If the core reports unsupported fields after import, check the core's capabilities and the config format rather than removing security settings just to make the config load.
type: trojan
Trojan typically carries proxy traffic over TLS and uses password authentication; its config may also include additional transport settings. The server connection address and the server name used for TLS are different things. A reachable address doesn't guarantee certificate validation will pass. For certificate errors, check the hostname, device clock, and server certificate first; disabling certificate validation shouldn't be a routine troubleshooting step.
# Category 03 · rules-routing
Rules match destinations; policy groups provide outbounds. When reviewing a connection, check both the matched rule and the proxy ultimately used.
mode: rule / global / direct
Rule mode selects an outbound based on the configured rules, Global mode uses the global policy, and Direct mode generally bypasses remote proxy outbounds, though core settings such as DNS may still apply. These modes only determine how traffic already inside the core is handled; they don't route every app's traffic into it. Rule mode is usually a good starting point. Temporarily switching to Global can help distinguish a rule issue from a proxy issue, but it doesn't replace checking traffic capture.
proxy-groups
A policy group combines multiple proxies or other policies into an outbound that rules can reference. Once a rule points to a group, the group type and current state determine the proxy ultimately used. select is for manual selection, url-test selects automatically based on test results, and fallback usually tries available options in order. An automatic group doesn't guarantee the fastest route for every site; the test target may differ from the destination you're accessing.
rules / MATCH
The regular rules list is checked from top to bottom. The policy for the first match is used, and later rules won't select a different outbound for the same connection. A broad rule placed too early can shadow more specific rules, so custom rule placement matters as much as rule content. MATCH is usually the final fallback. After editing rules, start a new connection and check its match log; existing long-lived connections may not switch outbounds immediately.
GEOIP / GEOSITE
GeoIP classifies IP addresses using an IP database, while GeoSite classifies sites using domain lists. They match different targets and rely on different data. IP-based rules may need to resolve a domain first; behavior also depends on rule parameters and core settings. Domain classification and IP geolocation aren't the same thing. Databases can lag behind, so if traffic is routed incorrectly, check the actual destination and matched rule, then correct it with a more specific rule.
rule-providers / RULE-SET
Rule providers manage external rule collections through rule-providers, which are referenced in the main rules list with RULE-SET. This makes it easier to maintain rules for different services separately. The behavior type, file format, and contents must all match; a successful download doesn't guarantee the rules will load correctly. If routing for a service suddenly changes, check the rule set's update time, load logs, and reference in the config—not just whether the proxy is online.
# Category 04 · dns-network
DNS resolution, traffic capture, and connection routing are separate concerns. After enabling a setting, check routes and the app's own network behavior too.
DNS query path
A DNS leak occurs when domain queries bypass the expected resolution path and go to a resolver you didn't intend to use. It describes where queries are sent, not simply whether a webpage loads. System DNS, browser Secure DNS, and built-in app resolvers can all affect the result; enabling TUN doesn't replace testing each one. Check query records, core DNS logs, and traffic capture scope. A test page showing a resolver's name alone isn't conclusive.
enhanced-mode: fake-ip
Fake-IP mode returns virtual addresses to apps while the core keeps a mapping between each virtual address and its domain. When the connection reaches the core, it uses the domain for routing and subsequent access. Seeing a virtual address doesn't mean DNS is misconfigured, and it isn't the destination server's real address for connectivity tests. Some LAN or address-validation apps may need exceptions. Identify the specific domain first and consider a narrow filter rather than broadening exceptions.
tun: enable
TUN receives IP packets through a virtual network interface and can capture traffic from some apps that ignore system proxy settings. It usually requires administrator privileges or system VPN authorization. The actual capture scope still depends on routes, exclusions, DNS, and the client implementation; an enabled toggle doesn't mean all traffic is captured. After enabling it, test the target app, LAN access, and DNS separately. If conflicts arise, check for other VPNs and virtual network adapter software first.
system proxy → local listener
System proxy settings point the operating system to the client's local listener address and port. Apps that follow these settings pass their requests to the core. Some games, command-line tools, and apps with their own network stack may ignore the system proxy, so a working browser doesn't mean other apps are covered. If the network behaves unexpectedly after closing or uninstalling the client, check for a leftover proxy address in the system settings. To test a first connection, follow the system proxy setup steps.
nameserver / DoH / DoT
A DNS upstream is the resolver the client uses for domain queries. It can use traditional DNS, DNS over HTTPS, or DNS over TLS. Whether the query transport is encrypted and whether queries go through a direct or proxy outbound are separate questions; choosing DoH doesn't automatically route DNS traffic through a proxy. If the upstream is specified by domain name, its initial resolution matters too. Check how the core resolves it to avoid a circular dependency that prevents initial resolution.
# Category 05 · subscription-config
First identify what the subscription provides, then decide where to make changes. Updating proxies, updating rules, and upgrading the client are separate operations.
subscription / profile
A subscription distributes and updates proxies or full configs through a link. It's not a proxy protocol, and not every client can necessarily read the same content. Some links return full Clash YAML; others contain only a proxy list or a different format. Check the provider's stated compatibility before importing. Subscription links may contain access credentials; don't share them in screenshots, logs, or online conversion tools. See how to import a subscription link.
config.yaml
YAML is a text format that uses indentation to express hierarchy. Clash configs use it to organize proxies, policy groups, rules, DNS, and other settings. Use spaces, not tabs, for indentation. Keep fields at the same level aligned, quote values containing special characters correctly, and place new list items at the right level. Valid syntax doesn't mean the current core supports every field; after saving, check the load logs and the config that actually took effect.
proxy-providers / use
Proxy providers manage external proxy collections through proxy-providers, which policy groups reference with use. This keeps proxy sources separate from local rules. Unlike a full subscription config, a proxy collection alone doesn't include usable policy groups, rules, or DNS settings. After adding a provider, check its fetch status, content format, and group reference. A successful download doesn't guarantee the proxies will appear in the intended policy group.
delay / test URL / timeout
A latency test typically measures how long the client takes to reach a specified test URL through a proxy. Results depend on the test target, server load, and current network path. A lower number doesn't mean higher download bandwidth, and a timeout may mean only that the test URL is unreachable—not that every service is unavailable. Compare test results with access to your actual destinations, then check the connection panel to confirm the expected outbound is in use. See proxy speed tests and verification.
update / override / merge
A subscription update fetches remote content again, while a config override typically merges or changes selected fields when the config loads. They solve different problems: refreshing content and making local customizations. Editing a downloaded subscription file directly may not survive the next update. With overrides, check whether the client appends a list, merges an object, or replaces it entirely. Merge order varies by client. Keep a record of local changes before updating, then check that the final rules and policy group references still work.