10 Clash FAQs for Beginners: Subscriptions, Rules, and Fixing “Connected but No Internet”

1. What’s the difference between Clash, Mihomo, and Clash Verge Rev?

Clash is a common name in the proxy tools and configuration ecosystem. Mihomo is a proxy core, and Clash Verge Rev is a desktop client that uses Mihomo. The client provides subscription management, proxy selection, system proxy controls, and logs. The core handles connections, DNS, and rule matching. Installing a client does not give you working proxy nodes.

Mihomo was previously known as Clash.Meta. Older guides may refer to Clash Meta or the Meta core, but configuration fields can vary across cores and versions. If a configuration fails to load, note the client version, core version, and full error message before investigating compatibility.

• Client: Presents configuration and controls in a user interface, as Clash Verge Rev does.
• Core: Reads the runtime configuration, establishes proxy connections, and applies routing rules.
• Subscription: A source of configuration or nodes provided by your service provider; the client does not generate one automatically.

This guide focuses on desktop concepts in Clash Verge Rev. Android VPN permissions and desktop system proxy settings work differently, so their controls are not interchangeable. To compare options, see Compare Clients.

2. What is a subscription link, and where do I get one?

A subscription link is an address used to retrieve configuration and often contains an account token. Your provider may offer several options, such as an account page, a general node subscription, or a Clash-compatible subscription. In Clash Verge Rev, choose an option compatible with Clash or Mihomo—not the account homepage URL from your browser’s address bar.

Check these three things before importing

1. Make sure the link belongs to your service account and that your plan or authorization is still active.
2. Make sure the response contains supported configuration—not a sign-in page, payment notice, or web error.
3. Make sure the link is complete. Line breaks in chat apps, extra spaces, or missing query parameters can cause the request to fail.

A full configuration may include fields such as proxies, proxy-groups, and rules. It may also load nodes through proxy-providers, so the absence of proxies alone does not mean the configuration is invalid. A node-only subscription may need to be used with an existing configuration.

3. How do I import a subscription into Clash Verge Rev?

Import the subscription, activate its configuration, then choose a node. These steps retrieve the configuration, load it into the core, and select a proxy route. A successful import completes only the first step.

1. Open the “Subscriptions” page in the sidebar, paste the link into the subscription field, and select “Import.” In some versions, this option may be under a menu for adding subscriptions; follow the current interface.
2. Wait for the subscription card to appear. Check the update status, node count, or traffic details; whether these are shown depends on what the provider supplies.
3. Select the subscription to make it the active configuration. If you see a YAML parsing or field error, fix it before enabling network-wide traffic capture.
4. Open the “Proxies” page and choose an available node in the policy group actually referenced by your rules.
5. For your first test, use “Rule” mode with “System Proxy.” Test in a browser, then check the request on the “Connections” page.

If a manual update fails but the previous configuration still works, first check the subscription URL and request path. Don’t delete your only working configuration. For a 401 or 403 response, check your authorization, token, and server-side access restrictions. A 200 response does not guarantee valid content—check that you haven’t received an HTML page instead.

For the full install-and-import walkthrough, see Quick Start. When switching clients, reimport the original subscription first, then migrate local settings separately.

4. Which mode should I use: Rule, Global, or Direct?

Start with Rule mode for everyday use. The mode determines how the core selects a route, but it does not automatically send traffic from every app through the core. System proxy settings, TUN, and each app’s own proxy settings determine how traffic enters.

Global mode does not mean “route all device traffic,” and it does not guarantee faster access to every site. If an app does not use the system proxy and is not captured by TUN, its requests may bypass the client even in Global mode. If the global policy is set to DIRECT, traffic will not go through a remote proxy node either.

In Rule mode, rules are usually checked from top to bottom, and the first match determines the policy. If an earlier direct rule matches a destination, changing the final fallback rule will not affect that request. Check the matched rule in the connection details rather than guessing based on where the site is hosted.

5. What’s the difference between system proxy and TUN mode?

Use the system proxy to test a browser first; use TUN to capture more network traffic. The system proxy registers a local proxy endpoint with the OS, but apps can choose not to use it. TUN captures traffic through a virtual network interface and routing, making it useful for apps without explicit proxy support. It requires service permissions and can interact with your existing network setup.

Enable options gradually, as needed

• Browser only: Enable the system proxy first and temporarily disable browser proxy extensions to avoid conflicting settings.
• Command-line tools: Check whether the tool follows system settings, or configure an HTTP or SOCKS proxy for it directly.
• Games and some desktop apps: Check protocol and node support before trying TUN. System proxy settings generally cannot handle all UDP traffic.

In Clash Verge Rev, check the “System Proxy” and “TUN Mode” options under “Settings.” If TUN is unavailable, check whether the service mode for your version is installed and running. Permissions differ by operating system; running the client as an administrator indefinitely is not a good default fix.

If you also use a company VPN, another proxy app, or virtual network adapters, note the current setup and test with only one traffic-capture method enabled. TUN issues often involve routing, DNS, or subnet conflicts; switching nodes repeatedly may not help.

6. Why won’t a website load even though the node shows a latency value?

A latency test only shows that a specific test request received a response at that moment. It does not measure download bandwidth or prove that a website is reachable—or that every policy group selected that node. A node showing 80 ms may still fail to reach another site. This is an example value, not a measured result.

1. Check which policy group handles the destination. After a subscription update, group names and node selections may change.
2. Check the final route selected by that group. A selected group may itself refer to another policy group.
3. Test a different HTTPS destination known to work to tell a site-specific issue from a broader one.
4. Check the request in “Connections” and “Logs”; don’t rely only on the latency color on the Proxies page.

