Clash Beginner FAQ: 10 Questions About Subscriptions, Modes, and Connection Status

Before You Start: Distinguish These Four States

A Clash client usually relies on four parts working together: the graphical interface, the Clash or mihomo core, configuration files, and system network settings. A window opening only confirms that the interface has started; a successful configuration import does not mean traffic is already being proxied. To verify initialization, check the configuration, nodes, proxy entry point, and an actual request in that order.

1. Configuration status: The current configuration file loads successfully in the core, with no YAML parsing errors or incompatible fields shown in the interface.
2. Policy status: Proxy groups contain usable nodes, and no manually selected policy group is left empty.
3. Traffic capture status: At least one of the system proxy or TUN mode is enabled, allowing application traffic to reach Clash's listening port.
4. Connection status: New entries appear in the connection list, the logs show rule matches, and target requests receive normal responses.

If you focus only on “started” or the tray icon, it is easy to confuse configuration, node, and system proxy problems. The ten questions below follow the order of actual use, and you can jump straight to the relevant section when troubleshooting.

Subscriptions and Configurations: Importing Is Not Connecting

Question 1: Why are there no nodes after importing a subscription URL?

A subscription URL is essentially a remote configuration endpoint. The client must access it, download the response, and parse it into proxy nodes, policy groups, and rules. If the import completes but the list is empty, common causes include an incomplete URL, an expired subscription, an unreachable subscription server on the current network, an HTML page returned instead of a configuration, or an unsupported response format.

Start by running a manual update once from the configuration or subscription management page, then check the update time and any error message. For a timeout, check connectivity between the current network and the subscription server. For a parsing error, make sure you imported a subscription URL rather than a login page, dashboard URL, or QR-code image link. Some services provide separate universal subscription, Clash configuration, and single-node links; desktop Clash clients generally need the entry explicitly labeled for Clash or Clash compatibility.

Also distinguish between “no nodes” and “no policy group selected.” Nodes may already exist in the configuration while the home page shows only policy groups. Open the Proxy or Proxies page and expand a specific policy group to view its members. If a policy group is generated dynamically by a rule provider, wait for the configuration download and parsing to finish before making a selection.

Question 2: Will a subscription update overwrite manual changes?

Usually, yes. A remote subscription update downloads a new configuration, so changes made directly to subscription-generated node names, rules, or DNS fields may be replaced the next time it updates. Clients differ in how they implement overrides, merged configurations, scripts, and configuration patches, but the basic principle is the same: remote configurations should contain updateable content, while local customizations belong in the override layer provided by the client.

Beginners should avoid heavily editing YAML at the outset. Keep the original configuration, confirm that basic connectivity works, and then add local rules using the client's features. If startup fails after editing, first check indentation, spaces after colons, list markers, and field nesting. YAML uses spaces to express hierarchy; tabs, full-width punctuation, and incorrect indentation can prevent the entire file from loading.

Nodes and Latency: Test Results Are Not Real-World Speed

Question 3: Is the node with the lowest latency always the fastest?

Not necessarily. Latency tests mainly measure how long it takes the client to complete a connection or request to a test target, making them useful for checking whether a node is online and responsive. Download speed also depends on the node's exit bandwidth, line congestion, cross-network routing, target-site throttling, protocol overhead, and local network quality. A congested node with latency of a few dozen milliseconds may deliver less throughput than a slightly slower but more stable route.

When choosing a node, use three steps: remove nodes that time out, make real web or file requests through the low-latency candidates, then watch for frequent dropouts over time. Games, remote terminals, and real-time calls prioritize latency and jitter; video and large downloads prioritize sustained throughput; ordinary web browsing requires a balance of DNS performance, handshake speed, and stability.

A URL Test policy group can periodically test a fixed URL and select a better-performing node, but the result applies only to that target and that moment. A Fallback policy is designed more for failover, while a load-balancing policy may distribute different connections across multiple nodes according to the configuration. Behavior depends on the policy group type; “automatic selection” does not always mean simply choosing the lowest-latency node.

Question 4: Why won't a webpage open even though the node is shown as available?

A successful node test proves only that one test request can pass through that node; it does not prove that the browser request follows the same path. First, check whether the browser's domain appears in the connection list. If there is no record at all, the problem is usually in the system proxy, the browser's independent proxy settings, or the TUN capture layer. If there is a record, inspect the matched rule, final policy, and error message.

It is also possible for the test URL to be reachable while the target website is not. The target domain may be assigned DIRECT by a rule, the policy group may have selected another node, or the DNS result may not match the connection path. Switching briefly to Global mode can help isolate the issue: if Global works but Rule mode does not, check rule matching and policy groups; if neither works, check the node, DNS, system time, and local network first.

Rule Mode and System Proxy: Identify the Traffic Entry Point

Question 5: What is the difference between Rule, Global, and Direct modes?

Rule mode evaluates requests against the configured rules one by one—for example, by domain, IP, process, or rule set—to decide whether to connect directly, reject the request, or send it to a policy group. It is the most common mode for everyday use, provided that the configuration's rules and policy groups are complete and working.

Global mode usually sends every request entering Clash to the global policy group. It is useful for temporarily verifying whether a node works. It does not mean that every piece of traffic on the device automatically enters Clash; traffic must first pass through the system proxy, an application proxy, or a TUN interface.

Direct mode lets requests that have already entered Clash connect to their destinations without using a proxy node. It is useful for testing whether a proxy node is causing the problem, or for keeping Clash in control while stopping node forwarding. Direct does not mean the client has fully exited, because DNS, listening ports, and connection records may still be handled by the core.

