Clash Client UI Guide: Proxies, Profiles, Connections, and Logs

First, understand profiles, outbound proxies, and traffic entry points

A Clash client’s sidebar typically includes Proxies, Profiles, Connections, Logs, and Settings. These aren’t different ways to access the same feature: Profiles determines which nodes, proxy groups, and rules are loaded; Proxies controls the active outbound for each proxy group; Connections shows requests currently being handled; and Logs records core events. System proxy and TUN mode route traffic into the core.

Depending on the client, Proxies may appear as “Proxy” or “Proxy Groups,” while Profiles may be called “Profiles” or “Subscriptions.” The steps below use paths such as “Proxies → Select a proxy group” to describe where an action is performed; menu labels vary by client. Identify each page by its English name and function, then follow the corresponding controls in your client.

Profiles: Import and activate a subscription

An imported profile isn’t necessarily active

A subscription URL usually fetches a remote profile, though some URLs provide only a list of nodes. Whether a client can import it directly depends on the response format and the client’s import support. A web page URL, a subscription URL, and a node share link are different things. Pasting a provider’s login page into the subscription field may return HTML instead of the YAML the core needs.

1. Go to “Profiles” → “Import” or the subscription URL field, then paste the compatible subscription URL provided by your service.
2. Wait for the download and parsing to finish. Check that a profile card appears and that no syntax errors are reported.
3. Select the profile and confirm that its selection indicator or the current profile name changes.
4. Open Proxies and check that the expected proxy groups and nodes appear. If the old content is still there, return to Profiles and confirm that the new profile is active.

A client can save multiple profiles, but usually only one main profile is active at a time. Some clients also support merging, overrides, or scripts, so the original subscription file on disk may differ from the final configuration loaded by the core. When checking a setting, use the client’s runtime configuration or configuration preview if available.

Updating a subscription isn’t the same as updating rule sets

The “Update” button on a profile card usually fetches the remote profile again. Profiles using proxy-providers may also update node providers separately; those using rule-providers may have a separate rule-set download schedule. Updating the main subscription doesn’t necessarily refresh every provider resource at the same time.

• Unexpected node names or counts: check when the subscription was last updated and whether the relevant node provider updated successfully.
• Rules haven’t changed: check which profile is active, the rule order, and whether rule sets have loaded.
• Manual edits keep reverting: a remote update may overwrite the file. Use a persistent override method supported by your client.

Subscription URLs often contain authentication tokens. When sharing a screenshot, hide the full URL, QR code, and authentication details. If you need help, share the error text, core name, and relevant fields—but never publish the entire subscription URL.

Proxies: Choose a mode and proxy group member

Rule, Global, and Direct modes determine how traffic is routed

Rule mode checks requests against the rules in your profile, in order, and sends them to the specified outbound or proxy group. Global mode typically sends requests to the global selection group, but whether they’re proxied depends on the member selected in that group. Direct mode connects traffic handled by the core straight to its destination. None of these modes automatically captures traffic from every app; that depends on system proxy, TUN, or the app’s own settings.

Use Rule mode for everyday browsing. Switching to Global temporarily can help compare routing results, but switch back afterward; otherwise, requests that should go direct may take a different route. After changing modes, test with a new request rather than relying on an existing long-lived connection.

Manual and automatic groups work differently

A select group lets you choose a member manually. A url-test group chooses a member automatically based on configured probes. A fallback group falls back through members according to their availability and order. A load-balance group distributes connections using its configured strategy. Even when an automatic group is selected in a manual parent group, it may not offer a way to pin one node indefinitely.

A proxy group can point to another proxy group. For example, “Web Access” might select “Auto,” which in turn selects a node. To find the actual outbound, follow the entire chain rather than relying on the name of the outermost group. In a profile, DIRECT means a direct connection and REJECT means the request is rejected; neither is a proxy server.

Latency tests are only a first-pass filter

Clicking “Test” usually checks connectivity or latency to a specified URL; it isn’t a full bandwidth test. If one node shows 80 ms and another 120 ms, that only means the first probe took less time under those test conditions. It doesn’t predict video performance or download speed in MB/s. These figures are examples to explain how to read the results, not measurements from this site.

If a test times out, first check the test URL, network conditions, and node status. Avoid repeatedly testing every node at high frequency: concurrent probes can add load and make it harder to judge your everyday experience.

