Clash Client Interface Guide: Proxy, Profiles, and Logs

Start by separating the client interface, core, and active configuration

The Clash client window displays settings, the core handles connections, and the configuration file defines proxies, proxy groups, DNS, and rules. Clients using the mihomo core generally organize these areas in similar ways, though button names and locations can vary. This guide refers to common interface labels such as “Proxies,” “Profiles,” “Logs,” “Connections,” and “Settings.” Some clients call “Profiles” “Subscriptions” or label “Proxies” as “Proxy Groups.”

This guide covers interface workflows and is not tied to a specific client version. If labels differ, check what a setting does rather than following screenshot coordinates. Clash Release Hub curates client downloads and usage guides; it is not affiliated with the official client development teams.

Proxy page: check the operating mode, then the proxy groups

What Rule, Global, and Direct modes change

The top of the Proxies page commonly offers three modes: “Rule,” “Global,” and “Direct.” The mode controls how connections select a policy; it does not determine whether every app on your system is routed through the proxy. Even in Global mode, apps that do not use the system proxy and are not captured by TUN may bypass the core.

• Rule mode: Rules are checked in rules order, and the policy specified by the first matching rule is used. A policy can be DIRECT, REJECT, a proxy node, or a proxy group.
• Global mode: Uses the current selection in the global proxy group. Check the GLOBAL group or the corresponding global selection area in the interface to confirm the outbound; do not rely on the regular proxy groups.
• Direct mode: Connections that reach the core use the direct policy. This is not the same as quitting the client or turning off the system proxy.

For everyday use, Rule mode is usually the right choice. Temporarily switching to Global can help determine whether routing rules affect access, but switch back afterward. If Global works and Rule does not, check the matched rule and its target proxy group before concluding that a node is broken.

Proxy groups are not just a list of unrelated nodes

Labels such as “Select Proxy,” “Auto Select,” and “Streaming” on the Proxies page usually come from proxy-groups in the configuration file; they are not built-in client features. A group can reference nodes or other groups. So if “Auto Select” is selected, that only means the current group delegates the next choice to that subgroup.

• select: Manual selection. After you choose an option, new matching connections use it.
• url-test: Automatically selects based on the configured test URL, interval, and tolerance. It does not guarantee the lowest latency for every website.
• fallback: Selects an available option in configuration order; it typically does not sort options from lowest to highest test latency.
• load-balance: Routes traffic across multiple outbounds according to the configured balancing strategy. It does not combine all nodes’ bandwidth for a single download connection.

After switching nodes, existing long-lived connections may keep using the old outbound. Start a new request to verify the change; if needed, close the target connection on the Connections page. Avoid disconnecting every connection just to test one website, especially during downloads or meetings.

Profiles page: identify the active profile and update subscriptions

Importing, updating, and activating are separate actions

A card on the Profiles page usually represents a local or remote configuration. A successful import means the client saved the configuration source; it does not guarantee that the profile is active. After choosing “Enable,” “Use this profile,” or selecting the card, confirm the active indicator and check for any parsing errors.

1. Open Profiles and check the name and selected indicator on the active profile card.
2. Open the card menu and choose “Edit info” or “Details” to verify that the subscription URL is from the expected source. Do not share screenshots showing the full URL.
3. Choose “Update” and check the update time and any errors. Then return to Proxies and confirm that the group names and node list look right.
4. If the profile fails to activate after an update, check Logs for parsing errors. Start by checking indentation, field formats, and core compatibility.

Updating a subscription usually means fetching its remote content again; it does not update the client app. Updating an individual proxy-provider may only refresh the node list, without replacing the main configuration’s rules or DNS settings. If nodes change but rules do not, first check whether you updated the profile or just the provider.

Local edits, overrides, and the final runtime configuration

Edits made directly to a downloaded remote subscription file may be overwritten the next time it updates. For routing rules you want to keep, use the client’s supported override, extension configuration, or merge feature. Merge order varies by client, so check whether rules are appended or inserted earlier in the list.

The following is a rule snippet, not a complete configuration. The existing configuration must already contain a proxy group named Proxy; this snippet cannot be imported as a standalone subscription:

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN-SUFFIX,example.com,Proxy matches the domain and its subdomains; GEOIP,CN,DIRECT checks the destination IP against the GeoIP database; MATCH,Proxy catches connections that matched no earlier rule. A domain rule placed after MATCH will never take effect because the catch-all rule before it has already matched.

