10 Common Clash Questions for Beginners: Subscriptions, Proxy Modes, Nodes, and Startup

1. Where do I get a Clash subscription URL, and can I import it as a configuration?

Your network service provider or configuration maintainer supplies the subscription URL. You can usually copy it from the subscription page in your account dashboard. Check that it provides a configuration compatible with Clash or mihomo—not a website login URL, purchase page, or node list in a format intended only for another client.

Check these three things before importing

• Content type: A complete configuration usually includes fields such as proxies or proxy-providers, along with proxy-groups and rules. A subscription containing only node resources must be used with a main configuration.
• URL validity: Subscriptions may depend on your account status, access token, or device limits. When copying the URL, make sure it doesn't include line breaks, spaces, or punctuation added by a messaging app.
• Format compatibility: If your browser returns a login or error page, it cannot be loaded as a YAML configuration, even if the HTTP request succeeded.

Subscription URLs often contain access tokens, so treat them like passwords. Don't post the full URL in public comments or submit it to an unfamiliar online conversion service. If you need help, redact tokens, account details, and node passwords; share only the error message and the relevant configuration structure.

2. Why didn't my subscription take effect, and what should I do if an update fails?

“Downloaded” doesn't mean “enabled.” In a typical Clash Verge Rev interface, adding a remote configuration on the Subscription page is only the first step—you also need to select it. Then check the Proxy page to see whether the proxy groups appear. If you still see old nodes, confirm that the newly imported configuration is the one currently enabled.

1. Run a manual update and note whether the failure occurs during download, parsing, or loading.
2. If the download fails, check whether the subscription has expired, whether your local network can reach its domain, and whether your system date is correct.
3. If parsing fails, check that the response is YAML and look in the logs for line numbers, indentation errors, or unsupported fields.
4. If loading fails, check the core logs. Unsupported node protocols or proxy groups that reference nonexistent names can prevent the configuration from working.

If you can download the subscription directly but updates fail through the proxy, switch to direct updates if the client offers that option. Conversely, if the subscription domain is reachable only through an existing proxy, keep a working configuration available while updating. Don't delete your only working configuration before verifying the new one.

3. Should I use Rule, Global, or Direct mode?

Use Rule mode for everyday browsing. Rules are evaluated in order and route traffic to a chosen proxy group, direct connection, or reject policy. Global mode is useful for short-term troubleshooting; Direct mode lets traffic handled by the core connect straight to its destination.

Global mode does not take over your entire device. Traffic that isn't routed through the system proxy or TUN won't be sent to the core just because you changed modes. You also need to choose a working node in the GLOBAL group; if the selected option is Direct, switching to Global may still connect directly.

If Rule mode fails but Global mode works, check the Connections list for the destination domain, matched rule, and actual policy chain. Look for an accidental match to DIRECT, a REJECT policy, or an incorrect outbound selected in the target proxy group—instead of repeatedly switching nodes.

4. How do I choose a node? Is lower latency always faster?

Latency measures the round-trip time of a particular test request. It doesn't tell you the bandwidth, long-term stability, or whether the target site will work. The latency shown by a client also depends on the test URL, timeout, and testing method, so results from different clients aren't directly comparable.

Compare nodes under the same conditions

1. Choose one target site and use the same network, client, and test address for each node.
2. Select 2–3 nodes in the same proxy group, then open a webpage and test the service you actually need with each one.
3. For download tests, use the same file and run each test for about 30 seconds. Watch for interruptions rather than comparing peak speeds alone.
4. If a service requires a specific region, check the exit region it actually detects rather than relying on the node name.

For example, if one node shows 80 ms and another 160 ms in a test list, that only shows a difference in latency for that test. It doesn't mean the first node will necessarily download faster. These figures illustrate how to compare nodes; they are not test results from this site. Beginners can start by selecting a node manually to keep the outbound consistent, then try the configuration's automatic selection or failover group once the issue is resolved.

5. A node times out or won't connect. What should I check first?

First determine whether all nodes fail or just one. If all nodes fail, check your local network, configuration, and whether the core is running. If only one fails, check the node status, account permissions, and protocol settings. A failed latency test doesn't necessarily mean every type of traffic will fail.

• All nodes fail: Make sure the client core is running, the subscription is still valid, the node server's domain resolves, and your system clock is accurate.
• One node fails: Update the subscription and try again. Check whether the provider has changed the address, port, or authentication details.
• Websites work, but a specific app doesn't: Check whether the app follows the system proxy, requires UDP, and matches the expected rule for its domain.
• Results differ between Wi-Fi and a mobile hotspot: Note the difference and check whether the current network restricts the destination port, protocol, or UDP traffic.

How to interpret common log errors

connection refused usually means the destination port rejected the connection. timeout means a step did not complete within the allotted time. no such host often points to a DNS resolution problem. For TLS or authentication errors, check the system clock, protocol settings, and account details. The stage where an error occurs is more useful for troubleshooting than a generic “no internet” message.

Don't permanently disable your firewall or bypass certificate checks to troubleshoot. If you need to allow traffic through the firewall, verify the program path and network scope, and grant only the permissions required. Redact subscription tokens, authentication fields, and sensitive browsing records before sharing logs.

6. What's the difference between the system proxy and TUN mode? Should I enable both?

