MIHOMO / GLOSSARY
Look up client settings and YAML fields. Start by distinguishing the core, nodes, and proxy groups, then see how requests pass through rules, DNS, and routing.
These terms explain what applies the configuration, how it is organized, and how remote content reaches the client.
Mihomo is a proxy core formerly known as Clash Meta. It handles protocol connections, rule matching, DNS, and traffic forwarding. A GUI client is a separate application that manages configuration and provides controls. When troubleshooting compatibility, check both the client version and the version of the core actually running—not just the app's name.
Read about the core and clients →YAML is Mihomo's configuration format. It uses indentation to define hierarchy and key-value pairs and lists to organize fields. Use spaces for indentation, and make sure booleans, numbers, and strings match the requirements of each field. If parsing fails after an edit, first check indentation, colons, and quotes near the reported line. Valid YAML syntax does not guarantee that a combination of fields is valid.
Learn about configuration file management →A subscription URL lets a client fetch a list of nodes or a complete configuration. The response format determines how to import it. Some URLs provide nodes only; others include proxy groups, rules, and DNS settings, so you can't tell what's included from the URL alone. Refreshing a subscription fetches its remote content again; it is not a general fix for a broken node. URLs may also contain access credentials, so keep them out of public screenshots and logs.
Learn how to import and update subscriptions →Proxy providers are defined with proxy-providers and can load a set of nodes from a local file or remote URL. Proxy groups reference providers with use, keeping node sources separate from routing rules. After a provider updates successfully, make sure a proxy group actually references it. Defining a provider alone won't change the outbound used by existing rules.
The protocol determines how the client connects to the server. Its name alone says nothing about connection quality and does not replace the required authentication and transport settings.
A node is a set of parameters describing a proxy connection. It typically includes the protocol, server address, port, and authentication details; some protocols also require transport and TLS settings. The node name is just a label used in the interface and configuration—it does not prove the actual exit location. If a node fails to connect, check the logs for authentication, DNS, and server reachability issues instead of just renaming it.
Shadowsocks establishes proxy connections using a specified cipher and password. In Mihomo, its node type is type: ss. The client and server must use compatible ciphers, and some configurations also require plugin settings. Shadowsocks can carry UDP traffic, but actual support depends on both endpoints, node settings, and the network in between—not just the protocol name.
VLESS uses a UUID for authentication and does not provide content encryption on its own. It is often combined with mechanisms such as TLS or REALITY. Connections may also require matching transport, server name, and flow-control settings. A server address and UUID are usually not enough to recreate a complete node, so retain the other fields provided when importing it.
Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. A correct password does not guarantee a successful connection: certificate validity, server name, and transport settings also affect the handshake. If you see a certificate error, first check the system clock and node settings. Disabling certificate verification weakens authentication and should not be a permanent fix.
Hysteria2 is a QUIC-based proxy protocol that relies on an underlying UDP connection. Bandwidth settings are used for congestion control and do not guarantee the same real-world speed. If the current network blocks UDP, web traffic may fail because the underlying proxy connection cannot be established—even if the web traffic itself uses TCP. Check network restrictions and server status.
TUIC is a QUIC-based proxy protocol that can carry TCP and UDP traffic. Authentication, protocol version, and congestion control settings must be compatible with the server; do not assume settings for another QUIC protocol will work. When testing, distinguish a failed underlying handshake from a failure to forward a particular type of traffic. For handshake failures, check UDP reachability first; for forwarding failures, also check rules and forwarding settings.
WireGuard is a UDP-based tunnel protocol that identifies peers using public and private keys. Mihomo can configure it as an outbound. Settings such as the address, public key, endpoint, and MTU affect connectivity and data transfer; the private key is sensitive. Adding WireGuard as an outbound does not send all system traffic through the tunnel. Actual traffic flow still depends on traffic capture and routing rules.
First check which rule a request matched, then see which proxy group the rule points to, and finally check which node is selected in that group.
In rule mode, routing rules select a handling target for each request according to their order. A target can be a proxy group, a specific proxy, or a built-in option such as DIRECT. The first matching rule typically determines where traffic goes. If a site uses the wrong outbound, check the match log and adjust rule order instead of repeatedly switching nodes in the list.
Proxy groups organize multiple nodes or other proxy groups into a reusable target, defined with proxy-groups. Common types include manual selection, automatic testing, and failover, each with its own way of choosing an outbound. After a rule matches a group, the final node depends on the group's current state. The rule's target name and the selected node name may therefore differ.
GEOIP matches the destination IP based on its location in a geolocation database—not the webpage's language or the website company's registered location. Database updates may lag, and CDNs or shared infrastructure can produce results that seem counterintuitive. Domain requests may also require DNS resolution before this rule can match. The no-resolve option affects whether resolution is triggered for matching.
DOMAIN-SUFFIX matches a specified domain and its subdomains. For example, a rule for example.com can also match its subdomains. It does not match arbitrary strings that merely contain the text, unlike DOMAIN-KEYWORD. The core must also have the relevant domain information for the rule to apply; don't assume it will match when a connection uses an IP address directly or has no associated domain.
MATCH catches requests that did not match earlier rules and is usually placed at the end of the rule list. Its target—such as a proxy group or another handling option—determines where unmatched connections go; it does not automatically mean all traffic is proxied. If placed too early, it can prevent later rules from matching, so check its position when adding rules.
DNS resolution, traffic capture, and outbound selection are separate steps. Changing one field does not automatically replace the configuration for the others.
TUN mode receives IP packets through a virtual network interface and lets the core process their connections. It can capture traffic from some apps that ignore system proxy settings. The actual scope depends on system routes, process exclusions, permissions, and the client implementation. If enabling TUN breaks connectivity, check for routing or DNS loops instead of treating TUN as a simple switch for proxying more traffic.
Learn about TUN and routing settings →Fake-IP is a DNS mode that associates domains with connection requests using mapped addresses. The address an app receives may not be the website's real server address. The core uses the mapping to retain domain information and apply rules to subsequent connections. Some apps that require real IP addresses may need to be added to the filter configuration. A mapped address alone does not mean DNS failed—check the connection result.
Learn about Fake-IP and filter settings →redir-host returns the resolved IP address to the application instead of a Fake-IP mapping, making it suitable for cases that require a real address. It still needs correctly configured upstream DNS and relies on the core being able to associate connections with domains. Switching modes can change caching and app behavior. For a fair comparison, keep other settings the same and account for existing connections and DNS caches.
Learn how to choose a DNS mode →nameserver specifies the list of upstream resolvers Mihomo uses for regular domain lookups. Depending on the supported format, you can enter standard DNS or encrypted DNS addresses. This is not the only source used for all lookups: policy resolution, bootstrap lookups, and proxy server domain resolution may use other fields. Adding more resolvers does not necessarily make lookups faster. First confirm each address is reachable and the query path is as expected.
In a TUN configuration, DNS hijacking redirects matching DNS requests to the core's resolver for centralized handling. It describes how requests are captured, not a change of upstream resolver. Matching ordinary DNS ports cannot directly capture all encrypted DNS traffic generated by apps. Check app settings, routing, and the actual request type to understand what is covered.
Learn how DNS requests are captured →A DNS leak generally means domain lookups are sent through an unexpected resolver or network path, potentially exposing browsing activity. Browser secure DNS, the system resolver, and other network services can all take part in lookups, so a website's exit IP alone is not enough to assess a leak. First identify the expected DNS path, then check query logs and egress. A resolver being located in a particular region does not by itself prove a leak.
Learn how to troubleshoot DNS →Connection status, system proxy status, and test results in the interface each mean different things and should be verified separately.
A GUI client provides controls for importing configurations, switching modes, selecting nodes, and viewing logs, and it starts or manages the core. Clients may merge configurations differently, and identically named buttons may not produce the same fields. Before following a tutorial, confirm that it applies to your app and platform. To determine what configuration actually takes effect, check what the client passes to the running core.
Browse clients by platform →System proxy settings register a proxy address and port with the operating system for apps that honor those settings. Some command-line tools, games, and apps with their own network stack may ignore them, so enabling the switch does not capture all traffic. If a browser works but another app does not, check the app's proxy settings, environment variables, or TUN mode instead of immediately replacing the subscription.
Learn how to check and verify connections →A client latency test typically measures how long a node takes to reach a specified address; it may not use ICMP Ping. Results depend on the test target, connection reuse, DNS, and current network conditions, so numbers from different clients may not be directly comparable. Low latency does not mean high download bandwidth. If a test times out, check the logs to see whether the target is unreachable or the proxy connection failed.
Learn about speed tests and connection issues →VpnService is an Android VPN service interface that lets a client create a virtual network interface and receive traffic. System authorization means the app is allowed to create a connection; it does not provide a remote proxy node or guarantee that a node is working. Per-app settings, other VPN apps, and system battery restrictions can all affect connectivity. If the connection drops in the background, check each of these separately.
Learn how to get started on mobile →