10 Common Clash Questions: Subscriptions, Proxy Modes, and Connection Issues

1. What are the Clash client, core, and subscription?

The client provides the interface, the core processes traffic, and the subscription provides configuration. These components work together. Installing a client does not automatically give you working proxy nodes.

• Client: Provides features such as importing configurations, choosing nodes, viewing logs, and toggling the system proxy. Menu labels and default ports can vary between clients.
• Core: Reads the configuration, applies rules, and establishes connections. Clash Meta was later renamed mihomo; its supported fields and protocols are not identical to those of earlier Clash cores.
• Subscription: Usually a URL with access credentials that returns nodes, proxy groups, rules, and other configuration data. It may also provide only a list of nodes.

If you see a “Failed to load configuration” error, note the client and core names and versions, then check the subscription requirements. The installer’s name alone does not tell you whether every configuration field is supported. If you need to choose a client, start with the client comparison, then download the version for your operating system and architecture.

2. Where do subscription links come from, and why shouldn’t you share them?

Subscription links come from your proxy service provider or an administrator who manages the nodes and configuration. The downloads page provides client downloads; installing a client does not create a subscription for you.

What to check after getting a link

1. Check your provider’s account page to make sure your plan is active, you have data remaining, and you’ve selected a subscription format compatible with your core.
2. Copy the entire URL, including any parameters after the question mark. Don’t include explanatory text from the webpage.
3. Add the remote configuration in the client’s configuration or subscription manager. Once it updates successfully, set it as the active configuration.

A failed update doesn’t necessarily mean all your nodes are down. The subscription server may be unreachable, the token may have expired, or the server may have returned a login page. Check the subscription FAQ step by step, and don’t keep adding the same link repeatedly.

3. The import succeeded, but there are no nodes. What’s missing?

First check that the configuration is active, then determine whether it’s a complete configuration or just a node provider. “Download successful” only means the content was retrieved. It doesn’t guarantee that the core loaded it or that the active proxy group contains selectable nodes.

• Configuration not activated: You may have multiple files saved in the configuration list and still be using the original empty one after importing. Check the active configuration and the core logs.
• Format mismatch: A text file containing only a few proxy URLs may not work as a complete Clash YAML configuration.
• Provider not updated: If the configuration uses proxy-providers, the remote node list may still need to be fetched after the main configuration loads successfully.
• Nodes aren’t in a proxy group: Node definitions may exist, but if the active group doesn’t reference them, the list won’t show the options you expect.

Keep the original subscription while troubleshooting. Check whether the error mentions a YAML parsing failure, an unknown field, or a failed remote download. Don’t delete entire sections just to make the configuration “save.” For field hierarchy and indentation, see the YAML guide.

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

Use Rule mode for everyday browsing, Global mode for short tests, and Direct mode to connect traffic entering the core straight to its destination. The mode determines how the core handles traffic; it doesn’t determine whether an app has sent traffic to the core in the first place.

Rules are usually checked from top to bottom, and matching stops at the first hit. Put specific domain rules before catch-all rules. If a site works in Global mode but not Rule mode, check the rules and proxy groups first; don’t assume the subscription is broken. See proxy mode settings for details.

5. The client says it’s connected, but why won’t webpages load?

“Connected” may only mean that the core is running, a VPN interface is up, or a node test succeeded. None of these states alone proves that browser requests are reaching their destination. Check each part in order: local proxy, routing rules, then the remote connection.

1. Make sure the subscription is active, a node is selected in the proxy group, and the core isn’t repeatedly shutting down.
2. On desktop, if you use the system proxy, check that its port matches the client’s listening port. If the client listens on 7897 but the system proxy still points to 7890, traffic will go to the wrong port.
3. Check your browser’s proxy extensions. An extension may override the system proxy or still point to a port you no longer use.
4. Open the client’s connection list, then refresh a new page. Check for the domain, matched rule, and outbound proxy.

If no requests appear in the connection list, check how traffic reaches the client. If requests appear but time out, check the node and destination network. When testing, close old tabs with persistent connections or use a new session so you don’t mistake an existing connection for the current result. For the full initial setup sequence, follow the quick start guide.

6. The browser works, but why doesn’t the terminal use the system proxy?

Some command-line tools ignore the desktop system proxy and use their own options or environment variables instead. That’s why the browser can work while terminal commands fail. First, specify the proxy for a single command to narrow down the issue, then decide whether to set persistent environment variables.

These are example commands, not results tested by this site. They assume the client’s HTTP or mixed-port listener is 7890. Before running them, replace it with the port shown in your client:

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

In Windows PowerShell, use curl.exe to call curl explicitly and avoid parameter differences with aliases in older environments. If you get “connection refused,” check the local port and core status first. If it times out only after connecting to the local proxy, check the remote node and destination address.

