Clash Client Interface Guide: Proxies, Profiles, and Logs

First, distinguish the client interface from the proxy core

A Clash client usually consists of a graphical interface and a proxy core. The interface imports subscriptions, displays proxy groups, and toggles the system proxy; the core reads the configuration, matches rules, and establishes connections. Menus vary between clients such as Clash Verge Rev and FlClash. Clients built on mihomo may also offer configuration options unavailable in the original Clash. A label that says “Clash” does not guarantee that every field and feature works the same way.

This guide covers common desktop client interfaces. “Proxies,” “Profiles,” and “Logs” refer to the corresponding feature pages; some clients call “Profiles” “Subscriptions.” Using a common Clash Verge Rev layout as an example, import a file from “Profiles” in the sidebar, choose a proxy under “Proxies,” then check the system proxy under “Settings.” Button names can vary by release, so follow the labels and effective configuration in your current version.

Proxies: modes, groups, and node selection

Rule, Global, and Direct are modes, not three nodes

The proxy mode determines how traffic is routed. rule checks rules in the configuration from top to bottom; global usually sends connections entering the core through the global policy; direct connects those incoming connections directly. For everyday, per-site routing, start with Rule mode. Switching to Global does not automatically capture traffic from apps that never send it through the client, and it does not enable TUN.

• Rule mode: Keeps your LAN and selected sites on direct connections while routing other destinations through a proxy.
• Global mode: Useful for briefly checking whether routing rules are causing a problem. Switch back to your original mode afterward.
• Direct mode: Useful for comparing against your local network, but traffic may still pass through the core’s DNS handling. It does not fully exit the client.

Find the proxy group referenced by your rules

A “node” is a specific proxy exit; a “proxy group” determines how an exit is selected. A group with type select lets you choose manually; url-test selects a route based on health checks; fallback selects according to availability and order. If the interface shows several proxy group cards, you do not need to change them all. First use the Connections page to see which group the destination matched, then change that group’s selection.

This configuration snippet illustrates how the interface components relate; it is not a complete subscription. The candidates in Manual Select include only DIRECT, so this group does not provide a proxy exit outside your local network. A real subscription references defined nodes or proxy providers here.

mode: rule
proxy-groups:
  - name: Manual Select
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,Manual Select
  - MATCH,DIRECT

In this configuration, requests to example.com and its subdomains match “Manual Select”; all other destinations match the final MATCH rule. Even if the interface shows other groups, switching them will not change the route for this request if no rule references them.

A latency test only measures its test destination

“Test latency” on the Proxies page usually means checking connectivity or latency to a specified URL, not measuring download bandwidth. A result of 80 ms, for example, reflects the test destination at that moment. It does not predict video loading speed or prove that every site is reachable. A timeout could also be caused by an unreachable test destination, DNS issues, or a faulty node; check the logs for context.

Profiles: import, activate, and update subscriptions

Importing a profile and activating it are separate steps

The Profiles page stores configuration sources that the core can load. Remote subscriptions usually provide YAML through a URL; local profiles are imported from files. Some clients support individual node links or other subscription formats, while others accept only Clash YAML. If parsing fails, check the format before repeatedly clicking Update.

1. Open the “Profiles” or “Subscriptions” page and paste the subscription URL into the URL field or the form for adding a remote profile.
2. Choose “Import” or “Download,” wait for the profile card to appear, and check for parsing errors.
3. Select the profile and look for an “Active” or “Enabled” label, or a selected-state indicator. A newly added card may not replace the current profile automatically.
4. Return to “Proxies” and check whether the expected proxy groups appear. If the old groups are still shown, check whether switching profiles failed.

Subscription URLs often contain access tokens and should be treated like credentials. When troubleshooting, share only the domain, status code, and error type—not the full URL in public comments. A QR code displayed by the client may contain the same credentials.

Updating a subscription is not the same as updating the client

“Update” on a profile card usually downloads the remote content again, refreshing nodes, rules, and proxy groups. A software update replaces the client; a core update replaces the proxy engine. These are separate tasks. If a protocol is unsupported, updating the subscription may not help—you may need to check whether the current core supports that protocol and its fields.

Edits to a remote profile may be overwritten the next time the subscription updates. For persistent changes to ports, DNS, or rules, use the client’s supported override, merge, or extension features. After saving, check the “Runtime Configuration” or “Effective Configuration”: a field in the source file may not retain the same value after the client merges the configuration.