The system proxy tells apps that follow system settings to use a local proxy port. TUN routes traffic through a virtual network interface and processes connections using routing and DNS settings. If your browser already works, there's no need to enable TUN just to get “more features.”

Some clients allow both, but for your first setup, enable only one traffic entry point. In a typical Clash Verge Rev interface, look under Settings for System Proxy and Virtual Network Interface Mode; the service installation option varies by version. If your connection drops after enabling TUN, turn TUN off first, check whether the system proxy still works, and then review the core logs.

TUN doesn't guarantee that every app or protocol can be proxied. Results depend on whether the node supports UDP, how the rules are configured, and whether an app is bound to a specific interface. Running another VPN at the same time can also cause routing conflicts.

7. Where can I find the local proxy port, and why isn't my terminal using the proxy?

Check the listening address and port in the client settings or effective configuration; don't copy a port number from a random online guide. A common example is 127.0.0.1:7890, but your port may be different. mixed-port accepts both HTTP and SOCKS proxy connections on the same port; it is not the remote port on a node server.

# Example local listener; check whether the client already has this setting before merging
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

Terminal tools don't necessarily use the desktop system proxy. If your HTTP proxy port is 7890, run this command in PowerShell for an explicit proxy test. It affects only this request and won't change your global settings.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

The example URL is only for checking whether a request passes through the local proxy; it doesn't confirm that your target service is available. If you see an error connecting to 127.0.0.1, first check that the core is running, the port is correct, and another process hasn't claimed it. If the local port accepts connections but the remote request fails, check the node and rules. Keep LAN access disabled when using the proxy on your own device. To share it, configure the listening scope, authentication, and firewall separately.

8. How do DNS, rules, and subscriptions work together? Should I change DNS if a page won't load?

A subscription provides the configuration, rules determine how connections are routed, and DNS resolves domain names. They can affect one another, but they aren't the same setting. If a page won't load, first check the connection log to see whether the traffic reached the core. Then determine whether the problem is DNS resolution, routing policy, or the node connection.

Keep a working configuration to roll back to before making changes

• The destination isn't in the Connections list: check whether traffic is entering through the system proxy or TUN.
• A domain resolution error appears: check the active DNS configuration and whether the DNS server is reachable.
• The connection matched Direct, but the destination requires a proxy: adjust the relevant rule or proxy group.
• Rules and policies look correct: compare the results with another node and another network.

In mihomo's fake-ip mode, the core typically returns an address from the configured virtual IP pool to the app, then maps it back to the domain name and forwards the connection. This address isn't the node's exit IP and shouldn't be treated as an ordinary public DNS result. After changing DNS mode, an app or the operating system may still cache the old result. Try restarting the affected app before testing again.

Don't change DNS, enable TUN, switch nodes, and edit rules all at once. Change one variable at a time and keep a record of the original value. For corporate intranet domains, printers, and other LAN services, also check whether they need internal DNS and should connect directly.

9. How do I launch Clash at startup, and why does my connection drop when I quit?

Launch at startup, enable the system proxy after launch, and enable TUN after launch are three separate settings. Enabling launch at startup alone doesn't necessarily route network traffic through the client. Restoring the previous proxy state also doesn't mean a working node is available.

1. In the client's Settings, look for Launch at startup or Launch at login, enable it, and save your changes.
2. On Windows, check Settings → Apps → Startup. On macOS, check System Settings → General → Login Items & Extensions and confirm the app is allowed. Names may vary by OS version.
3. If you need TUN, install the service or grant the required permissions as described by the client. Don't rely solely on a privilege prompt appearing at login.
4. After restarting and signing in, check that the client, core, active configuration, and proxy entry point are all working, then test access to a target site.

Closing the window may only minimize the app to the system tray; choosing Exit from the menu actually quits it. If the app exits unexpectedly while the system proxy still points to a local port, your browser may lose access because nothing is listening there. On Windows, check Settings → Network & Internet → Proxy for a manual proxy. On macOS, check Proxy under Details for your current network connection.

10. How do I update the client and mihomo core? Will my old configuration still work?

First identify whether you're updating the graphical client or the core. They have separate versions, so updating the app doesn't necessarily update the core. Note the version in the client's About section, core information, or startup logs, then update using a method supported by that client.

Verify your setup before and after updating

1. Back up your subscription URL, local configuration, override files, and essential settings. Keep the backups secure, too.
2. Get updates through the client's supported update option or the relevant project's release channel, and make sure they match your OS and CPU architecture.
3. Prefer the client's built-in core updater. Don't overwrite files in the application directory with executables from unknown sources.
4. After updating, check that the configuration loads. Test one direct connection, one proxied connection, and any TUN or UDP use case you rely on.
5. If you run into compatibility issues, save the error logs, restore the previous stable setup, and check configuration differences one at a time.

Clash Meta and mihomo are related projects, but that doesn't mean every client with “Clash” in its name supports the same protocols and configuration fields. Older original cores may not recognize newer node protocols or options, and mihomo-specific fields shouldn't be assumed to work with other cores. If your client offers multiple core options, check the capabilities of the core that's actually enabled.

After working through these 10 checks, keep a verified baseline: a valid subscription, clearly defined proxy groups, a reachable node, a confirmed local port, and a single traffic entry point. When adding TUN, automatic node selection, or custom rules later, change and verify each item separately. This is easier to maintain than importing a large set of unknown settings all at once.