Look up terms by where they appear in your configuration, from subscriptions to networking. Each entry explains the concept, its purpose, and its limitations. Share a card title to link directly to that term.
First identify where the configuration comes from, which proxies it contains, and how traffic is captured. Then check whether the connection works.
A subscription is a remote link used to fetch configuration. Its contents may include proxies, proxy groups, and rules—not just a list of proxies. Updating it retrieves the provider’s latest content and may overwrite fields you changed locally. Links often contain access credentials; hide sensitive parameters when troubleshooting, and never post the full link publicly.
A Profile is a set of settings the core loads, usually stored as YAML and containing proxy entries, proxy groups, rules, and DNS options. A subscription profile is fetched remotely, while a local profile is saved and maintained by the user; either can be the active configuration. Switching profiles may also change rules and proxy groups, so check what is currently selected rather than relying on the profile name alone.
A proxy is an entry for a proxy service you can connect to, typically containing a server address, port, protocol, and authentication settings. Seeing a proxy in the configuration only means the entry was loaded; it does not mean the server is online or the credentials are valid. If it will not connect, check the subscription, matching settings, and network path instead of repeatedly switching between similarly named entries.
The latency shown by a client is usually the time taken to reach a specified test URL. It may include DNS resolution, the handshake, and the response, so it is not an inherent property of a connection. Results vary with the test URL, timeout, and network conditions. Low latency does not mean high bandwidth or guarantee access to a particular website; also check connection stability and the destination’s response.
System proxy settings direct traffic to Clash’s local listening address, allowing apps that honor those settings to forward their requests. Some apps use their own network settings and may connect directly even when the system proxy is enabled. System proxy and TUN capture traffic at different layers. Before closing the client, consider turning off the system proxy so the OS does not keep sending requests to a port that is no longer listening.
A protocol defines how connections and authentication work. Transport security also depends on encryption, certificates, and server settings.
HTTP proxy is a common interface used by browsers and other apps. It can create a tunnel for HTTPS using the CONNECT method. Here, HTTP describes the proxy interface—not a requirement that the destination website use unencrypted HTTP. When HTTPS is forwarded normally, the encrypted connection is still established between the app and the destination. Using a proxy does not, by itself, require installing a root certificate.
SOCKS5 can forward TCP connections and defines a method for forwarding UDP datagrams, but the app, client, and server must all support the relevant feature. The protocol itself does not encrypt traffic, so SOCKS5 is not an encrypted tunnel. An app may resolve domain names locally or send them to the proxy to resolve; check the specific implementation when troubleshooting DNS routing.
Shadowsocks uses encryption to forward network traffic. The server address, port, encryption method, and password must match. Protocol versions and encryption methods may not be compatible, so a proxy’s name alone does not confirm that it will work. If the server uses a plugin, the client must support it and have the matching settings. Changing the encryption method cannot make an incompatible server work.
Trojan typically establishes connections over TLS and uses a password for authentication. In addition to the server and port, the TLS hostname, certificate validation, and transport options affect whether it connects. If certificate validation fails, check the system clock, hostname, and server certificate first. Disabling certificate validation should not be a routine fix, as it removes an important check of the server’s identity.
VLESS is a proxy protocol that commonly identifies users with a UUID. A working connection also requires the transport and security layer specified by the server. TLS, REALITY, transport paths, and related settings are not interchangeable, and not every proxy uses the same combination. If an imported configuration will not connect, check core support and all required settings; adding a UUID alone does not complete the configuration.
Rules match connection conditions, policies determine how to handle them, and proxy groups choose which proxy entry to use.
Rule-based routing selects a policy for each connection—such as proxy, direct, or reject—based on conditions including domain, IP address, and process. Rules are generally checked from top to bottom, and the first match determines the result. An overly broad rule near the top can prevent more specific rules below it from matching. To troubleshoot routing, check the matched rule and final policy in the connection log, rather than just confirming that the rule text exists.
A proxy group combines multiple proxies or other proxy groups into one entry that rules can reference, rather than binding them to a single proxy. select lets you choose manually, url-test selects based on test results, and fallback typically checks entries in order for an available option. Automatic selection depends on the test URL and interval, and does not guarantee the same best choice for every use case.
A rule provider stores a set of match conditions separately for the main configuration to reference, making it useful for maintaining domain or IP range lists. The contents must match the configured behavior and file format; a domain-only list cannot be read as an arbitrary full ruleset. If a remote fetch fails, check the update log and local cache. A successful main configuration load does not mean every rule provider updated successfully.
GeoIP uses a database to identify the region or category associated with an IP address, often for routing traffic to a policy. Results depend on the database version and address allocation data; they do not indicate a website’s language, operator, or actual service location. When a domain resolves to multiple addresses, the match may also change with the DNS result. For precise control of a service, combine GeoIP with domain rules.
Rule mode selects a policy according to the ruleset. Global mode typically sends captured connections through the global policy, while direct mode connects them straight to their destinations. The mode describes how the core handles traffic it receives—not whether an app sends traffic to the core. Global mode does not mean every app is captured; that depends on system proxy, TUN, and app settings.
Check DNS resolution and traffic routing together. Changing one setting may not affect every app.
DNS looks up records such as IP addresses for domain names, so apps know where to connect. The operating system, browser, and Clash core may each use a different resolution path. Changing DNS in the configuration may not affect secure DNS enabled independently in a browser. First identify which component made the query and which resolver handled it, then adjust DNS servers and routing. Avoid changing several parts of the setup at once.
Fake IP returns a synthetic address for a domain and stores the mapping in the core, allowing later connections to that address to be handled using the original domain. The synthetic address is not the website’s real server address; correct DNS interception and traffic routing are required. Apps that depend on real DNS results may need to be added to fake-ip-filter. Adjust the filter for specific compatibility issues rather than excluding every domain.
TUN captures IP traffic through a virtual network interface and routing settings, including traffic from some apps that ignore system proxy settings. Enabling it usually requires additional permissions. Its actual coverage depends on routes, exclusions, the network stack, and DNS settings; turning it on does not guarantee that every connection is captured. When using another VPN at the same time, check for routing conflicts and keep a way to disable TUN if needed.
A DNS leak occurs when queries bypass the intended resolver or proxy path—for example, by being sent to a resolver provided by the local network. A website connection going through a proxy does not prove that its DNS query took the same route. Encrypted DNS is not automatically routed through the proxy, either. Check system DNS, secure DNS in the browser, TUN capture, and logs together; test pages can show only part of the picture.
Domain sniffing attempts to identify domains from handshakes or protocol metadata on supported connections, adding rule-matching information when only the destination IP is available. It cannot decrypt arbitrary HTTPS traffic or identify every connection, and is limited by the protocol and its encryption handshake. Whether it overrides existing destination information depends on the configuration. Check connection logs to see what changed; sniffing is not a substitute for a complete DNS setup.
The interface, core, and configuration have different roles. When something goes wrong, first identify which layer is involved.
mihomo is a core project in the Clash ecosystem that handles proxy connections, rule matching, DNS, and traffic interception. A graphical client provides the interface and usually integrates a core, but the client version and core version are separate. If a field is unsupported or a protocol is incompatible, check which core and version are actually running, then consult the relevant configuration documentation.
A Clash client lets you import configurations, choose policies, control connections, and view logs. Apps differ in their interfaces and system integrations. Similar menu names do not guarantee identical behavior, and supported configuration fields depend on the integrated core. When choosing a client, check your platform and processor architecture first, then confirm it supports the features you need. Browse the download page by platform.
YAML is a common text format for Clash configurations. It uses indentation to express structure and organizes settings with key-value pairs, lists, and other constructs. Use spaces for indentation, and quote strings containing special characters correctly; do not copy formatting symbols from documentation blindly. A YAML parser accepting the file does not mean the core configuration is valid. Check field names, proxy group references, and value types as well.
An external dashboard uses the core’s control API to view connections, switch policies, and manage runtime status; it is not the route that proxy traffic takes. external-controller specifies the control API’s listening address, while external-ui can specify the location of the dashboard’s static files. Restrict the listening address and configure authentication to prevent unauthorized users from changing policies or viewing connection details.
A configuration override replaces or merges selected fields before or after the original configuration loads, using the mechanism provided by the client. It is often used to preserve local DNS, routing rules, or traffic capture preferences. Clients may handle mappings, lists, and execution order differently; do not assume every override appends rather than replaces. After making changes, inspect the final active configuration and confirm your settings persist when subscriptions update or you switch profiles.
If an import fails, check the subscription and YAML first. If an app is not using the proxy, distinguish system proxy from TUN. If traffic reaches the core but follows the wrong policy, check the rules, proxy groups, and domain detection. This sequence helps keep configuration sources, capture scope, and routing results distinct.