• HTTP 401 or 403: Check the subscription credentials, service status, and access permissions first.
• HTTP 404: Check that the URL is complete and the path has not expired. Make sure you are using a subscription URL, not a webpage address.
• YAML parse error: Check indentation and field types, and make sure the server did not return an HTML error page.
• Download timeout: Check your local network and connectivity to the subscription domain. If the client can update through a proxy, make sure that proxy is working too.

Settings: system proxy, ports, and the TUN toggle

In the common Clash Verge Rev layout, the system proxy and TUN controls are in the relevant section under “Settings”; other clients may put them on the home screen. Look for the specific toggle name—do not confuse “Launch at startup” with “Proxy enabled.” Launch at startup only starts the app; service mode typically provides the system permissions needed to run the core.

The system proxy only works with apps that honor system settings

The system proxy points the operating system’s HTTP proxy setting to a local listening address. 127.0.0.1:7890 is an example, not a default port for every client. If mixed-port in the effective configuration is 7897, apps where you set the proxy manually should also use 7897—not copy 7890 from a tutorial.

# Local entry example, not a complete configuration
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port provides HTTP and SOCKS proxy access on the same port. allow-lan: false restricts LAN access. Letting other devices use your proxy also involves the listen address, firewall, and authentication; do not enable LAN sharing just to “see what happens.”

TUN captures more traffic

TUN uses a virtual network interface and routing to send more traffic through the core. It is commonly used for apps that do not follow the system proxy. TUN requires operating system permissions, a virtual network interface, and core support; it is not another name for the system proxy toggle. First make sure a regular browser works through the system proxy, then try TUN. If the network stops working, turn TUN off and confirm the basic connection is back.

Logs: filter by level and investigate errors

Distinguish the display filter from the log level

The Logs page shows core events; it is not a list of subscription nodes. Common levels include debug, info, warning, and error. The configuration can also use silent to disable routine log output. The interface’s level filter controls which received records are displayed; the core’s log-level setting controls which records are generated. If the core only outputs info and higher, selecting Debug in the interface cannot restore debug messages that were never generated.

info is fine for everyday use. To reproduce a complex issue, temporarily set the core log level to debug, reload the configuration, repeat the operation once, then restore the previous level. Debug logs may contain domains, IP addresses, and connection details. Remove subscription tokens, credentials, and any private browsing records before sharing them.

Tie each error to a specific action

1. Note the time—for example, 2:32 p.m.—then visit the affected site once.
2. Find the entries around that time on the Logs page, focusing on the destination domain, exit name, and error details.
3. Check the matched rule and proxy chain on the Connections page to confirm whether the expected node was used.
4. Change just one condition, such as the node, then visit the site again and compare the results.

An error message is a clue, not a diagnosis. For example, a timeout can occur at the proxy server or the destination site; one timeout does not mean the subscription has stopped working. Consider when it happened, how many destinations are affected, and the results of comparison tests.

Connections page and first-use checks

The Connections page is more useful than a latency test for answering “Where is this site’s traffic going?” Entries commonly show the destination domain or IP, upload and download amounts, matched rule, and proxy chain. Whether a process name appears depends on the platform, permissions, and core configuration. If an app is missing from the list, it may not have opened a new connection, or its traffic may not have reached the core. That alone does not mean the client is broken.

Verify your setup across four pages

1. Profiles: Confirm the intended profile is active and loads without errors.
2. Proxies: Select Rule mode and make sure the exit in the target proxy group is available.
3. Settings: Enable the system proxy and check the local port. For your first test, leave TUN off.
4. Connections and Logs: Visit the target site, check the new connection’s rule and exit, then review errors from the same time.

If your browser works but one app does not, first check whether the app follows the system proxy. If needed, configure an HTTP or SOCKS proxy for that app, then consider TUN. If no apps work, check that the profile loaded, the core is running, and the port is not in use before investigating nodes and DNS. Checking each page according to its role narrows down the cause more effectively than repeatedly replacing subscriptions or reinstalling the client.

Before exiting the client, check whether the system proxy has been restored. If the app crashes and your browser loses internet access, check the manual proxy setting in Windows under “Settings” → “Network & Internet” → “Proxy”; on macOS, check “System Settings” → “Network” → your current network service → “Details” → “Proxies.” Remove only local proxy settings left behind by the client; do not change proxy settings required by your workplace or school.