A timed-out latency test does not prove that a node is dead. The test address may be unreachable, the server may restrict access to it, or the timeout may be too short. Consider actual web requests, connection errors, and how other nodes perform on the same network.

If regular pages load but large downloads or video keep failing, check node quality, destination service restrictions, and protocol compatibility. Don’t choose a node based on the lowest latency alone.

7. How should I troubleshoot “connected but no internet”?

First check whether the request reaches the client, then inspect the rules, node, and DNS. A running status usually means the core or traffic-capture feature has started; it does not mean the full connection to the destination is working.

Trace one request through these six checks

1. Local network: Temporarily turn off the system proxy and TUN, then check whether sites that should be reachable directly load. If basic connectivity is down, check Wi-Fi, your gateway, or a network sign-in page first.
2. Active configuration: Confirm the subscription is selected and the core has not reported a configuration load error.
3. Traffic entry: Reload the destination and check whether its domain or IP appears under “Connections.” If there is no entry, check browser proxy extensions, the system proxy port, TUN routing, and bypass lists.
4. Rule result: Check the new connection’s matched rule and policy chain. Make sure it did not select DIRECT by mistake or match REJECT.
5. Proxy route: Switch to another node in the same policy group and make a new request. Existing long-lived connections may not move to the newly selected node immediately.
6. Error type: Use the logs to distinguish DNS lookup failures, connection refusals, timeouts, and TLS errors, then troubleshoot accordingly.

Restore Rule mode when you’re done troubleshooting. Don’t leave the system firewall disabled, and don’t bypass certificate verification to hide TLS errors. Instead, check the system clock, certificate chain, destination service, and any HTTPS inspection software.

8. How can I tell whether the problem is DNS or the proxy port?

DNS translates domain names into addresses; the proxy port receives app requests. They operate at different stages. If logs show messages such as lookup or no such host, check name resolution first. If a connection to the local proxy address is refused, check the port and whether the core is listening.

The commands below show how to test by explicitly specifying an HTTP proxy endpoint. 7897 is an example port; replace it with the HTTP or mixed port in the client’s current runtime configuration. Do not assume the 7890 used in older guides is a universal default.

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 --head https://example.com/

In Windows PowerShell, use curl.exe to avoid environments where curl maps to a different command. The example uses a 10-second connection timeout and a 20-second total timeout. The destination is illustrative; for troubleshooting, replace it with the address that is failing. An HTTP response means the request reached the application layer, but does not prove that every feature on the site works.

• Local connection refused: Check the port, listening address, whether the core is running, and whether another process is using the port.
• Resolution fails after the request reaches the client: Check the runtime DNS configuration and whether the upstream DNS server is reachable.
• Only the browser is affected: Check browser proxy extensions, secure DNS, cache, and the browser’s own settings.

Fake-IP is a domain-mapping mechanism, not the address of the actual remote server. When it is enabled, a synthesized address in the lookup result is not necessarily an error. Check the effective configuration before changing DNS; the result of the system nslookup command may not reflect the resolution path used by the core.

9. Can subscription updates overwrite node selections and local rules?

Remote subscription content can change with updates; keep local customizations in an override layer. If you directly edit a downloaded remote YAML file, a later update may replace your changes. Whether node selections persist also depends on the client’s save behavior and whether policy group and node names remain the same after an update.

Know which of these three configuration layers you’re editing

• Remote configuration: Nodes, policy groups, rules, and related settings supplied by your provider.
• Local overrides: Fields merged with or adjusted on top of the subscription to preserve your own routing rules and settings.
• Runtime configuration: The final configuration processed by the client and loaded by Mihomo.

With Merge overrides, don’t assume every list is automatically appended. How rule lists are merged, the order scripts run, and client-specific enhancements can all affect the result. After saving, inspect the runtime configuration and test with a real request to confirm the rule matches.

For example, to route a domain directly, adding DOMAIN,example.com,DIRECT is not enough. Check its position in the effective rules and whether an earlier rule matches first. For your initial setup, keep the subscription’s original rules. Once everything is stable, follow Advanced Usage to add local overrides one at a time.

10. No internet after quitting the client? How to restore access and report the issue

First check for leftover proxy settings pointing to localhost. If the system still points to a proxy port on 127.0.0.1 after the client core has stopped, apps that follow that setting will be unable to connect.

1. Reopen the client, turn off “System Proxy” and “TUN Mode,” then quit normally and check whether your connection is restored.
2. On Windows 11, check “Settings” → “Network & internet” → “Proxy” → “Manual proxy setup.” Remove only the local proxy settings you configured; don’t delete settings managed by your organization.
3. On macOS, check “System Settings” → “Network” → your current network service → “Details” → “Proxies,” and review the HTTP, HTTPS, and SOCKS settings.
4. If the problem persists, check for other VPNs, browser-specific proxies, and the HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables in your terminal.

Issues after an unexpected TUN shutdown differ from leftover system proxy settings and may involve virtual adapters, routes, or DNS state. Use the client to stop traffic capture and its service normally; reconnect to the network if needed. Don’t delete routes or virtual adapters in bulk unless you know what they do.

Include these basic diagnostics when asking for help

• Operating system version, client version, and Mihomo core version.
• Current mode, whether System Proxy and TUN are enabled, and the local port in use.
• When the issue occurred, the destination domain, and the matched rule and policy chain shown under “Connections.”
• Errors from around the time of the issue, the steps you tried, and the result of each step.

Remove subscription tokens and other credentials before sharing. A clear set of reproduction steps is more useful than a full-screen screenshot of your nodes. A good troubleshooting order is: subscription valid, configuration active, request reaches the client, rule matches correctly, route works, then investigate DNS and more complex traffic-capture settings.