Clash Beginner FAQ: Subscription Import, Node Selection, and Connection Issues

Subscription

Subscription and configuration import

1. Why can’t a subscription link be used directly as a node?

A subscription link is a remote configuration endpoint, not a specific proxy node. After the client accesses it, it retrieves configuration data such as the node list, policy groups, rules, rule providers, and DNS settings. Once the import succeeds, the configuration should appear on the configuration page, while the proxy page should show the available policy groups and nodes.

The usual import process is to copy the Clash or Mihomo subscription URL provided by the service, then paste and download it on the client’s subscription or configuration page. A regular webpage URL, an account dashboard URL, or a subscription format intended for another client may not be readable by the current core. If the import reports a format error, first verify the type of link instead of immediately changing ports or enabling TUN.

2. Why are no nodes visible after importing a subscription?

First, confirm that the new configuration has finished downloading and has been set as the active configuration. Some clients can store multiple configurations, so successfully adding a subscription does not necessarily switch to it. Next, check whether the proxy page shows only policy group names. Nodes are often inside groups named “Node Selection,” “Manual Selection,” or a provider-specific name rather than displayed directly on the home screen.

If the configuration is enabled but the node count is still zero, check the client logs or configuration error message. Common causes include an expired subscription, a temporarily unreachable remote server, an empty response, an incompatible subscription format, or problems with YAML indentation and field structure. A manually written configuration must at least contain valid references between nodes, policy groups, and rules. For example, a policy group’s node name must exactly match the node definition:

proxies:
  - name: "Example Node"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "Node Selection"
    type: select
    proxies:
      - "Example Node"
      - DIRECT

rules:
  - MATCH,Node Selection

This snippet only illustrates the reference structure; it is not a complete configuration that can connect to an external network. Actual node parameters should come from a trusted configuration source.

3. Will updating a subscription overwrite choices already made?

A subscription update normally fetches the remote configuration again. Whether nodes, policy group structures, rules, and DNS settings change depends on the new content returned by the server. Clients differ in how they remember policy group selections: if the group and node names remain unchanged, the previous choice may continue to apply; if a node is removed or renamed, it must be selected again.

Be careful when editing the YAML downloaded from a subscription directly. The next update may replace the local content with the remote version, removing manual changes. For custom rules that need long-term maintenance, use the client’s supported override, merge-configuration, or scripting features, and keep a separate backup. After updating, check the active configuration, key policy groups, and rule mode rather than relying only on an “update successful” message to confirm connectivity.

Selection

Nodes, policy groups, and proxy modes

4. Does the node with the lowest latency always deliver the fastest real-world speed?

A latency test measures the time taken by one or more short connections from the client to a test target. It does not fully represent sustained downloads, video playback, or access across regions. Node performance is also affected by line congestion, egress bandwidth, packet loss, the destination’s location, the transport protocol, and local network quality. A node with slightly higher latency but less packet loss may be more stable in practice than a congested low-latency node.

When choosing a node, start with a latency test and then verify it against the real destination. For websites, check time to first byte and whether repeated page loads remain stable; for video, see whether buffering continues over time; for downloads, focus on sustained speed rather than a brief peak. If every node times out, check the subscription, network, and core status first. If only one node times out, that node may simply be unavailable.

5. Which should you use: Rule, Global, or Direct mode?

Rule mode matches the rules in the configuration from top to bottom. Once a domain, IP, process, or rule set matches, the connection is handed to the specified policy group, DIRECT, or REJECT. It is suitable for everyday use and makes it easy to send local services and frequently used sites in mainland China directly while routing selected destinations through a proxy.

Global mode usually sends every connection entering the core to the global policy group. It is useful for briefly verifying that a proxy node works or for comparison testing when a destination is not covered by the rules. Global mode does not mean every device and process will automatically enter Clash; traffic capture still depends on the system proxy, TUN, or the application’s own proxy settings.

Direct mode connects captured traffic to the destination without using a proxy node. It can help determine whether a problem is related to the proxy path. For everyday use, start with Rule mode and switch briefly to Global or Direct only when diagnosing a problem.

6. Why is traffic still not going through the proxy after selecting a node?

Selecting a node only chooses the exit for a particular policy group; it does not automatically send application traffic into Clash. At least one traffic-capture method is still required: enable the system proxy, enable TUN mode, or enter Clash’s HTTP or SOCKS listening address manually in the application.

Also confirm that the rules actually use the policy group you just changed. A configuration may contain several groups, such as “Node Selection,” “Auto,” “Media,” and “Final.” Changing the node in “Node Selection” may have no effect if a rule points to another group. In that case, open the connection log or activity view and find the matched rule, policy group, and final node for the target domain.

Traffic Capture

System proxy and TUN mode

7. Why do some apps still connect directly when the system proxy is enabled?

The system proxy mainly affects applications that honor the operating system’s proxy settings, including most browsers and some desktop software. Certain games, command-line tools, standalone updaters, and programs with their own network stack may ignore the system proxy and therefore bypass Clash. An application may also specify “direct connection” or a different proxy in its own settings, overriding the system configuration.

