Help Center: Clash Troubleshooting Handbook

A client is just a traffic-routing engine: it reads a configuration and decides, rule by rule, whether each connection goes direct or through a proxy. Nodes are provided by whoever runs the subscription (a service provider or your own server) — the client itself ships with zero nodes.

So after installing a client you still need to import a subscription before you have any usable exit. The two pieces are inseparable, and the order is fixed: install the shell first, then load the ammunition.

Rule mode matches traffic against the rules in your config one by one — direct when a rule says direct, proxy otherwise — and is the everyday default. Global mode ignores rules entirely and sends everything through the proxy. Direct mode is effectively a temporary proxy off-switch.

Recommendation: run Rule mode day to day, flip to Global briefly only when you suspect a rule isn't matching, then switch back. Leaving Global on permanently wastes bandwidth and slows down traffic that should have gone direct.

It's the default local mixed-proxy port used by Clash-family clients, shared by HTTP and SOCKS5. Apps hand their traffic to 127.0.0.1:7890, and the core forwards it out according to your rules.

The port number can be changed in settings. Just remember to update the matching value in your system proxy or any other app that references it — otherwise you'll hit a false alarm where the client looks connected but nothing gets through.

The core (mihomo is the current mainstream choice) handles protocols, rule matching, and traffic forwarding — it's the engine. Clients like Clash Plus and Clash Verge Rev are the shells wrapped around it, handling subscription management, toggles, and the interface.

Configuration formats are largely interchangeable across clients because they're all running the same class of core underneath. Pick a shell based on your habits; see the comparison for the differences that matter.

Every client listed on this site is free to download, and most projects have open, reviewable source code. What actually costs money is the node subscription itself — that covers the provider's bandwidth and line costs, and has nothing to do with the client.

Clash Plus is the top recommendation: simple interface, bundled mihomo core, works on Android 5.0 and up. If you want more customization, look at Clash Meta for Android or FlClash.

APK links and system requirements for every client are grouped in the Android section of the download page — just pick one based on the specs listed on each card.

Copy the URL your provider gave you, go to the client's Profiles/Subscriptions page, choose "Import from URL," paste it, save, and update once. A successful import shows up as populated content in the node list.

If what you have is a generic share format rather than a direct Clash config link, it needs to go through subscription conversion before importing. Format detection and conversion steps are covered in the subscription import guide.

Android clients take over traffic through the system VPN interface (i.e., TUN), so the first launch always triggers a "Connection request" authorization dialog. Tap OK and a key icon will appear in the status bar shortly after.

Declining prevents the tunnel from being established; if you tapped decline by mistake, there's no need to reinstall — just find the app under the VPN section of system settings and re-grant it.

Node addresses rotate on an irregular schedule, so it's best to enable auto-update in the client and set it to every 12–24 hours. If you can't connect, manually update the subscription once before troubleshooting anything else.

An update only pulls a small text config, so the data cost is negligible — there's no need to worry that frequent updates burn through your data.

Yes. The config is plain YAML text — rules, proxy groups, and DNS all live inside it, and any text editor can open it.

Keep in mind that automatic subscription updates will overwrite manual edits. For lasting customization, use the client's Override feature or a local config merge, so your changes get reapplied automatically after every update — see Advanced Configuration for how.

Tap the lightning bolt or speed-test button on the node or proxy page, and the client sends a request to a test URL and shows the round trip in milliseconds. That number is the round-trip time for "device → node → test endpoint": under 200ms feels smooth, over 500ms or a timeout means it's time to switch nodes.

Low latency doesn't mean high bandwidth — it only reflects response speed. Latency is the first filter when picking a node; actual throughput still depends on line quality. See the first-connection guide for the details.

Three checks: ① the client's connection toggle is on; ② you're connected to a node that passes speed tests; ③ open any IP-lookup page and confirm the exit IP and region match the node's location, not your own carrier.

If the IP hasn't changed, the system proxy probably isn't taking effect, or the app in question is bypassing it — work through the "Troubleshooting" section below one item at a time.

Most Android clients include a per-app proxy setting — just add the app to an allow-list or block-list; it takes effect after reconnecting.

On desktop, write rules instead: match by domain with DOMAIN-SUFFIX, by process name with PROCESS-NAME, and point the match at DIRECT or a specific proxy group. Rule syntax and priority are covered in Advanced Configuration.

When some programs ignore the system proxy setting (certain games and command-line tools are frequent offenders), TUN builds a virtual network adapter at the system level and funnels all traffic into the core, regardless of which app it came from.

Android clients use TUN by default with no extra step needed; on desktop it requires administrator permission, and pairing it with Fake-IP and DNS hijacking is recommended — see the matching section on the advanced configuration page for how they fit together.

A url-test type proxy group periodically tests latency and automatically switches to the fastest node; a fallback type group checks nodes in order and picks the first one that's available.

If you'd rather not pick nodes manually, point your everyday rules at one of these groups. The test interval and switching tolerance can both be adjusted in the config — a larger tolerance helps avoid nodes flip-flopping back and forth.

Four steps in order: ① whether the device has normal internet access at all; ② whether the subscription link has expired — open the URL directly in a browser and see if it returns text; ③ whether the proxy itself is causing a loopback — temporarily disable the proxy while updating, or set the subscription domain to go direct; ④ whether the provider has changed the link.

These four steps resolve about 90% of cases. If it still fails after all four check out, look at whether the client's UA setting is being blocked by the subscription endpoint.

First update the subscription to get the latest nodes. If everything still times out, check in order: your local network (switch to mobile data or another Wi-Fi network), whether the test URL is entered correctly, and whether the subscription service has expired.

A handful of nodes timing out is normal rotation and needs no action; only investigate further when the entire list is red.

The system proxy setting is only a "suggestion" — apps are free to ignore it. On desktop, the fix is to enable TUN mode, forcing the system to take over at a lower level; on Android, check the per-app proxy list first to see whether the target app is excluded.

Windows Store apps also run into a separate loopback restriction — see the next question for how to handle it.

UWP apps are blocked from the local loopback by network isolation by default — they can't even reach 127.0.0.1, so they can't use a local proxy port at all. This isn't a client bug; it's how the system is designed.

Use the built-in CheckNetIsolation tool, or the "UWP loopback exempt" option in the client, to allow the app through. Full steps and how to verify it worked are in the UWP loopback fix guide.

Try these in order: switch to a lower-latency node, set the proxy group to url-test auto-select, watch out for nodes with a high traffic multiplier in your subscription, avoid peak evening hours, and check the protocol in use (some older protocols get throttled more easily during peak times).

If every node is slow, it's usually a line-side issue — check with your subscription provider. That's about as far as client-side tuning can take you.