Clash Client UI Guide: What the Proxies, Profiles, Connections, and Logs Pages Do

Understanding the interface: Profiles, routing choices, and runtime status

A Clash client combines a graphical interface with a proxy core. The interface imports profiles, changes settings, and displays status; the Clash or Clash Meta (mihomo) core listens on ports, matches rules, and establishes connections. So an open interface, a successful subscription update, and a successful node latency test describe three different things—they are not interchangeable.

Sidebar order and labels vary between clients. Desktop apps commonly include Proxies, Profiles, Connections, Rules, Logs, and Settings; mobile apps may move some features to a bottom navigation bar or submenu. The sections below follow a common functional order. Menu paths indicate where to find a feature, but labels vary by client and this is not a pixel-perfect guide to a specific version.

Proxies page: Choose a proxy group, not just a node

Rule, Global, and Direct modes

A common path is “Proxies” → “Mode.” Rule mode corresponds to mode: rule; connections are routed according to the rules in the profile. Global mode sends ordinary connections through the global policy, often shown as GLOBAL. Direct mode bypasses the proxy. These modes determine how traffic is routed; they do not replace the system proxy or TUN, which direct app traffic into the core.

For everyday use, start with Rule mode, then check which proxy group the matching rule references. Say a rule sends a domain to “Web Egress,” but you change only “Downloads.” New connections to that domain may still use the original node. To verify a switch, check the group actually used—not just whether a node card is highlighted.

Proxy group type determines what its controls do

• select: Manually choose a node or nested proxy group when you need to specify the egress route.
• url-test: Tests candidates against the configured URL and interval, then selects an option based on settings such as tolerance. It is not a ranking of download speeds.
• fallback: Typically selects an available option in candidate order. Its purpose is failover, not always choosing the lowest-latency option.
• load-balance: Distributes connections according to the configured strategy. It does not combine every node’s bandwidth for a typical download.

A group may also contain DIRECT, REJECT, or another proxy group. These mean bypass the proxy, reject the connection, or pass selection to the next group—they are not all actual servers. The millisecond value shown by a latency test is one probe to a specific target. For example, 80 ms versus 160 ms is a comparison under those test conditions; it says nothing about video throughput. These figures are illustrative readings, not test results.

Profiles page: Import, update, and activate are separate actions

Common paths include “Profiles” → “Import” or “New.” For a remote subscription, enter its URL; for a local profile, select a YAML file. Import creates a profile entry, update fetches its content again, and activate loads it into the core. Some clients activate a profile on import; others require you to click its card. Seeing a profile name in the list does not mean it is active.

Four things to check when importing a profile

1. Content type: A URL that opens in a browser does not necessarily return Clash YAML. A login page, error message, or config for another client can all cause parsing to fail.
2. Active status: Make sure the intended profile is checked or highlighted, then confirm the expected proxy groups appear on the Proxies page.
3. Update status: A successful update means the client retrieved new content; it does not mean every node can establish a connection.
4. Error details: Distinguish a download failure from invalid YAML syntax or a field the core does not support. Each calls for a different fix.

Subscription URLs often contain access credentials, so treat them like passwords. When sharing screenshots, hide the full URL, QR code, and token; never post them in a public support ticket. Traffic allowances and expiration dates shown by some clients come from server response headers. If these values are not displayed, the import may still have succeeded.

Editing the source profile vs. using an override

Updating a remote profile can overwrite direct edits. To keep local rules, DNS, or port settings, use the client’s Override, Merge, or script feature, and check which profile it applies to. Merge order varies by client, so the original YAML shown in an editor may not reflect the final runtime values.

# Example for learning: shows what the fields mean; not a complete subscription
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

Here, 7890 is an example mixed-port listener for HTTP and SOCKS connections; it is not the default for every client. After saving, check the final values under “View runtime config” or a similar option, if available. See the YAML Config Handbook for field details. Do not use this snippet as a complete, working configuration.

Connections page: See which route a request takes

The Connections page shows traffic that has reached the core. Common columns include destination host, destination IP, port, bytes uploaded and downloaded, connection duration, matched rule, and proxy chain. Whether a process name appears depends on system permissions, core capabilities, and process-detection settings; a blank value does not by itself indicate a traffic problem.

Trace a connection through the routing path

1. Open “Connections” and filter by destination domain or process. Visit just one test site to reduce background traffic.
2. Check the destination port. HTTPS commonly uses 443, but the port alone does not prove that traffic used a proxy.
3. Check the matched rule, such as DOMAIN-SUFFIX, IP-CIDR, or the fallback rule MATCH.
4. Check the proxy chain to see whether the connection ends at DIRECT, a specific node, or a nested proxy group.
5. Change the selection within the group, establish a new connection, and compare the proxy chain.

