Clash Client Interface Guide: What the Proxies, Profiles, Connections, and Logs Pages Do

Separate the client, configuration, and core

Clash Plus, Clash Verge Rev, FlClash, and similar desktop applications are client shells. They provide the interface, manage configuration, and call the proxy core. The Mihomo core usually handles rule matching, DNS resolution, connection forwarding, and TUN interception. Sidebar icons, menu labels, and their order vary by client, but the main responsibilities remain the same: the Proxies page determines which policy handles traffic, Profiles determines which rule set is loaded, Connections shows active sessions, and Logs records how the core processes them.

Once these roles are clear, the workflow is straightforward: import and enable a subscription in Profiles, confirm the mode and policy-group selection in Proxies, enable the system proxy or TUN, then verify the result in Connections and Logs. Repeatedly switching nodes in Proxies without checking the active profile and traffic interception method is one of the most common ineffective habits for beginners.

Interface area	Primary objects	Common actions	What it does not handle
Proxies	Modes, policy groups, and nodes	Choose nodes, switch policies, test latency	Update subscription content
Profiles	Local YAML, remote subscriptions, proxy providers	Import, update, and enable profiles	Determine which rule matched an individual connection
Connections	Current TCP and UDP sessions	View destinations, rules, proxy chains, and traffic	Maintain complete long-term diagnostic records
Logs	Core runtime events	Check DNS, rules, dialing, and configuration errors	Replace a subscription editor
Settings	System proxy, TUN, ports, and core options	Determine how applications intercept traffic	Replace policy-group selection in Proxies

Proxies: Modes, Policy Groups, and Node Selection

The Proxies page is more than a simple server list. It displays the proxy-groups defined in the configuration, with each group serving a specific purpose. For example, “Node Selection” may be a manual group, “Auto Select” may use url-test, and “Failover” may use fallback. The path used by a connection depends on the operating mode, the matched rule, nested policy groups, and the current selection.

What the three operating modes do

Rule: Matches configuration rules from top to bottom. A domain may match DOMAIN-SUFFIX, an IP address may match IP-CIDR, and unmatched traffic ultimately reaches MATCH. This is the most common mode for everyday use.
Global: Sends most connections through a global policy group instead of routing them individually through the regular rules. It is useful for temporarily checking whether a site works through a specific node, but it is not a good long-term replacement for rule-based routing.
Direct: Usually sends connections straight to their destinations without using proxy nodes. It is useful for comparing local connectivity, but after enabling it, application traffic may still show DIRECT even when a node is selected in Proxies.

If a website always connects directly, first check whether the page header or settings area is set to Direct. If every site uses the same node, check whether Global was selected by mistake. Clients generally restore the previous state after restarting, so troubleshooting should not rely on memory alone.

Policy-group types determine how selections work

Group type	Interface behavior	Best for
`select`	Lets the user choose a node or another policy group manually	Fixed regions, fixed routes, and manual control
`url-test`	Automatically selects based on latency to a test URL	Choosing the fastest responder among similar nodes
`fallback`	Prefers the first available node in the list	Switching to a backup route when the primary fails
`load-balance`	Distributes connections according to configured policies	Spreads connections across multiple nodes; it does not add their bandwidth together

Latency values only show the response time for the test URL during that particular check. An 80 ms node is not necessarily faster for downloads than a 120 ms node: real-world speed also depends on egress bandwidth, packet loss, the destination’s location, and congestion. A failed test does not always mean the node is unusable. A blocked test URL, failed DNS lookup, or an outdated provider can also result in a timeout.

Profiles: Importing, Updating, and Enabling Subscriptions

Profiles manages the complete set of runtime inputs. A remote subscription is usually downloaded as a Clash YAML configuration containing ports, DNS settings, nodes, policy groups, rules, and rule providers. Some services return only a generic Base64 node list, which may not be directly parseable in Clash Profiles. If import reports a format error, or only nodes appear without rule groups, verify the subscription format first.

A successful import does not mean the profile is enabled

Most clients can store multiple profiles at once. After importing a new subscription, click its profile card, radio marker, or “Enable” button to make it active. To confirm the switch, return to Proxies and check whether the policy-group names changed, or look in Logs for a profile reload entry. If the old and new subscriptions contain groups with the same names, do not rely on the Proxies heading alone—check the selected marker and update time in Profiles.

Open the “Profiles” page.
Paste the complete URL beginning with https:// into the subscription field.
Click “Import,” “Download,” or the plus button, then wait for parsing to finish.
Select the new profile card and make it the active profile.
Click the update button and confirm that the update time changes.
Return to Proxies and check that the expected policy groups and nodes appear.

The boundary between automatic updates and local edits

A common automatic update interval is 24 hours, though some clients support 6-, 12-, or 48-hour intervals. The update time only shows that the client attempted to fetch the subscription; it does not mean the upstream content changed. For a 401 or 403 response, check whether the subscription has expired and whether its authentication parameters are complete. For a timeout, continue by checking DNS, the current network, and reachability of the subscription domain.

Be careful when editing YAML generated from a remote subscription. The next update may replace local changes with the remote version. To preserve custom rules, copy the profile locally or use the client’s override, script, Merge, or Mixin features. The relevant option may be under “Profiles” → “Overrides” or “Settings” → “Profile Management.” Keep a working copy before editing so you can roll back after a syntax error.

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Node Selection

In the example above, mixed-port: 7890 means that HTTP and SOCKS inbound connections share port 7890. This is only a common setting, not a fixed value. The actual port shown in the client’s Settings page takes precedence over tutorial screenshots. When configuring a browser, terminal, or other application manually, read the active runtime configuration instead of assuming every client uses 7890.

