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

How the Interface Fits Together: Profiles, Proxy Groups, and Traffic Routing

When you open the Clash desktop client, keep three functions separate: Profiles loads configuration files; Proxies shows proxy groups and lets you choose an outbound route; system proxy or TUN mode sends app traffic to the core. A successful import only means the profile can be loaded—it doesn't mean your browser is using the proxy.

Menu labels and layouts vary across graphical clients such as Clash Verge Rev and Clash Nyanpasu. The sections below cover common sidebar functions; button locations in one client aren't universal. If your menu is in English, look for Profiles, Proxies, Connections, Rules, Logs, and Settings.

Page or setting	What it does	What it doesn't tell you
Profiles	Import, update, and activate a profile	An imported profile doesn't prove that its nodes are working
Proxies	View proxy groups, switch nodes, and run latency tests	A successful test doesn't mean every app is routed through the proxy
Connections	Inspect connections handled by the core and their rule chains	An empty list doesn't necessarily mean a node is down
Logs	Check core activity, rule matches, and errors	One warning doesn't mean the entire network is unavailable
System proxy / TUN	Choose how app traffic reaches the core	Enabling it still requires a valid profile and a working outbound route

Profiles: Import, Activate, and Update

After importing, check which profile is active

Open Profiles and paste your subscription URL using Import or the URL field. Once the download finishes, check which profile card is marked as active. Some clients activate imported profiles automatically; others require you to select the card or choose Activate from its menu. A file appearing in the list and the core actually loading that file are two different states.

Get a Clash- or mihomo-compatible subscription from your provider. Don't mistake an account page URL for a subscription link.
Check the profile name, last-updated time, and any error messages. If parsing fails, don't keep toggling the system proxy.
Activate the profile, then open Proxies and check whether its groups and nodes appear.
To refresh the nodes, use Update on the profile card and check the result.

Keep the original subscription separate from local changes

Refreshing a remote subscription may overwrite edits made directly to the downloaded file. To preserve custom rules, use the client's supported override, merge, or script mechanism, and check which profile it applies to. Support varies by client. When getting started, leave the subscription unchanged until you've confirmed a basic connection, then make changes one at a time.

Proxies: Modes and Proxy Group Selection

Understand Rule, Global, and Direct

Rule applies the policies in the active profile to choose a route. Global generally sends regular proxied traffic that reaches the core through the GLOBAL group. Direct connects that traffic without a proxy. Global mode doesn't capture apps whose traffic never reaches the core, so it doesn't mean every app is using a proxy. For most first-time users, Rule mode makes routing easier to inspect.

Check the group type and current selection

select: Manual selection. Choose a node or nested group; new connections will use that selection.
url-test: Automatically selects an option based on the configured probe URL, interval, tolerance, and other settings. The selection may change as probe results change.
fallback: Selects an available option based on candidate order and health checks; it doesn't simply pick the node with the lowest latency.
load-balance: Distributes connections according to the configured balancing strategy. Don't expect every request to use the same node.

Rules can point to different groups. For example, a browser request might match a Streaming group; changing only Default Proxy may not affect it. Check the matched policy chain on the Connections page first, then change the relevant group. Some groups point to another group, so expand them to find the final node.

A test button usually checks the response from a specific test URL; it isn't a download-speed test. If it shows Timeout, check whether the probe URL is reachable, whether the node works, and whether too many probes are running at once. Don't delete an entire profile based on one timeout.

Settings: System Proxy, Ports, and TUN

The system proxy uses a local listening port

Look for System Proxy and Ports in Settings; some clients put the system proxy toggle on the home screen or in the tray menu. The system proxy changes your operating system's proxy settings, which are used by apps that respect them. The actual port depends on the client and active profile—don't assume every app uses the same port.

For example, the configuration snippet below exposes a mixed port at 7890 on the local machine, accepting both HTTP and SOCKS proxy connections. This illustrates what the port means; it isn't a complete, importable profile:

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

If an app lets you set an HTTP proxy directly, and the port above is active, enter host 127.0.0.1 and port 7890. Terminal apps may not read the system proxy settings, and browser extensions can override them. If the browser works but the command line doesn't, check the app's own proxy settings first.

TUN provides another way to route traffic

