Clash Client UI Guide

Start by separating profiles, proxies, and traffic routing

To understand the Clash interface, keep three questions separate: where the configuration comes from, which proxy handles a request, and whether app traffic reaches the client at all. The Profiles page loads proxies, proxy groups, and rules. The Proxies page lets you inspect groups and choose an outbound route. System proxy and TUN settings determine how app traffic reaches the core. Logs provide clues about processing and errors; they don't replace any of these settings.

Clash is a common name for the proxy core and its associated clients. mihomo is a core that evolved from Clash Meta. Navigation labels, button locations, and core features vary across graphical clients. Paths such as “Main window → Profiles” and “Main window → Proxies” below indicate where to find a feature; your client may label these sections “Subscriptions,” “Profiles,” or “Proxies.” Look for the corresponding function rather than an exact label.

Profiles: confirm activation after importing

For first-time setup, open “Main window → Profiles,” then choose “Import” or “New.” Remote subscriptions usually require a subscription URL; for a local profile, select a YAML file. Subscription URLs may contain personal access credentials. Store them somewhere trusted, and don't include them in screenshots or public support requests.

Import, activate, and update are three separate actions

1. Import: Add a remote profile or local file to the list. Seeing a profile card means only that the client saved the profile entry.
2. Activate: Select a profile and load it into the core. Check the selected indicator, the active profile name, and any load errors.
3. Update: Fetch the remote content again. When the update finishes, check the timestamp and load result. You may need to activate the profile again, depending on how the client reloads it.

For example, if an update adds proxies but the Proxies page still shows the old list, first check whether you updated a different profile card that isn't active. If activation reports a YAML parsing error, inspect the indicated line, indentation, and field type; repeatedly clicking Update won't fix it. A failed network request and a configuration parsing error are different problems: for the former, check the subscription URL, network, and server response; for the latter, check whether the returned content is a valid profile.

Local edits versus subscription updates

Direct edits to a cached remote profile may be overwritten the next time it updates. If your client supports overrides, merges, or extension scripts, check their execution order first, then put persistent local rules in the appropriate mechanism. Override formats vary by client; a script for one client can't simply be used as a mihomo YAML field.

Proxies: check the mode before the policy group

In “Main window → Proxies,” don't assume every box represents a server. The page usually shows policy groups first, followed by the proxies or other groups available within them. When a rule points to a policy group, the actual outbound route depends on the group type and current selection. So clicking a proxy doesn't necessarily mean the current request will use it; the rule still has to match.

How the three modes affect traffic

• Rule mode: Requests are matched against the configured rules in order and may go direct, through a proxy, or be rejected. Selecting a policy group affects only traffic matched to that group.
• Global mode: Requests that reach the core follow the global policy. This can help with a brief comparison while troubleshooting, but it won't route app traffic that never reaches the core.
• Direct mode: Connections that reach the core go direct. Some clients don't offer a separate button for this mode; check what your client actually supports.

Manual selection versus automatic policies

A select group lets you choose manually. url-test selects an outbound based on periodic tests; fallback picks the first available option in order; load-balance distributes connections according to its configured strategy. Whether an automatic policy allows temporary manual overrides, and how it resumes automatic selection, depends on the core and UI implementation. The card's appearance alone won't tell you.

For example, if a rule sends a destination to the “Web Proxy” group but you change the “Media Proxy” group, web traffic usually won't be affected. Check the Connections page to see which group actually matched instead of switching proxies at random. A policy group may also point to another group, so follow the proxy chain through to the final proxy.

Latency tests: distinguish a timeout from download speed

The “Test” button on the Proxies page usually sends a request to a specified test URL and displays how long the probe took, in milliseconds. It's not a sustained bandwidth test or the same as an ICMP ping. Results depend on the test URL, timeout, proxy connection status, and your current network.

If two tests show 85 ms and 210 ms, that only means the first probe finished sooner under those test conditions. These figures are examples, not test results from this site. They don't prove large-file download speed, video stability, or access to a particular website. If a test shows timeout, check whether the proxy failed to connect, the test URL was unreachable, or the timeout was too short.

1. Test one proxy you plan to use and confirm that it returns a result.
2. Open the destination in the app you actually use and note when the problem occurs.
3. Check the Connections page to see whether the destination used that proxy, then review the logs from the same time.

Testing every proxy in quick succession creates extra connections. For troubleshooting, test a small number of candidates so results are easier to compare and test traffic doesn't get mixed up with app traffic. If the UI lets you change the test URL, establish a new baseline after changing it; don't rank results collected under different test conditions.

