Glossary / Configuration Reference
First distinguish how traffic reaches the core, then see how rules select an outbound. Browse terms by category and map configuration fields to settings in your client.
Cores and Clients
A client that can import a configuration does not necessarily mean its core supports every field in it. Before troubleshooting, identify the client, the core actually in use, and how traffic reaches that core.
Think of the client as the control panel: importing subscriptions, switching policies, viewing logs, and enabling the system proxy usually happen in its interface. The core handles configuration parsing and connection forwarding, so the same core can work with different clients. When following a tutorial to find a setting, check the client’s name first. A different layout does not necessarily mean the feature is missing.
Think of mihomo as the engine that handles network connections: it reads configuration, resolves DNS, matches rules, and establishes direct or proxy connections. It continues the Clash Meta project’s technical lineage and can run through a graphical client or on its own. If a field is unsupported or a protocol is unrecognized, check which core is actually running—not just the client’s release date.
In older documentation, Clash Meta usually refers to a core in the Clash ecosystem, with a historical name associated with today’s mihomo. Some clients, subscription types, and tutorials still use the Meta label; that does not mean they are the same application. When reading an older configuration, check the current core’s documentation to confirm what each field means, especially for differences in DNS, TUN, and newer protocol settings.
Enabling the system proxy points the operating system’s proxy settings to the local address and port the client listens on. Browsers and apps that honor these settings will send their connections through it, but standalone network tools, some terminal apps, and games may not. If the browser works but another app does not, check whether that app supports proxy settings before considering TUN mode.
Treat latency as the time taken by a particular test, not a proxy speed rating. The test address, connection method, timeout, and network congestion all affect the result, so numbers from different clients may not be directly comparable. Low latency can still come with low bandwidth or packet loss. Check connections to the sites you use, sustained transfers, and stability to assess real-world performance.
Proxy Protocols
The protocol name is only one part of a connection configuration. Authentication, transport, TLS, and server settings must all match; a proxy’s display name alone cannot confirm compatibility.
This proxy protocol establishes connections using an encryption method and authentication details. Common settings include a server address, port, encryption method, and password. The client and server must support the same method—the protocol name alone is not enough. If a subscription imports but connections fail, check that all methods and parameters are correct, and confirm that the active core supports any extensions used by the configuration.
This proxy protocol uses a user ID and other parameters for authentication. Connections may also use transport settings such as WebSocket, gRPC, and TLS. Even with the right user ID, a mismatched path or hostname can prevent a connection. If one proxy stops working after a subscription conversion, check that these related fields were preserved rather than comparing only the server address.
This lightweight proxy protocol is typically deployed with TLS or REALITY for transport protection. The user ID, transport settings, and any flow field in the configuration must match the server. Do not switch it to VMess just because both protocols use a user ID. For compatibility issues, check the full set of parameters and whether the core supports them.
This proxy protocol typically uses TLS for transport and a password for authentication. The certificate and server name also matter. Even with the correct address and password, an incorrect device clock, expired certificate, or mismatched server name can cause a connection to fail. For TLS errors, check the clock and server name first; do not bypass certificate verification to hide the problem.
This QUIC-based proxy protocol relies on UDP, so whether the network allows the necessary UDP traffic directly affects availability. Its configuration should not be assumed to be interchangeable with earlier Hysteria configurations; check the protocol type and authentication fields when importing it. If it works on one network but times out on another, check UDP restrictions and bandwidth settings as well as the server.
Routing Rules
First confirm that the connection is being captured, then check which rule it matched. In the syntax below, PROXY is an example policy name; it must exist in your actual configuration.
In rule mode, the core checks connections against the configuration in order. The first matching rule usually determines the outbound. Rules can distinguish traffic by domain, destination IP, or other conditions, but cannot capture requests that never reached the core. Before changing routing, check the matched rule in the connection details and update that entry. Do not rely on whether a website loads to decide if a rule is working.
Use this rule to match a domain and its subdomains. For example, DOMAIN-SUFFIX,github.com,PROXY matches the domain and its subdomains. It matches the domain suffix, not the full URL or a page path. When adding a rule, omit the scheme and slash, and place it before broader rules that could match first.
Use an IP geolocation database to determine the region associated with a destination address. For example, GEOIP,CN,DIRECT sends addresses associated with that region through a direct connection. Database results do not show where a website operator is based; content delivery networks and database updates can also affect the result. These rules may depend on DNS resolution. If a domain uses different outbounds at different times, check the resolved address, database, and rule order.
Put this at the end of the rule list to handle connections that did not match earlier entries, for example MATCH,PROXY. It has no domain or IP condition, so if it appears too early, later rules usually will not be checked. Choose the fallback policy for your needs. Setting it to a proxy does not reroute connections already matched by a direct rule.
A proxy group puts multiple proxies or other policies into a named collection that rules can reference instead of tying them to a single server. Common types include manual selection, automatic testing, and failover, each with different switching behavior. If a rule matches the right group but traffic uses the wrong outbound, check the group’s current selection and nesting rather than adding the same rule again.
DNS and Networking
How a domain resolves to an address and how the subsequent connection leaves your device are related but distinct. When troubleshooting, record the resolver, the resolved address, and the connection’s outbound separately.
DNS resolves domain names to IP addresses and other records. Apps usually get a resolution result before connecting to the destination. The operating system, browser, and core may all handle DNS, so changing DNS in the client may not affect every app. If a domain will not load, first check which resolver handled the request, then distinguish a resolution failure from a connection failure after an address was returned.
With this DNS mode enabled, the core returns synthetic addresses to apps and maintains a mapping between each address and its original domain. When subsequent traffic returns to the core, it can use that mapping to identify the domain and process the connection according to the configuration. A synthetic address is not a proxy server address. Some apps require real DNS results; if compatibility issues arise, check the filter list rather than immediately rewriting the entire DNS configuration.
A virtual network interface and routing configuration send eligible IP traffic to the core, which can help with apps that do not follow the system proxy. Enabling TUN usually requires system privileges and may conflict with other VPNs, virtual adapters, or routing settings. TUN changes how traffic reaches the core; the active mode and rules still determine the outbound. It does not mean every connection goes through a proxy.
A DNS leak occurs when queries expected to follow a specified resolution path take another route and expose query information. A test page showing a particular provider or region does not, by itself, prove a leak: the resolver’s location and the connection’s outbound can differ. First decide which requests should use which path, then check whether browser secure DNS, system resolution, and core settings agree.
In client configuration, this usually means redirecting eligible DNS requests to the core’s DNS module, not a network attack. dns-hijack in a TUN configuration can capture these requests, but coverage depends on the platform, routes, and request method. Encrypted DNS used directly by an app may not be captured the same way. Check the app’s settings and connection records to find out.
Subscriptions and Configuration Files
A file downloading successfully does not mean it can run as-is. First check whether the subscription provides a proxy collection or a complete configuration, then verify its fields, references, and update method.
A subscription is a remote source for retrieving and updating proxies or a complete configuration, not a specific file format. Its response might be YAML, a Base64-encoded proxy list, or multiple URIs; direct import depends on client support. Subscription URLs often contain access credentials, so treat them like account details. When troubleshooting, do not share the full URL in public logs, screenshots, or online conversion tools.
A proxy is a set of parameters needed to connect to a proxy server, usually including the protocol, server address, port, authentication details, and transport settings. Display names are mainly for identification; they do not confirm a server’s actual location, connection quality, or bandwidth. If a proxy fails, test other proxies in the same configuration first to determine whether the issue is with that proxy’s settings, local traffic capture, or the underlying network.
This structured text format is commonly used for Clash configuration. It represents hierarchy with space indentation and organizes data with lists and key-value pairs. Keep indentation consistent, avoid tabs, and watch for spaces after colons and special characters. Valid YAML syntax only means the file can be parsed; the core still needs to check whether fields are valid and referenced policy names exist.
Use this configuration field to manage a proxy collection separately from the main configuration, so the core can load or update proxies from a specified source. The collection is a proxy source that can be referenced; it usually needs to be linked from a proxy group using fields such as use. If the download succeeds but no proxies appear in the group, check the reference name, content format, and filters. Do not run a proxy collection file as a complete configuration.
Use this to declare an external rule collection, then reference it in the rule list with RULE-SET to manage and update large sets of domain or address rules separately. The collection’s content type and format must match its declaration, and the reference must specify a valid policy. Even a valid rule collection may not take effect if its reference appears too late. Check update logs and the order of the main rules as well.