Connections: Confirm Where Traffic Actually Goes

Connections provides the clearest evidence of what is happening at runtime. It typically shows the source address, destination host, destination IP, network type, upload and download amounts, matched rule, policy group, and proxy chain. Opening a web page can create multiple connections at once: the main document, images, scripts, fonts, and analytics endpoints may use different domains. Seeing a dozen sessions in the list is therefore not unusual.

Four fields to check first

Host or destination domain: Confirm that the connection belongs to the application you are investigating. If only an IP address appears, the application may be connecting directly by IP, or domain sniffing may not have produced a result.
Rule: Shows the matched rule type, such as DOMAIN-SUFFIX, GEOSITE, IP-CIDR, or MATCH. The rule payload is usually shown in a neighboring field.
Chains: Shows the path from the policy group to the final exit, such as “International Sites → Auto Select → HK-01.” A final value of DIRECT means the connection is direct; REJECT means the rule denied it.
Network: Distinguishes TCP from UDP. Web pages mostly use TCP or UDP-based QUIC, while voice calls, games, and DNS may also create UDP sessions.

When troubleshooting rules, clear the filters first, then enter the target domain in the search box. Reopen the website and inspect the new connections. If traffic expected to use a proxy matches DIRECT, check the rule order: Clash normally evaluates rules from top to bottom, and the first match wins. A custom rule placed after a broad direct rule will not run, even if its syntax is valid.

Connections can also confirm whether a node switch took effect. Suppose the old chain was “Node Selection → JP-01.” After switching to SG-02, existing long-lived connections may still show JP-01, while new connections show “Node Selection → SG-02.” This is normal connection reuse. Clicking “Close All Connections” interrupts active sessions, affecting downloads, remote terminals, and online meetings as well.

Logs: Trace a Symptom to the Failing Component

Logs records core startup, configuration loading, DNS queries, rule matching, proxy dialing, and error events. Connections answers “where did this traffic go?” while Logs answers “why was the connection not established?” Keep the level at info during normal troubleshooting. Switch temporarily to debug only when regular logs are insufficient, then restore info after finding the cause.

Common log keywords and what to do next

Log excerpt	Usually means	Next step
`connection refused`	The destination port actively refused the connection	Check the node address, port, and service status
`i/o timeout`	The connection or read did not finish within the time limit	Switch networks or nodes; check packet loss and destination reachability
`no such host`	The domain could not be resolved	Check DNS settings, upstream servers, and network permissions
`address already in use`	The listening port is already occupied by another process	Close the process using it or change the mixed, HTTP, or SOCKS port
`proxy provider` update failed	The proxy provider file was not fetched successfully	Check the provider URL, update interval, and access path
YAML line or field error	The configuration syntax or field structure could not be parsed	Return to Profiles and restore a copy, then check indentation and field nesting

Before sharing logs for help, check whether they contain a subscription URL, node server address, authentication parameters, LAN IP address, or visited domain. Instead of pasting an entire page, keep roughly 20 to 50 lines from before and after the failure, and include the time of the incident, client name, core version, operating mode, and interception method.

Settings: How the System Proxy, TUN, and Ports Work Together

Selecting a node in Proxies does not by itself send traffic through the core. The system proxy and TUN are two common interception paths. With a system proxy, the client points the operating system’s HTTP, HTTPS, or SOCKS proxy to a local port, and browsers or other applications that follow system settings use it. Terminal tools, games, and some independent network stacks may ignore the system proxy.

TUN mode uses a virtual network interface to intercept a broader range of traffic. It works well for applications that ignore system proxy settings, but depends more heavily on system permissions, routing, and DNS configuration. On Windows, enabling TUN may require administrator privileges or service mode. A client can coordinate the system proxy and TUN, but during troubleshooting, identify which one is active instead of changing multiple variables at once.

Local ports to remember

7890: A common mixed port that accepts both HTTP and SOCKS connections; use the value shown in Settings.
7891: Used as a SOCKS port by some older configurations, but newer configurations may assign ports differently.
9090: A common external controller port used by the client interface to connect to the core control API. It is not the proxy port to enter in a browser.
53: The standard DNS port. TUN and enhanced DNS configurations may handle queries through an internal listener or forwarding, so the port number alone cannot confirm that DNS is working.

If the client says it is running but websites do not open, use “Settings” → “Port Settings” to verify the mixed port, then check that the system proxy points to 127.0.0.1 on the same port. If Logs shows address already in use, the port failed to bind. Even with the system proxy switch enabled, applications cannot pass requests to the core in that state.

A reliable daily workflow

Once the interface is familiar, there is no need to inspect every page each time. Normal use can follow a fixed sequence; when something fails, trace the traffic path layer by layer.

Profiles: Confirm the subscription update time and active profile. After a subscription change, update it first, then check whether new policy groups appear.
Proxies: Use Rule mode and choose the required policy group or node. Treat latency tests as an availability reference only.
Settings: Enable the system proxy or TUN according to the application, and verify the local listening port.
Connections: Open the target website, filter new sessions by domain, and inspect the rule and proxy chain.
Logs: When a connection is not established, search by time for DNS failures, timeouts, refused connections, or configuration errors.

If a browser works but terminal commands connect directly, first check whether the terminal reads the system proxy, or use TUN instead. If no application creates connection records, check the system proxy, TUN, and port binding. If Connections shows a record whose chain is DIRECT, return to the proxy mode and rule order. If the chain reaches the selected node but still times out, check node reachability, DNS, and the destination site’s status.