Connections: check the rule and final outbound

The Connections page is the best place to answer, “Where did this app's traffic actually go?” With the client active, make a fresh request, then filter by domain, destination IP, or process name. Whether process information appears depends on platform permissions, traffic capture method, and core configuration. A blank field doesn't necessarily indicate a connection problem.

• Destination: Check the domain or IP and destination port. HTTPS commonly uses destination port 443; this is not the client's local listening port.
• Rule: Check the matched rule type and condition, such as a domain suffix rule or the final MATCH rule.
• Proxy chain: Check whether the final route is DIRECT or a policy group and its selected proxy.
• Connection status: Use the duration and upload/download counters to see whether the request is still active. Column names vary by client.

Existing connections may not move to a new outbound when you switch policies. Browsers may reuse an open connection, so start a new one to verify the change. If your client has a “Close connection” option, close only the relevant entry and revisit the destination. Closing all connections can interrupt downloads, calls, and other tasks, so check the impact first.

If the destination never appears in the connection list, first check whether the app follows the system proxy or uses another network route. The app may also use cached data and make no new request. Don't assume a missing entry means the proxy is down.

Logs: filter by level and don't draw conclusions from one line

Open “Main window → Logs,” clear any UI filters or note the current time, then reproduce the issue. Logs record core events and connection processing; they may not retain a complete history of every request. Some clients receive live entries only while the Logs page is open. If you need logs for longer, check whether the client supports writing them to a file.

Three common error messages

• address already in use: A listening address or port is usually occupied. Identify the port and process first; you don't need to replace the subscription right away.
• i/o timeout: A network operation timed out. Check the destination, connection stage, and surrounding context; this doesn't necessarily mean the subscription has expired.
• connection refused: Often means the destination port isn't listening or the connection was explicitly rejected. Check whether the error points to a local interface, an upstream proxy, or the destination service.

The log-level setting in the profile controls output verbosity. The dropdown on the Logs page may only filter entries the core has already sent. If the core outputs errors only, setting the UI filter to “All” can't restore routine logs that were never produced. To see more detail, make sure you're changing the core's log setting, then reload and reproduce the issue.

Settings: check ports, system proxy, and TUN separately

The local port in Settings is where apps connect to the client; the controller port is for the UI or management tools to call the core API. They serve different purposes. For example, mixed-port: 7890 accepts HTTP and SOCKS proxy requests on the same port. 127.0.0.1:9090 is a common example of a local controller address, but it isn't a fixed default for every client.

The snippet below explains what the fields mean; it isn't a complete profile you can use to replace a subscription. A graphical client may override these fields in its settings, so check the values actually in effect:

mixed-port: 7890
allow-lan: false
log-level: info

System proxy and TUN are separate settings

System proxy usually changes the operating system's proxy settings, so only apps that follow those settings use that route. TUN captures traffic through a virtual network interface and routing, often requiring elevated permissions and involving DNS and route settings. After enabling TUN, check service permissions, confirm the virtual interface was created, and make sure the rules match your needs. TUN isn't a universal fix for connection problems.

In clients with an options menu, look under “Settings → Preferences” for the port. If there's no such section, search for “Ports” or “Core settings.” After changing 7890, also update any manually configured browser proxy, terminal environment variables, and other app settings. Check in the operating system whether the client has updated its managed system proxy settings too.

A full check: from profile to logs

If a proxy passes the latency test but websites won't load, follow these steps to narrow down the problem instead of changing several settings at once.

1. Profiles: Confirm the intended profile is active and loads without errors. The subscription update time is a clue, not a substitute for checking the load result.
2. Proxies: Confirm Rule mode is active and check the destination's policy group and proxy. Switch to Global mode briefly only if you need a comparison, and note the original setting.
3. Settings: Confirm the app uses the system proxy or TUN, and check the actual listening port so the app isn't still pointing to the old 7890.
4. Connections: Revisit the destination, check for a new connection, and note the matched rule and final outbound.
5. Logs: Check for errors at the same time and identify whether the issue occurred during DNS, upstream connection, TLS, or local listening.
6. Restore settings: When troubleshooting is done, restore any temporary mode or log-level changes and keep only the necessary redacted records.

For everyday use, follow this sequence: confirm the profile source → check the policy → verify the result in Connections → investigate errors in Logs. For field definitions, see the Configuration Reference. To import a profile and connect apps for the first time, follow the Quick Start Guide.