Clash Beginner FAQ: Subscriptions, Nodes, and Proxy Modes Explained

1. Is Clash a node service, and where does the subscription link come from?

Clash, Clash Meta (now commonly referred to as mihomo), and graphical clients read configurations, apply rules, and forward connections. They do not provide nodes themselves, nor do they generate a subscription after installation. Your service provider creates the subscription link, usually under “Subscription,” “One-click subscription,” or “Import to client” in the service dashboard.

A subscription usually returns a YAML configuration or an encoded list of nodes. A complete Clash configuration may also include proxy groups, rule providers, DNS settings, and TUN parameters. A single node share link can be imported manually, but proxy groups and routing rules must then be configured separately.

Check these three things first

1. Make sure the service dashboard provides a Clash or Clash Meta format, not a format intended only for another client.
2. When copying, keep the full https://, path, query parameters, and token. Do not omit the final characters.
3. Open the service dashboard in a browser first to confirm that your account and subscription are still active. Do not mistake the login page URL for the subscription URL.

2. How should a subscription be imported, and why must it be updated afterward?

The labels vary slightly between graphical clients, but the workflow is much the same. In a typical interface, open “Subscription” → “New subscription,” paste the URL, enter a recognizable name, and choose “Save and update.” Other clients may use “Profiles” → “New” → “URL.” After a successful import, you should see an update time, the configuration filename, and the number of proxies.

“Save” only stores the address; “Update” actually requests the remote content. If the node list is empty after the first import, the most common reason is that the URL was saved without running an update. Set the automatic update interval within the range allowed by your provider—for example, once every 1,440 minutes. Updating every 5 minutes will not make the connection more stable and may trigger server-side rate limits.

Troubleshoot update failures in this order

• Check whether the error is 401 or 403. This usually means the token has expired, the account is in an abnormal state, or the request was denied.
• For a 404, copy the subscription address again and verify that the path and query parameters are complete.
• If the connection times out, disable the current proxy and try the update again. If the server cannot be reached directly, try updating through a working old configuration.
• If the update finishes but the node count is 0, check whether the download is an HTML webpage rather than YAML or a node list.
• For configuration parsing errors, check the line number in the logs. If the server returned incompatible fields, switch to the Clash Meta format or update the mihomo core.

3. The subscription imported successfully—why can’t I see any nodes?

First distinguish between “the subscription exists” and “the current configuration is enabled.” Many clients let you save multiple configurations but load only one at a time. Open “Subscription” or “Profiles,” select the configuration you just updated, then choose “Enable,” “Set as current,” or “Switch.” Next, open “Proxies” and check whether nodes appear in the policy groups.

If the configuration is enabled but there are still no options, it may define rules without proxies or proxy-providers. The proxy provider may also have failed to complete its initial fetch. For provider-based configurations, open “Proxy Providers” and update them manually, or search the logs for the provider name.

4. Why do all nodes time out, and how should latency numbers be read?

A latency test is more than a simple network probe to the node server. Clash typically requests a test URL through the node and measures the time from connection establishment to the response. A timeout can therefore occur anywhere along the path: the local network, the node entry point, the test site, DNS resolution, or the TLS handshake.

Start by testing three nodes individually instead of sending requests to dozens of lines at once. A common test URL is https://www.gstatic.com/generate_204, with the timeout initially set to 5,000 ms. If this address is unreachable on your current network, use the HTTP 204 test URL recommended by your provider; otherwise, every node may appear to time out at the same time.

How to interpret latency in practice

• 50 to 120 ms: Usually suitable for web browsing, instant messaging, and regular video.
• 120 to 250 ms: Generally usable, though real-time voice calls and remote desktops may feel less responsive.
• Over 500 ms: Test another line and check whether packet loss or frequent disconnects occur as well.
• Consistently 0 ms: Usually not a real result; the test may not have run or the interface may not have refreshed.
• All nodes show Timeout: Test the direct connection first, then check the system clock, DNS, core logs, and test URL.

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

For everyday use, beginners should start with Rule mode. It matches domains, IPs, processes, or rule sets from top to bottom, then sends each connection to the assigned policy group. Services in mainland China can connect directly, destinations that require a proxy use a node, and LAN or special addresses can be handled separately through the configuration.

If a website does not open in Rule mode, briefly switch to Global mode as a test. If Global mode works, the node itself is probably fine; check which rule matched the domain. If Global mode also fails, continue checking the node, DNS, and the destination site. Switch back to Rule mode when testing is complete so that all connections do not remain concentrated on one node.

Rule-match details in the logs are essential. Temporarily set the log level to info, revisit the destination, and see whether the domain ends up at DIRECT, REJECT, or a proxy group. There is no need to keep debug enabled after troubleshooting; verbose logs can quickly increase file size.

6. What is the difference between system proxy and TUN mode?

A system proxy writes HTTP and SOCKS proxy addresses into the operating system. Browsers and applications that follow system proxy settings send their connections to Clash, such as through the commonly used mixed listener 127.0.0.1:7890. It is simple to configure and easy to toggle, but some games, command-line tools, store apps, and software with its own network stack may ignore the system proxy.

TUN mode creates a virtual network interface and uses routing to capture more TCP, UDP, and DNS traffic. It is useful for applications that cannot be configured manually, but the operating system must grant permission to create a virtual network adapter and modify routes. Windows clients typically require service mode to be installed first; macOS asks for network extension permission; Linux needs the appropriate network management capabilities.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