• For an HTTPS destination through an HTTP proxy, the proxy address can still be http://127.0.0.1:7890; the client uses CONNECT to establish a tunnel.
• The HTTP and SOCKS ports may differ. Changing only the protocol prefix doesn’t make them interchangeable.
• Global environment variables can affect other tools. Once a one-off command works, configure the proxy according to your shell and tool documentation. When you disable the proxy, remove the corresponding variables too.

For how proxy endpoints, protocols, and ports relate, see the glossary.

7. Do you need to enable TUN mode?

No. Apps that use the system proxy can usually start with that. TUN mode routes traffic through a virtual network interface, which can help with apps that ignore system proxy settings. It also adds permissions, routing, and DNS to the list of things to troubleshoot.

Check how traffic is routed on your platform

• Windows and macOS: The client may need to install a service or network extension, or request administrator access. Toggling the switch without completing the authorization doesn’t mean traffic is being routed.
• Android: Many clients route traffic through the system VPN interface, so make sure VPN permission is granted. App exclusions and bypass lists can also affect which traffic is covered.
• Multiple network tools: Another VPN, virtual network adapter, or security app may change routes or DNS settings. Change one variable at a time when testing.

TUN mode doesn’t mean all traffic goes through a remote node. Once traffic enters the core, modes and rules still determine whether it’s proxied, sent directly, or rejected. Whether UDP, IPv6, and specific network ranges are routed depends on the configuration and platform. Don’t treat TUN as a download speed boost. Before configuring it, read the DNS settings guide.

8. Why are downloads and videos slow even when node latency is low?

A latency test measures the round-trip time or request duration for a specific test target; it doesn’t measure sustained bandwidth. Test methods, target URLs, and timeouts vary by client, so results aren’t directly comparable across setups.

For example, a node can show 40 ms latency and still download at just 1 MB/s. There’s no contradiction: the first is a time measurement, while the second is throughput. Using decimal units, 1 MB/s ≈ 8 Mbps. Actual speeds also depend on network congestion, server limits, packet loss, and device performance. These figures are only examples to explain the units.

1. Use the same test file on the same network, and pause other bandwidth-heavy tasks.
2. Test two nodes for about 30 seconds each. Record the speed once it stabilizes, not just the initial peak.
3. Repeat the tests during peak and off-peak hours to see whether results vary by time of day.
4. Check your provider’s data multiplier. If usage is billed at 2×, for example, using 1 GB typically deducts about 2 GB from your plan allowance. Check your provider’s terms for the exact calculation.

A region label doesn’t guarantee the exit location a website sees or the content it makes available. Check the actual exit location and the service’s rules. Don’t draw conclusions from a single page load after repeatedly switching nodes. For routine troubleshooting, use the steps in the FAQ.

9. Should you just turn off DNS or Fake-IP when errors appear?

First distinguish DNS resolution failures from routing errors and node connection failures, then decide whether to change the DNS mode. A site not loading doesn’t necessarily mean DNS is the problem. Replacing the entire configuration at once also makes it harder to identify the cause.

Fake-IP returns a synthetic IP address to the app for mapping, then the core uses the associated domain name to handle the connection. The commonly seen 198.18.0.1/16 is an example of an address range used for this mechanism. Seeing this kind of result doesn’t mean the domain was incorrectly resolved to a regular public server. Check the core and DNS configuration to understand the exact behavior.

• Resolution failure in the logs: Check whether the upstream DNS server is reachable and whether DNS requests are caught in a loop.
• Only local network device names fail: Check local domain names, search domains, and Fake-IP filtering. Don’t exclude every domain.
• Only one browser behaves differently: Check its Secure DNS or DoH settings; it may be using a different resolution path.
• No change after adjusting settings: Restart the affected app or clear its DNS cache in case it’s still using an old result.

Change one setting at a time and record the logs before and after. For definitions and configuration limits, see the Fake-IP guide.

10. Lost internet after closing the client? How to restore it and prepare a support request

First check for a leftover system proxy, then check TUN routes and DNS. If the system still sends requests to a local listening port that’s no longer running, apps that use the system proxy may lose access while other apps continue to work.

Recovery steps

1. Reopen the client you were using, turn off the system proxy, and—if TUN was enabled—turn off TUN before exiting normally.
2. On Windows 11, go to Settings → Network & internet → Proxy to check the manual proxy settings. On macOS, go to System Settings → Network → your current connection → Details → Proxies. If your device is managed by an organization, check its requirements first.
3. If only the terminal is affected, check command-line options and proxy environment variables. These may not be cleared when you turn off the system proxy.
4. If access still hasn’t returned, save the logs, reconnect to the network, and check DNS and the default route. Don’t delete every virtual network adapter or reset all network settings.

After your first setup, record the status in a consistent order: active configuration → proxy mode → selected proxy group → traffic entry point → test destination. The next time something breaks, you can compare only what changed. For installation and permissions, check the quick start guide—there’s no need to reinstall the client as a first step.