Check the interface, core, and traffic entry point first

Clash GUI clients display configuration, switch policies, and control the system proxy; the core handles rule matching and traffic forwarding. Menu names vary across Clash Verge Rev, ClashX, and mobile clients. This guide groups features into five areas: Proxies, Profiles, Connections, Logs, and Settings. Your client may use different labels, so look for the function rather than an exact button name.

When you first open the client, check the core status on the home or settings page, then confirm that the active profile loaded successfully. An open window only means the GUI started. If the core failed to start, a port is in use, or the configuration has a parsing error, an old list of nodes on the Proxies page does not prove that traffic is being forwarded correctly.

Interface areaWhat to checkWhat it does not prove by itself
Home or overviewCore status, active profile, live trafficZero traffic is not necessarily a problem; there may simply be no requests
ProxiesProxy group names, selected options, test resultsLow latency does not mean every site is reachable
ProfilesActive profile, update result, parsing errorsA successful download does not mean the profile is active
ConnectionsDestination, matched rule, policy chainAn empty list does not automatically point to a node problem
LogsTime, level, error contextOne error does not mean every connection has failed

Proxies: proxy groups, nodes, and operating modes

Check the group name, then its options

The Proxies page usually displays cards for each proxy group. A card title matches a name under proxy-groups in the configuration. Its options may be individual nodes, other proxy groups, or built-in policies such as DIRECT. Subscription labels like “Auto,” “Manual,” or “International” are just group names. Check the group’s type to understand its behavior rather than guessing from its label.

  • select: Manual selection. After you choose an option, new connections using this group will generally use it.
  • url-test: Automatically selects an option based on test results. Switching also depends on settings such as the test interval and tolerance.
  • fallback: Selects an available outbound according to the configured order; it does not simply pick the node with the lowest latency.
  • load-balance: Selects an outbound for each connection according to the configured balancing strategy. It does not combine multiple nodes to increase the bandwidth of a single download.

If a group points to another automatic group, selecting that group delegates the choice to it. When troubleshooting, expand the chain all the way to the final node. For example, “International → Auto → Node A” is more useful for reproducing an issue than simply noting that “Auto” was selected.

What Rule, Global, and Direct change

Use Rule for everyday rule-based routing. The core checks rules in order and sends traffic to the policy each rule specifies. Changing a group that the current request never matches will not change its outbound. Global sends traffic entering the core through the global policy; check which option that group selects. Direct connects traffic entering the core directly. Switching to Global does not automatically route apps that were not using the system proxy into the core.

  1. Set the mode to Rule on the Proxies page, then identify the group handling the destination traffic in your configuration.
  2. Open a manual group and select a specific node. Leave other groups unchanged.
  3. Close the existing test connection, make a new request, then check its policy chain on the Connections page.
  4. If an existing connection is still using the old outbound, close that test connection from the Connections page. There is no need to close every connection first.

Latency is only a single test result

The milliseconds shown on the Proxies page usually measure how long a probe takes to reach a specified test URL; they are not necessarily ICMP ping times. Test URLs, timeouts, and concurrency settings vary by client. If one test shows 85 ms and another 140 ms, that only means the first took less time under those test conditions—not that it will deliver faster video. A timeout can mean the test URL is unreachable, DNS failed, or the node handshake failed. Check the logs to tell these apart.

Profiles: importing, activating, and updating are separate actions

The Profiles page manages subscription URLs, local YAML files, and client-specific merge or override settings. To get started, import a valid configuration source, wait for it to finish parsing, and confirm that it is marked as active. Some clients activate a profile automatically after import; others require you to select its card or click “Use.” Check the active indicator and the group names shown on the Proxies page.

  1. Import: Open Profiles or Config, then choose Import from URL or import a local file. Subscription URLs may contain access tokens, so do not include them in public screenshots.
  2. Activate: Select the profile and wait for it to reload. Check the Proxies page to confirm that its configured groups appear.
  3. Update: Update the subscription and check the timestamp and result. After the new content downloads, make sure there are no configuration parsing or reload errors.
  4. Roll back: Keep a working local copy before making changes. If an error occurs, restore the known-good configuration first, then compare changes one at a time.

“Remaining traffic” and “Expiration date” on a subscription card usually depend on information returned by the server. If these details are missing, the client may still be able to proxy traffic. If a quota is displayed, that does not guarantee the current connection will work. Local files typically do not include server-side subscription details, so check the file contents and loading status instead.

Avoid editing subscription content that will be overwritten

If you edit the YAML downloaded from a remote subscription, the next update may overwrite your changes. To keep custom rules, first check whether your client supports overrides, merges, or script processing, and confirm which profile they apply to. The supported formats vary by client, so do not paste a script from a different client. For a temporary test, make a local copy; it will not receive new nodes from the original subscription automatically.

Settings: check ports, system proxy, and TUN