The structure above is a common TUN configuration in mihomo. The fields that work in practice depend on the core version and how the client manages them. When a graphical client already controls these parameters, enable TUN through “Settings” → “Network Settings” → “TUN Mode” rather than maintaining two conflicting copies in the interface and subscription overrides.

Guidance for beginners

• Only need a browser and regular desktop apps? Start with the system proxy.
• Games, terminals, or specific apps ignore the system proxy? Enable TUN instead.
• Lost network access after enabling TUN? Turn TUN off, restore connectivity, then check service mode, routes, and DNS logs.
• Some clients can manage the system proxy and TUN together, but do not install multiple tools that try to take over routing at the same time.

7. What do ports 7890, 7891, and 9090 do?

Ports are the entry points local programs use to connect to the Clash core. In the configuration, mixed-port: 7890 accepts both HTTP and SOCKS proxy connections, making it suitable for most desktop clients. Older configurations often place HTTP on 7890 and SOCKS on 7891. external-controller: 127.0.0.1:9090 is used by graphical interfaces to control the core; it is not a proxy port for ordinary applications.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

If an application asks for a proxy address, use host 127.0.0.1 and mixed port 7890. Do not enter 9090 in browser proxy settings. To share the proxy over a LAN, explicitly enable allow-lan, configure the listen address, and restrict sources in the system firewall. For local-only use, leaving it disabled is easier to manage.

If startup logs show address already in use, another process is already listening on that port. Open “Settings” → “Preferences” and change the mixed port—for example, from 7890 to 7893—then restart the core. Afterward, also update the proxy port manually configured in browsers, terminals, and other applications.

8. The browser works—why do other apps still connect directly or lose network access?

A working browser only shows that the browser’s connections are reaching Clash; it does not mean all traffic on the device is being captured. First check whether the browser has a separate proxy extension installed. If the extension points directly to 127.0.0.1:7890, the browser may continue using Clash even with the system proxy disabled, while other applications connect directly.

Check by application type

1. Regular desktop apps: Check whether the client correctly wrote the address and port under “System Settings” → “Network & Internet” → “Proxy.”
2. Command-line tools: Confirm whether the tool reads the HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables.
3. Games and UDP apps: A system HTTP proxy usually cannot cover them; use a node that supports UDP and enable TUN.
4. Windows Store apps: Some UWP apps are affected by loopback restrictions and require a loopback exemption for the target app.
5. Virtual machines and containers: Their 127.0.0.1 points to the virtual environment itself, not directly to the host.

During troubleshooting, open the client’s connection list and make a new request in the target app. If the list contains no matching domain or process at all, the traffic has not entered the core. If a connection appears but fails, check the matched rule, node, and DNS. This helps distinguish a traffic-capture issue from a proxy issue.

9. Why are rules not taking effect, and where should custom rules go?

Clash evaluates rules from top to bottom in configuration order and normally stops after the first match. Put more specific custom rules before broad rules, and always before the final MATCH rule. Adding rules after MATCH has no effect.

rules:
  - DOMAIN,api.example.com,Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN matches a complete domain name, while DOMAIN-SUFFIX matches the suffix and its subdomains. IP-CIDR is used for network ranges; the trailing no-resolve means the domain should not be actively resolved to obtain an IP during matching. The policy name at the end of a rule must exactly match a group name in proxy-groups, including capitalization and spaces.

Subscription updates often overwrite the original YAML, so editing the subscription file directly is unreliable. Clients that support overrides usually provide a “Subscription” → “Override” or “Profiles” → “Merge configuration” entry, allowing custom rules to be inserted before remote rules. Save and reload the configuration, then verify the actual matches in the connection logs.

10. How can you confirm the proxy is working, and what should you do before quitting?

Do not rely only on the client toggle to confirm that connections are working. First record your current exit information in Direct mode, then switch to Rule mode, select a node, and reopen the test page. If the exit address and region change as expected and the client’s connection list shows the matching domain, the request has gone through the proxy.

Next, check DNS and rules. Open the client logs, visit one mainland-China site that should connect directly and one destination that should use a proxy, and confirm that they match DIRECT and the specified proxy group respectively. With Fake-IP, an application seeing a mapped address in the 198.18.0.0/15 range is normal; the core keeps the real domain mapping for rule matching.

Post-setup checklist

• The current configuration is enabled, and the subscription update time and node count look normal.
• The mode is set to Rule, and the target policy group has a working node selected.
• At least one of the system proxy or TUN is enabled and matches the application types in use.
• The connection list shows the target requests, and the rule-match results are as expected.
• The core logs show no ongoing port conflicts, DNS timeouts, or provider update failures.
• When closing the client, restore the system proxy and TUN routes as well to prevent the system from retaining an invalid proxy address.

If no webpages open after closing Clash, first check the system proxy settings and make sure the proxy toggle is off. If TUN behaves abnormally, quit the client and reconnect to the network; restart the system if necessary to restore routing. Before launching again, do not run multiple proxy clients listening on 7890 or taking over the default route.

For beginner troubleshooting, follow a fixed order: check the local network, confirm the subscription updated, verify that the configuration is enabled, test node connectivity, confirm the mode and policy group, and finally check whether the system proxy or TUN is actually capturing the application. Change one variable at a time and verify the result in the connection list and logs; this is usually faster than repeatedly reinstalling the client.