Quick glossary / 25 common terms
Start by distinguishing subscriptions, nodes and configurations, then look up routing rules and DNS. Share any term using the anchor beside its heading, or continue to a tutorial or configuration reference for practical steps.
Know what a subscription imports, what a node connects to, and what determines which traffic is routed.
Fundamentals
A subscription uses a URL to retrieve and update nodes or configuration; it is not itself a proxy connection. It may return a complete YAML configuration or just a list of nodes, so check that your client supports the format before importing it. After an update, enable the configuration and select a policy. Subscription URLs often contain access credentials, so do not share them publicly or include them in screenshots.
See how to import a subscription →Fundamentals
A node is a set of parameters for connecting to a remote proxy server, usually including its address, port, protocol and authentication details. Its name in the interface is just a label; it does not reveal the actual exit location or guarantee availability. For a connection to use a node, traffic must enter the core and a rule or policy must direct it there.
Fundamentals
Latency is the time taken by a specific probe. Depending on the test, it may include connection setup, a TLS handshake and the response time, so it may differ from a system ping result. The test destination, caching and current network conditions all affect the value. Use it to compare connections under the same conditions, not as a measure of download speed. Check the logs to investigate timeouts.
Fundamentals
System proxy settings provide an address for apps to use, usually pointing to a local listening port on the client. Browsers and other apps may follow these settings, but some games, command-line tools and apps with their own networking stack may ignore them. An enabled toggle only confirms the setting was changed. Check the relevant connections and logs to see whether traffic is actually being routed through the proxy.
Fundamentals
A mixed port accepts both HTTP and SOCKS5 proxy connections on the same local listening port, for example mixed-port: 7890. The number is a configurable local port, not the remote node's port or a speed setting. Make sure the port configured in the app matches the one actually listening. If startup fails, first check whether another process is using the port.
The protocol determines how a connection works; authentication, transport and TLS settings must also match.
Proxy protocols
An HTTP proxy accepts proxy requests from an app. To access an HTTPS website, the app typically uses CONNECT to create a tunnel, then communicates with the site over TLS. An HTTP proxy can still access HTTPS sites, and the HTTP label does not mean traffic between the app and proxy is encrypted. When setting a proxy manually, distinguish the proxy protocol from the destination website's protocol.
Proxy protocols
SOCKS5 is a general-purpose proxy protocol that can forward TCP and, when both implementations support it, UDP through the appropriate mechanism. Whether domain names are resolved locally or by the proxy depends on the app's implementation and settings; the SOCKS5 label alone does not tell you. SOCKS5 does not provide encryption, and TCP proxy support does not imply UDP support.
Proxy protocols
Shadowsocks is a proxy protocol that requires the client and server to use the same encryption method and matching credentials. If a connection fails after importing a node, check the address, port, encryption method and authentication details rather than just changing the node name. Protocol extensions and plugins may have additional requirements, so not every Shadowsocks configuration works in every client.
Proxy protocols
Trojan typically carries proxy traffic over TLS and requires valid TLS settings in addition to the address, port and authentication details. The server name may be used for certificate verification and the handshake, and may differ from the connection address. If you see a certificate error, check the system time, server name and server configuration. Do not routinely disable certificate verification as a fix.
Proxy protocols
VLESS is a proxy protocol often deployed with TLS, REALITY or different transport types. The protocol name alone is not enough to recreate a node; you also need its authentication ID, transport type and relevant security settings. A successful import in the client does not guarantee that its core supports every combination. Check the server requirements against the capabilities of the core in use.
Check which rule a connection matched, then see which policy that rule points to.
Routing rules
Rule-based routing directs connections according to domains, IP addresses or other conditions. Rules are usually checked from the top down, and matching traffic is handed to the assigned policy. For example, DOMAIN-SUFFIX,example.com,DIRECT sends matching domains to the direct-connection policy. Earlier rules generally take priority, so a broad rule near the top may catch traffic before a more specific rule can match.
Routing rules
Proxy groups organize nodes or other policies. Common types include select for manual selection, url-test to select based on probe results, and fallback for failover. Once a rule points to a group, the group's type and current state determine the actual exit route. Make sure group and node names match exactly. Existing long-lived connections may not switch immediately when you change the group's selection.
Routing rules
Rule mode uses the configured rules to decide where each connection goes. Global mode typically sends connections that have entered the core to the global policy. It changes how traffic is routed; it does not make every app follow the system proxy or enable TUN. Rule mode is a good default for everyday use. Temporarily switching to Global can help distinguish a rule issue from a node issue, but it is not a substitute for a full investigation.
Routing rules
GeoIP uses regional classifications from an IP database to match rules, such as choosing a policy based on the destination IP's location. It is not a domain category list, and location data is not always accurate. Cloud services and network changes can cause mismatches. If a site uses the wrong policy, first check which rule actually matched, then decide whether to adjust a domain rule or update the relevant data.
Routing rules
A rule set stores a group of matching conditions separately. Add it through rule-providers, then use RULE-SET to specify the policy to apply. Rule sets are easy to update and reuse, but their content format must match declarations such as behavior. A successful download is only the first step: make sure the rule set is referenced in the rule list and appears in the right order.
DNS resolution, connection routing and traffic capture are related, but distinct issues.
DNS and networking
DNS resolves domain names to IP addresses and other records. When you visit a website, resolution usually happens before the connection is established. A successful lookup does not mean the destination is reachable or that the connection uses a proxy; a failed connection is not necessarily a DNS issue either. Browsers may use their own encrypted DNS, so after changing system DNS settings, check whether the app actually uses that resolution path.
View DNS configuration →DNS and networking
Fake-IP mode returns a virtual address for a queried domain and has the core maintain a mapping between the address and domain, allowing later connections to be associated with that domain. The virtual address is not the site's real IP and cannot be used to determine the server's location. Some apps rely on real IP addresses or special discovery mechanisms and may need compatible filter settings. Enabling this mode does not mean all DNS requests are being captured.
DNS and networking
A DNS leak occurs when domain lookups do not follow the expected path and are instead handled by another resolver. The region shown by a DNS test does not, on its own, prove a leak. Consider the intended configuration, browser encrypted DNS, IPv6 and system routing together. First establish which resolver should handle the request and how it should reach that resolver, then check what actually happens rather than relying on a location label alone.
DNS and networking
TUN mode routes IP packets into the core through a virtual network interface and routing settings. It is useful for apps that do not follow the system proxy. Actual coverage depends on permissions, automatic routing, exclusions and the system's network conditions. Before enabling it for the first time, keep your original network settings. If conflicts occur, disable other VPNs or traffic-capture tools and check each setting in turn.
DNS and networking
allow-lan controls whether other devices on the same local network can access this machine's proxy service. It does not configure proxy settings on phones or other computers automatically. You also need an appropriate listening address, firewall rules, and the correct local IP address and port configured on each device. Enable it only when needed on trusted networks, and avoid exposing the proxy port directly to the public internet.
The interface provides controls; the core and active configuration determine network behavior.
Clients and cores
Clients typically handle subscription management, policy selection and system integration. The core handles proxy connections, rule matching, DNS and other network processing. Clients with similar interfaces may use different cores or generate configurations differently. When reporting an issue, include details about both the client and core. Updating the UI does not necessarily update the core that's currently running.
Browse clients by platform →Clients and cores
mihomo is an open-source core in the Clash ecosystem, previously known as Clash.Meta. It handles proxy connections, rule-based routing, DNS and more. It can be integrated into a GUI client or run independently on a server or router. When looking up configuration fields, check the actual core and its version; a configuration accepted by another core may not work in your environment.
Clients and cores
YAML is a common format for Clash configurations. Indentation represents hierarchy, and hyphens mark list items. Use spaces, not tabs, for indentation, and preserve the original nesting when copying a snippet. A file that parses successfully is only syntactically valid; check field names, value types and core support when loading it.
View the YAML structure →Clients and cores
Configuration overrides modify the final configuration by merging snippets or running scripts on top of original content, such as a subscription. They are often used to preserve local DNS, routing rules or listening settings. Clients may handle merge order and list additions or replacements differently. Check the active configuration after making changes, not just the original subscription file. Direct edits to files that get overwritten during updates are unlikely to persist.
Clients and cores
The external controller lets a client UI or dashboard read status and switch policies. A common local address is 127.0.0.1:9090. It is a management interface, not the mixed proxy port used by a browser to access the internet. Confusing the two will cause connection failures. Keep access local by default; if remote management is necessary, configure authentication and restrict access by source.