Clash Beginner FAQ: Fix Subscription Import Errors, Node Timeouts, and System Proxy Issues

When troubleshooting Clash, first identify where the problem occurs: whether the configuration loaded, whether a node connects, and whether app traffic reaches the client. Check in that order to pinpoint the cause more easily than by switching modes, changing ports, and reinstalling all at once.

01 / How are Clash, the client, and mihomo related?

The client provides the interface; the core handles connections. Subscription imports, node selection, and system proxy settings are usually managed in the client. The core reads the rules and connects to servers. The Clash Meta project was later renamed mihomo, so older guides may still use its previous name.

Client: A desktop window, tray menu, or mobile app that determines where buttons and settings appear.
Core: Handles proxy protocols, rule matching, DNS, and connections, and determines which configuration fields are supported.
Configuration: Settings read by the core, usually in YAML format—a text format where indentation represents hierarchy.

If you see “unsupported proxy type” or “unknown field,” don’t compare app icons alone. Find the client and core names and versions under “About” or on the core information page, then check whether the subscription supports that core. Older Clash versions and current mihomo builds do not support exactly the same configurations.

02 / Why are there no nodes to select after installation?

Installing the client doesn’t give you a proxy configuration. Nodes contain connection details for remote servers and are typically provided by a service through a subscription. A subscription link is an address for retrieving and updating configuration—not an ordinary web page you can open and use directly.

Get a subscription link from a trusted source that supports your client or core. Don’t use the URL of an account management page as a subscription link.
Open the client’s “Profiles” page, choose to add a remote profile or import from a URL, and paste the full link.
After importing, select the profile to make it active.
Go to “Proxy,” expand a policy group used by the rules, and select a node. A policy group is a set of connection options that rules can use.

A profile appearing in the list doesn’t mean the core has loaded it. If the Proxy page still shows only direct connections, check that the profile is selected, then look in the logs for a configuration load error.

03 / Subscription import failed: check the link or the network first?

Read the error before choosing what to check. Timeouts, permission errors, and parse errors have different causes. Repeatedly clicking Update usually just repeats the same error.

Error or symptom	Check first	Next step
Connection timed out; DNS lookup failed	The network path used to fetch the subscription	Make sure regular websites load, then check whether updates depend on a proxy that’s no longer working
HTTP 401 or 403	Subscription credentials, account status, or access restrictions	Get a fresh link from the service provider; don’t keep testing the old link publicly
HTTP 404	Whether the URL is complete or the endpoint has changed	Copy the subscription link again and check for a missing path or query parameter
YAML parsing failed	Whether the response is actually a configuration	Check whether the response is a login page, error page, or unsupported subscription format

Narrow it down in three steps

Copy the link again, remove any leading or trailing spaces, and make sure it contains no Chinese punctuation or line breaks.
Check the format options provided by the service and choose a Clash or mihomo configuration compatible with your core.
If your current proxy is no longer working and subscription updates are set to use it, temporarily switch to a direct connection for the update. Conversely, if the subscription URL isn’t reachable directly, you’ll need an available, authorized network path to fetch it.

04 / Import succeeded, but the configuration has errors. What should I change?

Downloading successfully and loading successfully are two different things. The client may have downloaded the file, but the core can’t parse its contents. Open “Logs” and find the earliest configuration error from the latest load attempt—not just the final startup failure message.

Indentation error: YAML uses spaces for indentation, not tabs. Check the line before the reported location as well.
Missing reference: A policy group name referenced by a rule must exactly match its definition. An extra space or missing character can cause an error.
Core incompatibility: The configuration uses a protocol or field the current core doesn’t recognize. Use a compatible format or core rather than simply deleting the line that triggered the error.

These two lines show how a rule references a group name; they are not a complete configuration:

rules:
  - DOMAIN-SUFFIX,example.com,Web Proxy
  - MATCH,DIRECT

“Web Proxy” must be defined under proxy-groups in the configuration. MATCH matches the remaining traffic. Back up the original file before making changes. If you edit a downloaded copy of a remote subscription, the next update may overwrite it. For lasting changes, use the client’s supported override or merge feature, then verify the result is active.

05 / All node latency tests time out. Does that mean every node is down?

A timed-out latency test only means the test request didn’t finish in time. The node may be unreachable, but the test URL, DNS, or selected configuration could also be the problem. Latency usually measures response time to a specific test address; it doesn’t indicate download bandwidth.

Make sure the device can reach a regular website directly, ruling out an internet outage or a Wi-Fi sign-in page.
Confirm that the active configuration loaded successfully and that the subscription hasn’t expired or run out of data.
Select a node manually, visit a permitted destination, and check Connections and Logs.
If sites load but the latency test times out, check the test URL, timeout, and test method. If sites also fail, try another node for comparison.

Compare results; don’t judge by latency alone

For example, one node showing 80 ms and another 180 ms only means their response times differed in that test. It doesn’t prove the first will download faster. If several nodes fail on your home network but work on a phone hotspot, check the local network path before reinstalling the client.

In logs, connection refused usually means the connection was rejected; timeout means it took too long; and no such host often points to a DNS lookup problem. Record the destination and time to distinguish an issue with the local proxy, remote node, or destination website.

06 / System proxy is on. Why is nothing changing in the browser?