If the client offers “View runtime configuration” or “Runtime config,” check the final result after making changes. A rule in the editor does not necessarily mean the core has loaded it. A failed profile switch, a disabled override, or rules appended in the wrong place can all lead to a mismatch.

Logs page: trace a rule and outbound with a single request

Start with info logs; enable debug briefly if needed

Common log levels include debug, info, warning, error, and silent. Start with info for routine troubleshooting. Switch to debug briefly when you need more detail. If the interface has both a “Level filter” and a “Log level” setting, the filter may only affect what is displayed, while the setting determines which records the core generates.

1. Open Logs, pause auto-scroll or clear the current display, and note the start time.
2. Return to your browser and visit the page you need to troubleshoot once.
3. Go back to Logs and filter by a domain keyword. Avoid opening several test sites at once.
4. Read the network type, destination, rule type, and outbound in order; check the error details last.

The following is a structural example, not verbatim output from a specific version. A client may split the same information across columns or display it in a different text format:

[info] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[Node A]

• TCP: This record is for a TCP connection; it does not show that other UDP traffic is being handled correctly.
• 127.0.0.1:53124: The example’s local source address and temporary source port, not the proxy listening port to enter in system settings.
• www.example.com:443: The destination domain and the port commonly used for HTTPS. The presence of port 443 alone does not mean the client is decrypting HTTPS traffic.
• DomainSuffix(example.com): A domain-suffix rule matched.
• Proxy[Node A]: An example of traffic passing through the Proxy group and using Node A. If groups reference other groups, check the Connections page to see the full proxy chain.

Read logs by identifying where the error occurred

If the browser says a page cannot be reached but there is no corresponding log entry, first check the filters and log level, then verify whether the request reached the core. Browser cache and reused connections can also affect what you see. Starting a new request to the target is more useful than repeatedly switching nodes.

Settings and Connections: verify how traffic enters the core

System proxy and TUN mode provide different ways to route traffic. The system proxy gives proxy settings to apps that read them; some command-line tools, games, and apps that manage their own networking will not use it. TUN captures traffic through a virtual network interface and routing, but its coverage also depends on route exclusions, permissions, DNS settings, and other VPNs.

Check the current port setting instead of relying on the default

For example, if the runtime configuration includes the two entries below, apps that support HTTP or SOCKS can connect to port 7890 on the local machine using the corresponding protocol. Here, 7890 is an example value, not a guaranteed default for every client:

mixed-port: 7890
allow-lan: false

When configuring a proxy manually on the same device, the address is usually 127.0.0.1, and the port must match “Mixed Port” in Settings. external-controller is the control interface, not a proxy port for browsers. With allow-lan: false, other devices on the local network should not be expected to use this proxy directly.

Verify with connection records, not just the toggle color

After enabling the system proxy or TUN, search for the target domain on the Connections page and check its rule and proxy chain. If the destination appears as an address in the 198.18.0.0/16 range, it may be a normal mapping from Fake-IP in the configuration. Check the domain and DNS settings together; an unfamiliar address alone does not mean traffic went to the wrong server.

To learn about system proxy settings and routing rules, see the system proxy setup guide and routing rules guide. TUN affects system routing, so save your current configuration before enabling it. If network issues occur, first disable the newly enabled traffic-capture method, then troubleshoot one setting at a time.

End-to-end check: from configuration to a matched rule

Once you are familiar with the interface, use the following steps to run a complete check. Change only one variable at a time and note the results before and after each change. Avoid changing the subscription, node, DNS, and mode all at once.

1. Check the profile: On the Profiles page, verify the active card and confirm the update loaded successfully. Check the final runtime configuration if needed.
2. Check the mode: On the Proxies page, select Rule mode, find the group targeted by the rule, and check its current selection.
3. Check traffic routing: In Settings, verify the system proxy or TUN status. For manually configured apps, check the address, protocol, and port.
4. Make a request: Open the target once, then look for the same domain in Logs or Connections.
5. Confirm the route: Check the matched rule, group name, and final outbound. If the rule is wrong, check its order; if the outbound is wrong, check how the groups reference one another.
6. Restore normal settings: Revert temporary Global mode and debug settings, keeping any configuration changes you have verified.

The Proxies page answers “Which outbound is selected?”, Profiles answers “Which definitions are loaded?”, and Logs answers “What happened to this connection?” Check all three along with the traffic entry point to distinguish an inactive configuration, an unmatched rule, an unreachable node, and an app that is not routed through the core. If the cause is still unclear, continue with the relevant Troubleshooting topic.