Settings: Check system proxy, TUN, and mixed port

“Settings” or the main dashboard usually provides access to system proxy, TUN mode, and port settings. System proxy works for apps that follow the operating system’s proxy settings. TUN routes eligible traffic through a virtual network interface and requires the appropriate permissions; it may also conflict with routes set up by another VPN. For initial setup, test one traffic entry point at a time instead of changing multiple switches at once.

A mixed port accepts both HTTP proxy and SOCKS proxy connections on the same listening port. For example, the snippet below sets the local mixed port to 7890. This is an illustrative configuration, not a default port for every client or a complete profile with nodes and rules.

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

If your client is actually listening on 7890, you can explicitly specify the HTTP proxy in a terminal command to test the local proxy connection. Confirm the port first; don’t assume the example port is the one your client uses.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• HTTP response headers are returned: this request received a response through the specified proxy port. It doesn’t mean other apps are using the system proxy.
• Can’t connect to 127.0.0.1:7890: check that the core is running, then verify the actual port and listener settings.
• The local port connects, but the request still times out: check access to the destination, rules, DNS, and the upstream node. Repeatedly toggling the system proxy won’t help.

Connections: Check which rule matched a request

Use Connections to answer three questions: Did the request reach the core? Which rule matched? Which outbound did it use? Common fields include the destination domain or IP, destination port, network type, rule, proxy chain, and upload and download totals. Whether the process name appears depends on system permissions, core capabilities, and client implementation; a blank field doesn’t necessarily indicate a problem.

1. Open “Connections” and filter by destination domain first to reduce noise from background requests.
2. Open the destination in a browser and check whether a new connection appears. HTTPS requests commonly use destination port 443, but the port alone doesn’t identify the app.
3. Expand the connection details and note the matched rule, rule payload, and proxy chain.
4. If the result is DIRECT, check whether a direct-connection rule matched before assuming the proxy has failed.

After switching nodes, existing connections may keep using the old outbound. HTTP keep-alive connections, WebSockets, and streaming sessions can all remain open for a while. To test again, close the target app’s connections or close the relevant entries on the Connections page, then make a new request. “Close all connections” interrupts other downloads and sessions, so check what will be affected first.

An empty connection list doesn’t automatically mean the node is at fault. The app may not have made a new request, may be using cached content, may bypass the system proxy, or the request may have ended too quickly to remain in the current view. Make a clear new request and check the logs instead of repeatedly refreshing the list.

Logs: Find load and dialing errors by timestamp

Logs record events; they aren’t a full packet capture. Log messages vary across cores and clients, but the troubleshooting order is the same: check that the profile loaded, then check DNS, rule resources, and upstream connections. Common log levels include silent, error, warning, info, and debug. Available options depend on the core in use.

Reproduce one issue at a time

1. Open “Logs,” clear the display, or note the current time.
2. If your client lets you change the log level, start with info. Switch briefly to debug if you need more detail.
3. Visit the target site once, then copy the related errors and surrounding context from that time window.
4. When you’re done troubleshooting, restore your usual log level to avoid retaining excessive request details.

If you’re using mihomo, formerly the Clash Meta core, check whether the profile relies on extended fields. A similar-looking client interface doesn’t mean the cores have identical capabilities. Before reporting an issue, note the client version, core name, and core version. You can usually find them under “About” or in the core information area; “latest version” alone isn’t enough.

Getting started and troubleshooting checklist

Understanding what each page does can help you avoid toggling settings without evidence. The steps below are useful when a subscription has been imported but websites still won’t load:

1. Profiles: Confirm the intended profile is active, loaded without errors, and its proxy groups appear on the Proxies page.
2. Proxies: Use Rule mode, check the proxy group for the service you’re testing, and make sure you haven’t selected DIRECT or an unavailable member by mistake.
3. Settings: Check the system proxy or TUN entry point. For a terminal test, specify the actual mixed port.
4. Connections: Make a new request and check the rule and proxy chain. If there’s no entry, check the traffic entry point; if there is one, check the outbound.
5. Logs: Match the timestamps to your test and distinguish configuration parsing, DNS, and dialing errors. Change only one relevant setting at a time.

Proxies is where you choose an outbound; Profiles controls where your configuration comes from; Connections shows the route a request actually took; and Logs explains core events. First identify where the request stopped, then troubleshoot on the relevant page. This approach works even when you switch clients.