The system proxy tells apps that honor the setting to send requests to a local proxy port. It doesn’t automatically route every program. First, check that the address set in the system matches the address the core is actually listening on.

Look for the HTTP or mixed port in the client settings or active configuration. A mixed port can accept both HTTP and SOCKS proxy requests.
If the local mixed port is actually 7890, for example, the system proxy should point to 127.0.0.1:7890. Don’t assume this example port is the default for every client.
On Windows 11, go to “Settings” → “Network & internet” → “Proxy” and check the manual proxy settings. On macOS, go to “System Settings” → “Network” → your current connection → “Details” → “Proxies.”
Check for browser proxy extensions, separate browser proxy settings, and other network tools that may override the system setting.

In Windows PowerShell, use this command to test the local HTTP proxy directly. Replace the port with the one in your configuration first:

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

This command explicitly specifies a proxy, so it doesn’t rely on the browser honoring the system proxy. It only confirms the result of one request to the test site: if it can’t connect to 127.0.0.1, check whether the core is running and the port is correct. If the request reaches the client but fails, check the rules and node.

07 / Which mode should I use: Rule, Global, or Direct?

Use Rule mode day to day; switch modes briefly when troubleshooting. These modes determine how requests that reach the core are routed. They don’t determine whether app traffic reaches the client in the first place.

Rule mode: Matches rules in the configuration order and applies the corresponding policy group, direct connection, or reject action.
Global mode: Usually routes requests that reach the core through the global policy. Check whether the global group is set to a node or a direct connection.
Direct mode: Sends requests that reach the core directly. It doesn’t mean the system proxy is off or the core has stopped.

Rules are generally evaluated from top to bottom, and the matching rule determines the policy. So if a site connects directly in Rule mode but uses a node in Global mode, the rules may be producing different results—it doesn’t necessarily mean the client is broken. Open “Connections” to see the destination domain, matched rule, and actual policy chain; that’s more useful than checking only whether the page loads.

08 / When should I use TUN mode? What if the internet stops working?

Consider TUN when you need to route traffic from apps that ignore the system proxy. TUN creates a virtual network interface that uses system routes to send eligible traffic to the core. It may require administrator privileges or a client service mode. Support depends on your system, core, and configuration.

Verify the basic connection before enabling TUN

First, use an explicit proxy request or a browser to confirm that at least one node can reach a destination.
Record the current system proxy, DNS, and other VPN settings so you don’t change multiple variables at once.
Install the required service or grant network permissions as instructed by the client, then enable TUN. Check whether an interface is created and whether any routing or permission errors appear.

If even direct websites stop loading after you turn it on, disable TUN first and check whether the original network works again. Then check permissions, route conflicts, and DNS settings. DNS translates domain names into IP addresses. A DNS issue can leave the connection active while domain lookups fail.

Don’t copy entire fake-ip, DNS hijacking, or routing sections from another guide into your existing configuration. fake-ip uses virtual addresses to help map domain names; whether it’s appropriate depends on your DNS and routing setup. Corporate networks, other VPNs, and virtual machine networks can also conflict with TUN.

09 / Why do browsers work when games or store apps don’t?

First, check whether the failing app’s connections appear in the client. A working browser only confirms that the browser’s route works; other apps may use different proxy methods.

No requests in the Connections list: The app may ignore the system proxy or use its own proxy settings. Check the app’s settings first, then consider whether routing it through TUN is appropriate.
Requests appear but use a direct connection: Check the matched rule and policy group to confirm they’re expected. Don’t just switch nodes.
Requests reach a node but fail: Check the destination protocol, service restrictions, and whether the node supports the required transport. Some games use UDP; a working HTTP proxy doesn’t mean the UDP route will work.
Some Windows Store apps fail: UWP network isolation may be involved. UWP is a Windows app platform; these apps may need a per-app loopback exemption to access a local proxy.

A loopback exemption only addresses restrictions on specific apps accessing a local interface. It won’t fix an expired subscription or make an unsupported protocol work. Identify the app and failing route first, then use the appropriate tool from a trusted client. Don’t exempt every app just to test.

10 / How can I recover safely if a subscription update or client shutdown causes problems?

Restore the last working route first, then make a lasting fix. Subscription updates can change node names, policy group members, and rules. After the client exits, the system may also retain proxy settings that point to a local port. Handle these as separate issues.

Problems after a subscription update

Check which profile is active and whether the latest update actually succeeded.
Review your policy group selections. A manually selected node may have been renamed or removed, changing the group’s result.
Check the configuration load logs. If you have a known-good local backup, switch to it temporarily to test; keep in mind that its nodes and credentials may also have expired.
Once service is restored, migrate custom rules one at a time. Don’t overwrite the updated configuration with old rules when its structure has changed.

No internet after exiting the client

First, check whether the system proxy still points to 127.0.0.1. If the client has stopped listening, leaving this proxy enabled will break connections. Turn off any lingering proxy setting. If you used TUN, make sure its interface and routes have also been restored. Don’t delete the entire configuration directory instead of checking these settings.

Keep reading: choose a guide by issue

For installation and importing, see the user guide. To check field hierarchy, policy group references, and rule order, consult the YAML manual. Find answers to common usage questions in the FAQ. Change one thing at a time while troubleshooting, and keep a record of the results before and after each change.