Start by opening the destination in a browser and watching the connection log. If browser traffic appears but a particular application produces no entries, the issue is usually whether that application honors the system proxy. Check the application’s own proxy options, or use TUN mode when necessary. If no application produces any entries, check whether the client core is running, whether the system proxy was applied successfully, and whether another program is using the listening port.

8. When should TUN mode be enabled?

TUN mode uses a virtual network interface to capture a broader range of IP traffic. It is useful for applications that do not read system proxy settings and reduces the need to configure each application individually. It is not something that must be enabled immediately after installation. If browsers and commonly used software already work through the system proxy, keeping the simpler system-proxy setup makes the configuration easier to understand and troubleshoot.

Enabling TUN often requires system permissions and may create routing conflicts with other VPNs, virtual network adapters, security software, or enterprise network clients. If the network stops working, check whether TUN started successfully, whether the default route is correct, whether DNS is available, and whether another network-capture tool is running at the same time. Disabling other network-control software and testing again can help identify the source of the conflict.

TUN sends traffic into the core; whether it is ultimately proxied is still determined by the current mode and rules. Therefore, seeing some connections use DIRECT after enabling TUN is not necessarily a problem—they may have matched a direct-connection rule. During diagnosis, check the rule name and final route in the connection details rather than looking only at the TUN toggle.

Troubleshooting

Basic connection troubleshooting

9. The node test passes, but websites will not open. What should you check?

A measurable node latency only shows that a particular test request received a response; it does not guarantee that the entire route to the target webpage is working. Check the following in order:

1. Confirm that traffic is entering the core. Open the connections page or live log, then visit the target website. If no new entry appears, check the system proxy, TUN, or application proxy settings first.
2. Confirm the matched rule. Check whether the target domain ultimately uses DIRECT, PROXY, or REJECT, and confirm that the corresponding policy group has an available node selected.
3. Switch nodes for comparison. Change only the node within the same policy group; do not modify DNS, the mode, and the configuration at the same time. If another node works, the original node or its egress route is more likely to be the problem.
4. Compare Rule and Global modes. If Global mode works but Rule mode does not, inspect rule matching, policy group references, and rule-set updates.
5. Check DNS. Failed domain resolution, an unexpected address, or a resolution path that conflicts with proxy rules can all make a website appear unreachable. Compare access by domain with a connection to a known IP, but do not treat a temporary IP as a long-term fix.
6. Check the destination service. If only one website is affected, the site may be under maintenance, region-restricted, affected by account status, or rejecting the egress IP.

If the log shows a timeout, determine whether it occurred while connecting to the proxy server, querying DNS, or connecting from the proxy server to the destination. These are different stages and require different fixes. The browser’s final error page alone is usually not enough to identify the cause.

10. How can you quickly restore connectivity after a restart?

First check that the client core has started, rather than only confirming that the window is open. Then verify that the active configuration still exists and is enabled, the subscription has not become empty, and the main policy groups contain usable nodes. After a system restart, the system proxy may not have been enabled automatically. If you rely on TUN, confirm that the permission prompt, service component, and virtual network adapter are all functioning normally.

Use a “minimum variables” recovery process: temporarily disable TUN and enable only the system proxy; choose a configuration recently confirmed to work; use Rule mode; manually select a working node in the main policy group; then test in a browser while watching the connection log. Once this combination works, restore automatic selection, TUN, custom DNS, or override settings one at a time.

If the client cannot start the core, check the error log for a port conflict, configuration parsing failure, or insufficient permissions. When a port is occupied, avoid repeatedly changing several listening ports; first quit other proxy software and restart the client. If configuration parsing fails, switch to a working configuration or undo the most recent override. For permission issues, follow the operating system’s instructions to authorize the TUN service or network extension.

Checklist

First-use checklist

After installation and subscription import, verify the following in order. If one item fails, fix it before moving on to more complex DNS or routing changes:

1. The client core is running, with no configuration parsing errors.
2. The subscription has been downloaded and its configuration is set as the active configuration.
3. The proxy page shows policy groups, and those groups contain nodes.
4. At least one node passes a latency test or completes a real connection.
5. Use Rule mode for everyday traffic first, and confirm the selections in the main policy groups.
6. Enable the system proxy and run the first connection test in a browser.
7. Use the connection log to confirm the target domain, matched rule, and final exit.
8. Consider enabling TUN only if an application ignores the system proxy.
9. Recheck policy groups after a subscription update so that renamed nodes do not invalidate your selection.
10. When a problem occurs, save the relevant logs and investigate in this order: traffic capture, rules, node, DNS, then the destination service.

Once these layers are clear, problems such as “the selected node has no effect,” “the browser works but the game does not,” and “Global mode works while Rule mode fails” can be broken down into verifiable steps. Clash is not controlled by a single switch; it is a processing chain made up of the configuration source, traffic entry point, rule matching, and exit node. Reviewing connection records and checking each layer is more likely to reveal the real cause than repeatedly reinstalling the client.