The local port is the entry point between apps and the proxy core. The example configuration uses mixed-port: 7890, meaning the same port accepts HTTP proxy and SOCKS connections. Your installation may use a different port, so check the active settings. If you configure a proxy manually, use 127.0.0.1 as the host and the actual listening port. Do not enter the subscription server address as the local proxy host.

SettingHow to checkCommon misconception
Local listening portCheck mixed-port or the separate ports in the active configurationEvery client uses 7890 by default
System proxyAfter enabling it, check the system proxy address and portEnabling the switch covers every app
TUNCheck client support, permission prompts, and startup logsA lit switch means the route was installed successfully
Allow LANEnable only when another device needs to connectIt must be enabled for local use

On Windows 11, check the system proxy under Settings → Network & internet → Proxy. On macOS 13 and later, go to System Settings → Network → your current network service → Details → Proxies. Menus and permissions may differ on managed devices. If your browser still points to a local port that has closed after the client exits, connections will fail. Check for leftover system proxy settings instead of repeatedly updating the subscription.

TUN usually requires additional system permissions, a service component, or a network extension, depending on the client and operating system. For initial troubleshooting, verify the basic connection path with a browser and the system proxy first. Then investigate apps that do not honor system proxy settings. Changing TUN, DNS, and rules at the same time makes it harder to identify the cause.

Connections: check what a request actually matched

The Connections page helps you cross-check what you see on the Proxies and Logs pages. Common columns include the destination domain or IP, upload and download traffic, connection duration, matched rule, and policy chain. Some clients can also show the process, depending on permissions, platform, and process lookup settings. An empty process column does not necessarily mean the connection is faulty.

  • No destination listed: Make the request again and clear any page filters. If nothing appears, check whether the app is reaching the proxy entry point.
  • Connection shows DIRECT: Check the matched rule to confirm that a direct connection is expected. A selected node does not prove that this request will use the proxy.
  • Correct policy chain, but access still fails: Check DNS, handshake, and connection errors from the same time. If needed, test again with a specific node.
  • Outbound unchanged after switching nodes: Existing TCP or long-lived connections may continue using the old outbound. Close the test connection and establish a new one before checking whether the switch took effect.

A browser may connect to several domains to load one page—for example, the main content, images, and APIs may each match different rules. When troubleshooting, note the specific domain that failed. Do not treat one DIRECT connection as the route used by the entire page.

Logs: filter by level, then find the right time

The Logs page typically lets you filter by level or keyword, pause scrolling, and clear the display. Distinguish between a display filter and the core’s log level: switching the display filter to Debug cannot restore debug information the core never recorded. If your client provides a runtime log-level setting, change it there or set log-level in the active configuration.

LevelWhen to use itWhat to look for
infoRoutine monitoring and initial troubleshootingStartup, loading, and routine connection details
warningInvestigating issues that have not yet caused a complete failureThe components involved in a warning and what happened next
errorFinding a specific failureDestination, time, failure stage, and cause
debugBriefly reproducing a complex issueMore detailed processing information; switch back to info when done

Before reproducing the issue, note the time—for example, 14:32:10—then make one request to the destination and look for related domains in the seconds around it. If you see connection refused, check whether a service is listening at the address being contacted. A timeout only means a stage did not complete before the deadline; use the surrounding context to determine whether it occurred during resolution, connection, or handshake. If a 401 or 403 appears during a subscription request, check subscription authorization before changing routing groups.

Use a minimal configuration to map fields to the interface

This local example illustrates how the interface works and can be imported on its own in Clash or mihomo clients that support these basic fields. It only provides direct connections and contains no remote nodes; it is not a substitute for an actual subscription. Test with a separate local profile rather than overwriting the subscription in use.

interface-demo.yaml
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: Manual Outbound
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Manual Outbound
  • Profiles: After importing and activating the file, confirm that this local example is the active profile.
  • Proxies: The “Manual Outbound” group should appear with DIRECT as its only option.
  • Connections: New requests entering the core match the final MATCH rule, use “Manual Outbound,” and connect directly.
  • Logs: The base log level is info. If the client has a global override, the effective runtime value may differ from the file.

If another process is using port 7890, choose an available port in the client settings or test file, then update the app’s proxy settings to match. Many GUI clients merge global settings with subscription content, so check the actual listening port and operating mode in the interface rather than relying only on the original YAML in an editor.

Six checks for first-time setup

  1. Check the core: Confirm it is running without startup or configuration parsing errors.
  2. Check the profile: Import the subscription, confirm which profile is active, and check the group names on the Proxies page.
  3. Check the entry point: Start with the system proxy in your browser and note the actual local address and port.
  4. Check the selection: Use Rule mode and select an outbound in the group referenced by the destination’s rule.
  5. Check the connection: Make a new request and check its destination domain, matched rule, and final policy chain.
  6. Check the logs: Find errors at the same time, change one setting at a time, and test again.

Following this order helps distinguish between an inactive profile, an app that never reached the core, a rule that selected a direct connection, and an outbound connection failure. For help with installation or authorization, see the setup guide. For terms like proxy group, rule, and TUN, see the quick reference.