Before You Connect: Three Basic Checks
Finishing a subscription import just means the node list is now inside the client — it doesn't mean traffic is actually routed through the proxy. For that, three things need to be true at once: the core is running, the system proxy is on, and the proxy mode is correct.
- The core is running. Clash-family clients (Clash, Clash Meta, or mihomo) start a core process that listens on a local port. The default mixed port on most clients is
7890, while Clash Verge Rev defaults to7897— check your client's settings page for the actual value. The corresponding fields in the config file are:
mixed-port: 7890
allow-lan: false
mode: rule
- System proxy is on. Every client has a "System Proxy" toggle on the main screen. Turning it on makes the OS route HTTP and HTTPS traffic to the local port automatically, so your browser and most desktop apps use the proxy without any per-app setup.
- Proxy mode is correct. Clash offers three modes: Rule, Global, and Direct. For everyday use, pick Rule mode — traffic to mainland China sites goes direct, while everything matching a proxy rule gets routed through the proxy. Global mode sends all traffic through the proxy, handy for quick troubleshooting; Direct mode effectively turns proxying off.
Tip
If another program is already using the port, the core fails to start — you'll see the client keep quitting or throwing errors in the log. When that happens, change the port in settings first, then restart.
Picking a Node: Understand Proxy Groups First
Open the Proxies panel and you'll usually see a handful of proxy groups rather than one long node list. Subscription providers organize nodes into groups by purpose, with the actual servers nested inside. There are three common group types:
- Select (manual): The default type. Expand the group and click a node — traffic from that group now goes through it, and stays there until you pick something else.
- URL-test (auto): The client periodically pings every node in the group and automatically switches to whichever has the lowest latency right now. Good if you don't want to manage nodes by hand.
- Fallback: Nodes are probed in list order; if the top one goes down, traffic automatically falls back to the next available node.
When picking nodes manually, three rules of thumb help narrow things down:
- Location first. For users in mainland China, Hong Kong, Japan, Singapore, and Taiwan servers generally beat US/EU ones on latency. Use a nearby node for everyday browsing, and switch temporarily when you need to reach a service in a specific region.
- Then check the line type. Labels like IPLC, IEPL, or "dedicated line" in a node's name usually mean a more stable backbone route. Nodes tagged with a multiplier (e.g., ×1.5) burn through your data allowance faster, so keep an eye on your remaining quota.
- Avoid crowded nodes. When a region has several nodes, prefer the higher-numbered ones during peak evening hours — congestion differences show up directly in load speed.
Testing Latency: What the Numbers Mean
The speed-test button on the node list (a lightning-bolt icon or "Latency Test" label) triggers an HTTP latency check: the client sends a request through that node to a fixed address (usually http://www.gstatic.com/generate_204) and records the round-trip time in milliseconds. The result is shown right next to each node.
| Latency range | What it means |
|---|---|
| < 150 ms | Pages load instantly, video streams smoothly |
| 150 – 400 ms | Fine for daily use, slightly slower loading |
| > 400 ms | Noticeable lag — worth switching nodes |
| timeout | Node unavailable, or the test address is unreachable |
When reading latency numbers, keep two things in mind:
- Latency isn't speed. Latency measures responsiveness; bandwidth determines download speed. A 200 ms node might still max out your bandwidth, while a 50 ms node could be throttled. Use latency tests only as a first filter to weed out timeouts and high-latency nodes.
- If the whole group times out, suspect your local setup first. If every node shows a timeout at once, check whether your local network can reach the test address directly, and confirm your subscription hasn't expired — don't jump straight to blaming individual nodes.
Verifying the Proxy Is Actually Working
Once connected, cross-check with any of these three methods — running all three gives you extra confidence.
Method 1: Check Your Outbound IP
Open ip.sb or ipinfo.io in your browser — the IP location shown should match the node's region. Force-refresh the page before checking, so you don't see a cached result.
Method 2: Check the Connections Panel
The client's "Connections" page lists active connections in real time, showing the destination, the matched rule, and the proxy chain used. Open any webpage — if a matching entry shows up in the panel, traffic is definitely flowing through the Clash core.
Method 3: Test via Command Line (Optional)
Point a request at the proxy address explicitly from a terminal, bypassing the system proxy setting to test the core directly:
curl -x http://127.0.0.1:7890 https://api.ipify.org
If the returned IP matches the node's region, the proxy chain is working correctly. Use whatever port your client is actually listening on — swap it in if it differs from the example.
If the lookup still shows your real IP, check in order: is the system proxy toggle on → is the mode accidentally set to Direct → does your browser have a standalone proxy extension overriding the system setting → does the app in question even read the system proxy at all.
Apps That Ignore the System Proxy: TUN Mode
Some apps — most games, a few command-line tools, and the occasional desktop program — don't read the system proxy setting at all, so their traffic bypasses Clash entirely and connects directly. The fix is TUN mode: the core creates a virtual network adapter and takes over traffic at the network layer, so every app gets routed without needing any cooperation from it.
Note
TUN mode requires installing a network service and granting admin privileges: on Windows, enabling it for the first time prompts you to install service mode; on macOS, you'll be asked for your password to authorize it. You won't need TUN for everyday browsing — turn it on only when an app refuses to honor the system proxy.
Quick Fixes for Common First-Connection Issues
- Every toggle is on, but the browser still connects directly: Check for proxy extensions in your browser (like SwitchyOmega) — they can override the system proxy. Disable the extension, or switch its mode back to "use system proxy."
- Every node times out: First check when the subscription was last updated — nodes in an expired subscription mostly stop working, so update it and test again. If everything still times out, go to settings and change the latency test address to one your current network can actually reach, then retest.
- Connected but slow: Switch to a nearby, low-latency node and avoid peak evening hours; also make sure Global mode isn't accidentally routing mainland China traffic overseas too.
- Want to share the proxy with other devices on your LAN: Turn on
allow-lanin the client, then have other devices set their proxy address to this machine's LAN IP plus the port number.
That covers the full first-connection loop: confirm the core and system proxy are on, pick a node by location and latency, and verify it's working with an IP lookup. From here, subscription updates and rule tweaks are just routine maintenance — the client handles most of that automatically.