For troubleshooting, use this simple comparison: if Rule mode fails but Global mode works, focus on the rules; if Global mode also fails, focus on the node and traffic entry point; if Direct mode fails, the local network, DNS, or target service may also be at fault. Restore Rule mode after testing to avoid changing the expected traffic split long term.

Question 6: Why do some apps still connect directly after the system proxy is enabled?

The system proxy is a set of proxy settings that the operating system makes available to applications. Browsers and many desktop programs read these settings and send HTTP or HTTPS requests to Clash's mixed port or the relevant proxy port. However, not every application follows the system proxy. Some games, command-line tools, virtual machines, containers, and applications with their own networking stack establish connections directly.

After enabling the system proxy, confirm that the operating system's proxy address points to the local listening address and that its port matches the client's current port. If another program has taken the port, the core is not running, or listening failed after switching configurations, the system proxy may be enabled while traffic still cannot enter Clash. A browser's standalone proxy extension may also override system settings, so disable it temporarily before testing.

For broader coverage of TCP, UDP, or applications that ignore the system proxy, consider TUN mode. TUN creates a virtual network interface, allowing system routes to send more traffic to the core for processing, and it typically requires administrator privileges. Its coverage is broader, but it is also more likely to conflict with other VPNs, virtual network adapters, security software, and custom routes. Beginners should first make system proxy mode work, then enable TUN only when needed instead of changing several network settings at once.

Connection Failures: Check the Entry Point, Rules, Node, and Target in Layers

Question 7: What do timeout, connection refused, and DNS error in the logs mean?

timeout means that a network stage did not complete within the allowed time. It may occur while fetching a subscription, connecting to a node, establishing the target connection, or waiting for a response. It usually points to an unreachable route, severe packet loss, a slow target, or firewall interference, but a single timeout cannot identify the fault by itself. Use the target address, policy name, and connection path in the logs to narrow it down.

connection refused means that the target address explicitly rejected the connection. If the refusal occurs at a local port, the Clash core may not be listening on that port. If it occurs at the proxy server, the node service may be down or the port configuration may not match. If it occurs at the final destination, the target service may not have that port open.

A DNS error means that the domain-resolution stage did not return a valid result. Common causes include an unreachable DNS server, mismatched enhanced-mode settings, network interception of DNS requests, or a nonexistent domain. Do not simply keep switching nodes. First verify that the domain resolves on an ordinary network, then check the DNS switch, listening settings, and fields such as nameserver and fallback in the configuration. After changing DNS, reload the configuration and start a new connection; existing connections will not automatically use the new result.

Question 8: Why is the connection list still empty even though the system proxy is enabled?

An empty connection list means that the requests being observed have not entered Clash. First refresh a page you have never opened before so the browser cannot serve it directly from cache. Then check that the client core is running, the system proxy points to the correct port, and the operating system has no leftover proxy address from an older client.

If the browser uses a privacy proxy, extension proxy, or enterprise management policy, it may bypass the system proxy. Command-line tools may also use separate environment variables, such as HTTP and HTTPS proxy variables, that point to another port. If the connection list is empty in TUN mode, check whether the virtual adapter was created successfully, whether routes are active, and whether administrator permission was granted.

Also rule out an incorrect test setup from a local-area-network device. When Clash listens on the local address by default, other devices cannot connect to it directly. A phone or another computer can use the device as a proxy server only after the client allows LAN access, the listening address covers the LAN interface, and the operating system firewall permits the relevant port. Before exposing a LAN listener, make sure the network is trusted and restrict the accessible range.

Updates and Maintenance: Prevent Configuration Drift

Question 9: What should I do if the configuration will not load after updating the client?

The graphical client, core, and configuration specification are separate version concepts. Updating the client may also replace the core, or it may continue using the existing one; meanwhile, a subscription configuration may contain fields supported only by a particular core. If the configuration stops loading after an update, record the complete error line first and avoid changing several fields at once.

If the error points to an unknown field or policy type, confirm whether the current client uses the Clash, Clash Meta, or mihomo core and whether the configuration was generated for that core. mihomo carries forward and extends Clash Meta capabilities, but the core bundled with an older client may not support newer configuration options. If the error points to a YAML line number, inspect indentation, quotes, and list structure around that line, because the actual structural error may appear earlier.

Keep the recovery sequence consistent: back up the current file, switch to a known-good base configuration, verify that the core starts, and then update the subscription again. If the base configuration works but the subscription fails, focus on the subscription content or compatibility. If every configuration fails, check client permissions, core files, listening ports, and the upgrade process. This helps distinguish a configuration problem from an installation problem.

Question 10: How can I tell whether Clash is working correctly?

Do not rely on a single webpage as your verdict. Complete verification covers three layers: local status, proxy path, and traffic-splitting results. First confirm that the core is running, the configuration has no errors, and a node is selected in the policy group. Next confirm that the system proxy or TUN is enabled and that opening a webpage creates a new connection entry. Finally, check whether different requests match the expected rules—for example, local services use DIRECT while destinations requiring a proxy enter the designated policy group.

Use the checklist below to verify each item:

• The configuration page shows a recent update time, and a manual update returns no download or parsing error.
• The proxy page has at least one usable node, and the current policy group is neither empty nor pointing to an unavailable node.
• Rule mode is enabled, and the logs show the domain, matched rule, and final policy.
• Opening a new webpage changes the connection count, and upload and download traffic are no longer continuously zero.
• Disabling the system proxy changes the request path as expected, and enabling it again restores the connection.
• After restarting the client, the configuration still loads automatically and the system proxy state matches the client settings.

If all of these checks pass, the installation, configuration, node, and traffic entry point form a complete working chain. From there, addressing latency, fine-tuning rules, optimizing DNS, or resolving TUN compatibility will be more effective than repeatedly reinstalling the client.