TUN mode uses mechanisms such as a virtual network interface and routing to capture eligible traffic. It's often used for apps that don't follow the system proxy. It may require service mode or administrator privileges and can be affected by routes, DNS, and exclusions. If you can't find the toggle, check whether the client supports TUN and whether its service installed successfully. Allow LAN access is not the TUN switch.

Connections: Check Which Policy a Request Uses

The Connections page shows connections currently known to the core. Common fields include the destination domain or IP, destination port, bytes uploaded and downloaded, matched rule, and policy chain. Whether a process name appears depends on system permissions, core settings, and platform support; a missing process name doesn't mean the connection bypassed the proxy.

Note the domain you want to test, then visit it in your browser to create a new request.
Open Connections, search by domain, or look for the new entry.
Check the destination port—HTTPS commonly uses 443—then review the rule and policy chain.
If the chain ends in DIRECT, check the matched rule on the Rules page. If it ends in a node name, check that node's connection result.

After switching nodes, an existing TCP connection or app connection pool may keep using the old route. To verify the new selection, close the target connection and make another request. You don't need to clear every connection right away, which could interrupt downloads or calls in progress. Some clients can close connections automatically when you switch; understand which sessions this affects before enabling that option.

If the connection list is empty, first check whether the app sent a new request, whether the browser served it from cache, and whether the traffic reached the core. Only traffic handled by the core appears here. Assuming an empty list means the node is down can send troubleshooting in the wrong direction.

Rules: Check Match Order and Routing

Rules are usually evaluated in order, and the first match determines the policy. Use the Rules page to review loaded rules, search for domain rules, and check their order; direct editing may not be supported. If the view is read-only, make changes in the profile or a supported override instead of repeatedly clicking rules.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

In this example, example.com and its subdomains connect directly; unmatched requests go to PROXY. PROXY must be the name of a node or policy group defined in the complete profile—you can't copy the rule alone and omit its definition. MATCH is the catch-all rule. If it appears before other rules, those rules won't get a chance to match.

Profiles using rule sets may also show RULE-SET. The specific entries come from the linked rule provider, so check its update status too. To find out why a site connects directly, start with the actual match shown on the Connections page; it's more reliable than searching for the site name on the Rules page alone.

Logs: Trace the Stage Where an Error Occurs

Use info for everyday use and debug briefly when reproducing an issue

Common log levels include silent, error, warning, info, and debug. Change the level on the Logs page or in Settings, then confirm the core is using the new value. Some clients separate frontend and core logs; for network troubleshooting, check the core logs first.

info is usually sufficient for everyday use. To reproduce an issue, switch to debug temporarily, note the time, make one request, and inspect the nearby entries. Restore the previous level afterward to avoid accumulating excessive detail. Clearing the on-screen view doesn't necessarily delete log files from disk.

Common clues	Check first
`address already in use`	Whether another client instance or program is using the same listening port
`connection refused`	The destination address and port in the error, and whether the connection was refused by a local proxy entry point or a remote service
`timeout`	Whether the timeout occurred during DNS lookup, node connection, a test request, or access to the destination site
YAML parsing or profile validation error	Profile syntax, indentation, referenced names, and whether the core supports the fields

After a timeout, read the destination address and action described in the surrounding log entries. The right fix depends on whether the timeout is from an unanswered DNS query or a TCP connection to a node. When sharing logs, include the time, error type, and relevant context, but hide subscription tokens, passwords, and personal address information. A screenshot of just the last word usually isn't enough to diagnose the cause.

First-Time Setup Checklist

Follow this sequence to connect the pages described above. It works for a fresh install and for a basic check after moving to a different profile.

Profiles: Import and activate a valid profile, then confirm there are no parsing errors.
Proxies: Select Rule mode and confirm the outbound option in the group you'll actually use.
Settings: Check the local port and enable the system proxy. Don't add another traffic-capture method yet.
Connections: Make a new request and confirm that its destination and policy chain appear.
Logs: If the request fails, look for errors related to that request instead of changing several settings at once.

For help installing the client, importing a subscription, and setting up the system proxy, see the Getting Started guide. To understand how DNS, rules, and TUN work together, read Advanced Configuration. First identify where traffic enters and which rule determines its route; then adjust individual settings as needed. Each page in the interface has a clear role.