If the target app’s connection does not appear, first check whether its traffic is entering the proxy rather than immediately switching nodes. Possible causes include the app ignoring system proxy settings, its own proxy configuration, a system bypass list, or TUN routes that do not cover the traffic. The Connections page shows only connections handled by the core; it is not a system-wide traffic monitor.

“Close connection” interrupts the selected session, and the app may reconnect automatically. “Close all” can disrupt downloads, calls, or persistent connections. Prefer closing only the filtered target connection. The traffic totals shown are usually for the current run or statistics period, not the subscription provider’s billing record.

Rules page: See why traffic is direct or proxied

The Rules page usually displays runtime status and may not support editing. Rules are matched in order, and the first match determines how traffic is handled. A specific rule placed after a broad one may never take effect. This snippet uses a reserved example domain to show rule order and policy references:

rules:
  - DOMAIN-SUFFIX,example.com,Web Egress
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Web Egress

Web Egress must have a matching policy definition in the complete profile. no-resolve means this IP rule does not trigger a DNS lookup; it does not disable DNS for the entire client. The final MATCH is a catch-all rule. If placed at the top of the list, it prevents later general rules from matching.

When a profile uses rule-providers, distinguish the main rule list from external rule sets. A failed rule-set download, content that has not updated yet, and incorrect rule order can look similar in the interface. Check the matched rule in connection details first, then inspect the rule source on the Profiles page. This is usually more effective than repeatedly switching to Global mode.

Logs page: Find errors by time, not by guessing line by line

A common path is “Logs” → “Severity filter.” Core log levels commonly include debug, info, warning, and error, though the client may display localized labels. The filter changes what is shown; changing log-level changes which levels the core records. They are separate settings.

For effective troubleshooting, note the time and reproduce the issue once. For example, if you make a request at 14:32:10, review the surrounding log entries and identify whether the error concerns the subscription server, proxy node, or destination website. A single timeout line usually lacks the context needed to diagnose the problem.

Settings page: What the system proxy, TUN, and ports control

The system proxy provides an entry point for app traffic

A common path is “Settings” → “System Proxy,” though some clients put the toggle on the home screen. This feature usually points the operating system’s proxy address to a local listening port, such as 127.0.0.1:7890. Only apps that follow system proxy settings send traffic through this entry point; turning it on does not prove that every app is using the core.

If another app requires you to enter a proxy address manually, use the actual port shown by the client. The HTTP-only, SOCKS-only, and mixed ports may differ. Do not enter the panel’s external-controller API address in a browser’s proxy settings: it is a control interface, not a traffic proxy.

TUN is a virtual network interface, not another kind of proxy node

On desktop, a common path is “Settings” → “TUN Mode.” Starting it may require administrator privileges or service support. TUN routes IP traffic through a virtual interface, but actual coverage also depends on auto-routing, excluded routes, DNS interception, and the system environment. Mobile apps often use the system VPN interface instead, so their controls differ from desktop clients.

• System proxy works, but some apps do not: First check whether the app supports the system proxy, then consider whether TUN is needed.
• LAN access breaks after enabling TUN: Check LAN exclusion routes, DNS, and conflicts with other VPNs. Do not just switch nodes.
• Allow LAN: allow-lan controls whether other devices can access the proxy listener; it does not control whether this device can access other devices on the LAN.
• Launch at startup and enable proxy after launch: These may be separate settings. Check both if you configure either one.

If you need another client, compare platforms and features in the Clash Client Comparison. Do not enable the system proxy and TUN in two clients at once and then try to assess one client’s behavior. Keep a single, clearly defined traffic entry point so you can reproduce and troubleshoot the route.

First use: Check the interface in six steps

1. Profiles: Import a compatible Clash YAML file or subscription, confirm the update succeeds, and activate it.
2. Proxies: Select Rule mode, find the group referenced by the matching rule, and choose an available egress route.
3. Settings: Confirm the core is running, check the actual listening port, and verify the system proxy or TUN entry point.
4. Connections: Visit the destination site and check the new connection’s destination, matched rule, and proxy chain.
5. Logs: If the request fails, review the surrounding entries at the time it occurred and change only the setting related to the error.
6. Profiles, one last check: After updating the subscription, review local overrides and the active profile to make sure your changes still apply.

These six steps check separately whether the profile loaded, traffic entered the core, a rule matched, and the egress route is reachable. If the Proxies page looks normal but a site will not load—or the route seems unchanged after switching nodes—check the relevant page instead of mixing several layers of troubleshooting into one change.