Clash Client Interface Guide: Proxies, Profiles, and Logs Explained

Start with three screens: Profiles, Proxies, and Logs

Profiles control what gets loaded, Proxies control where traffic goes, and Logs help explain what went wrong. For your first setup, follow this order: import a profile → enable it → choose an exit node → route traffic through the client → check the logs. This makes issues easier to isolate than flipping settings at random.

Clash is a common name for a proxy core and its client ecosystem, but not every client uses the same interface. Clients such as Clash Verge Rev and FlClash can use the mihomo core; older clients may have different menus and features. This guide uses common tab names and includes their English equivalents for reference. Button locations vary by client, so no single version's layout should be treated as universal.

Profiles: importing a subscription isn't enough—you also need to enable it

From subscription URL to active profile

A subscription is usually a URL provided by your service. Open “Profiles,” find the subscription URL field or “Import,” paste the URL, and start the import. Clients that support file imports may also let you select a local .yaml file. Once imported, you should see a profile card or entry.

1. Make sure the URL is a Clash- or mihomo-compatible subscription provided by your service, not an account management webpage.
2. Select “Import” and wait for the download and parsing to finish. If it fails, save the error instead of creating duplicate entries.
3. Select the profile card or choose its “Enable” or “Use” action.
4. Return to Proxies and check that the profile's groups and nodes appear. An import-success message alone doesn't confirm that the profile is active.

A profile appearing in the list doesn't mean the core has loaded it. Clients typically mark the active profile with a highlighted border, checkmark, or “In use” label. If the Proxies screen still shows the old content after switching, check for loading errors and make sure you selected the right entry.

What update, edit, and switch do

• Update: Fetches the remote subscription again, typically to sync new or unavailable nodes.
• Edit: Changes the saved content. Direct edits to subscription-generated files may be overwritten the next time you update.
• Switch: Loads another profile, which may also change its proxy groups, rules, and DNS settings.

Proxies: the mode controls matching; the proxy group controls the exit

Rule, Global, and Direct are modes—not proxy nodes

The “Rule,” “Global,” and “Direct” options on the Proxies screen are traffic modes. For everyday use, start with Rule mode, which lets the profile's rules decide whether a request goes to a proxy group or connects directly. Global mode sends requests to the global proxy selection and can be useful for brief comparison tests. Direct mode bypasses proxy nodes.

These modes only affect traffic that reaches the core. Even in Global mode, apps that don't use the system proxy or aren't routed through TUN may still connect directly. So if an app behaves the same after you select Global, the node may not be at fault. First check whether the app's requests are reaching the client.

After choosing a node, make sure it's in the group your traffic actually uses

Names such as “Auto,” “Manual,” and “Streaming” on the Proxies screen are usually defined by the profile author; they're not built-in client features. A select group typically lets you choose manually; a url-test group picks based on test results; and a fallback group typically selects the first available entry. Groups can also refer to other groups, so a request may pass through several layers of group selection.

• First check which proxy group the rule uses, then open that group and choose a node.
• After selecting “Test latency” or a test icon, the number shows the response time for a specific test URL only.
• A reading such as 120 ms isn't a download speed and doesn't guarantee that every site is reachable. It's an example, not a live test result.
• After switching nodes, test with a new request. Existing long-lived connections may not move to the new exit immediately.

If there are many nodes but the expected group is missing, check which profile is active on the Profiles screen. Repeatedly switching nodes won't fix an unloaded profile, a rule pointing to another group, or traffic that never reached the core.

Settings: system proxy, TUN, and ports each handle a different layer

Start by testing your browser with the system proxy

Desktop clients usually offer a “System Proxy” switch under “Settings” or on the overview screen. It changes the operating system's proxy settings so apps that honor them send requests to the local proxy port. Browsers are often easy to test this way, but some games, command-line tools, and apps with their own network stack won't follow the system proxy automatically.

This is an example port, not a default for every client. mixed-port accepts both HTTP and SOCKS proxy connections on the same port. When configuring an app manually, use the listening address and port shown in your client.

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

If the actual port is 7890, local apps can use address 127.0.0.1 and port 7890. Don't confuse the proxy listening port with the external-controller port, which is for the management API—not for routing browser traffic.

TUN routes more traffic; it isn't a speed boost

TUN uses a virtual network interface and routing settings to capture traffic. The exact scope depends on the client, routes, and exclusions. Some desktop clients require a service to be installed or administrator privileges; mobile clients may establish a tunnel after you grant VPN access through the operating system. Test the system proxy first, then enable TUN if needed, so you don't introduce multiple variables at once.

“Allow LAN” is a separate setting that controls whether other devices can access the proxy listener on your machine. You usually don't need it for local use. If you do share access, check the listening address, firewall, and access controls—not just the toggle.

Connections: inspect what each request matched, not just the traffic graph

Open “Connections” and visit a site to generate a request. The client may show the domain, destination IP, upload and download totals, matched rule, and proxy chain. Find the entry created just now, then check whether it went through DIRECT, a node, or was blocked by REJECT.

1. No new entry: Check the system proxy, the app's own proxy settings, or TUN coverage. Also rule out page caching and filters on the Connections list.
2. An entry appeared but used a direct connection: Check the matched rule and traffic mode before switching nodes.
3. The expected node was used, but the request still failed: Open Logs and check for DNS, connection, or handshake errors from the same time.

Rules are usually matched from top to bottom, with MATCH at the end catching requests that didn't match earlier rules. Domain requests may not immediately create a new entry because of caching or connection reuse. To establish a fresh connection, close the relevant connection or restart the app. Closing all connections will interrupt active downloads and calls, so check the impact first.

Logs: keep the full error, then find which layer failed

The Logs screen shows core activity, not your browser history. Keep the log level at info while troubleshooting. Note when the failure happens, reproduce it once, then check the surrounding entries. Don't share just the last word in a red error line—the destination, port, and operation leading up to it matter too.

dial tcp only describes the operation context—attempting to establish a TCP connection. It doesn't identify the cause on its own. Read the address and error that follow, such as a timeout, connection refusal, or unreachable network. One timeout doesn't prove the entire subscription is broken; compare a different node and a different destination site.

If you need more detail, temporarily set the log level to debug, reproduce the issue, then switch back to info. Debug logs may include domains, IP addresses, and local paths, so redact them before sharing. For configuration syntax errors, preserve the line number, field name, and indentation rather than restarting repeatedly.

First-time setup: verify everything in six steps

1. Import from Profiles: Paste a compatible subscription, wait for the import to finish, and make sure the profile is enabled.
2. Choose a mode in Proxies: Select “Rule,” then choose an available node in the manual proxy group your rules actually use.
3. Route traffic in Settings: On desktop, start by enabling the system proxy. On mobile, follow the system prompts to authorize the VPN connection.
4. Send a browser request: Visit a specific page and check Connections for the new entry.
5. Check the route: Confirm that the rule, proxy group, and final node match your expectations. If there's an error, check the logs from the same time.
6. Expand only if needed: Consider TUN only if an app that doesn't follow the system proxy needs to use the proxy.

This sequence helps separate an inactive profile, the wrong proxy group, traffic that never reached the core, and a failed node connection. Change one setting at a time, send a new request, and check the result. For the next steps, see the subscription import guide and proxy mode guide. If you have a specific timeout error, see the timeout troubleshooting guide.